nilsson: airlied, I managed to fix it
nilsson: it looks like Option "Position" "1681 0!" was causing the problems
nilsson: *"1680 0"
nilsson: also, I had to switch monitor-DVI-0 and 1
nilsson: the reason I was using Option "Position" instead of Option "Right Of" is b/c there is a 1px bleedover to the second monitor
airlied: wierd, rotation must have off by one
nilsson: it happened on both kubuntu and fedora
nilsson: but it was their even without rotation
nilsson: I think it's something w/Right Of
nilsson: airlied, thanks for the help
nilsson: bye
Nightwulf|work: hi all
EruditeHermit: hey, does fdo bugzilla allow attaching tar.bz2 files?
EruditeHermit: would that count as a binary file?
EruditeHermit: nevermind
EruditeHermit: airlied, hey are you getting my messages?
spstarr: morning
[Enrico]: 'morning :)
spstarr: the sun rising has woken me up
zhasha: spstarr: weirdo
spstarr: heh
spstarr: well, i face east
spstarr: glisse: i hit some ttm error
spstarr: [13023.728128] radeon 0000:01:00.0: object_init failed for (86016, 0x00000002)
spstarr: [13023.728134] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (86016, 2, 4096, -22)
spstarr: [13023.728187] [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 21 pages at 0x00B6A000
spstarr: [13023.728192] [TTM] Couldn't bind backend.
glisse: spstarr: trying some big gl app ?
spstarr: it was second life that tripped that
spstarr: glisse: i think during the GPU reset with GLSL being enabled
spstarr: it kept spamming log with that over and over
glisse: it only happen within gpu reset ?
spstarr: lemme try to reproduce now
spstarr: Mar 11 07:06:00 segfault kernel: [ 1426.245863] [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 1 pages at 0x0040F000
spstarr: Mar 11 07:06:00 segfault kernel: [ 1426.245868] [TTM] Couldn't bind backend.
spstarr: i tripped
spstarr: Mar 11 07:06:00 segfault kernel: [ 1426.245877] radeon 0000:01:00.0: object_init failed for (4096, 0x00000002)
spstarr: Mar 11 07:06:00 segfault kernel: [ 1426.245884] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (4096, 2, 4096, -22)
spstarr: yes
spstarr: the app just crashed hehe
spstarr: now some text glyph corruption
spstarr: i see on my screen session
spstarr: i was enabling additional GLSL shader programs in game
spstarr: lemme run again with gdb for app see where it dies
spstarr: as the game calles them
spstarr: 'Atmospheric Shaders'
spstarr: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
spstarr: [ 1818.331849] [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(15).
spstarr: [ 1818.331856] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
glisse: spstarr: too much allocation
spstarr: I suppose
spstarr: glisse: well, how will we handle demanding games that allocate so much at once?
glisse: gl should report OUT OF MEMORY
glisse: and then it's up to the app
glisse: to behave
spstarr: hmm so a bug in mesa
glisse: it's not a bug
spstarr: hmmm
Thunderbird: so when will Mesa 9.0 with OpenGL 4.0 be out? ;)
adamk: As soon as you finish it.
[Enrico]: hopes glisse will soon finish the r600g shader compiler, so he will enjoy testing it ;)
kjeldahl: Anybody aware of bugs leading to random "pauses" with window updating etc? Cursor working fine, but kwin becoming unresponsive for 30-60 seconds? Then it resumes just fine. On RV730 PRO (HD 4650).
agd5f: airlied, mjg59: http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-expose-thermal-fan-i2c-buses.patch
suokko: "Wellcome to home" BUG: unable to handle kernel paging request
mjg59: agd5f: Looks good
mjg59: agd5f: But probably ought to do the request_module itself
AndrewR: agd5f, anything new on old i2c front ?
AndrewR: agd5f, i mean non-atombios
crimsonflame123: Hi, I updated my Fedora 12 system yesterday which caused the 2.6.32.* kernel to come in. The kernel works fine for single monitor setups but on dual screens, the second screen has moire patterns... I have ATI X 1300 card on my Lenovo T60. Any help?
agd5f: AndrewR: unforunately, I can't reproduce it and no one internally remembers if there are any timing specific issues on some chips :/ I may have to add an option to disable hw i2c on some chips.
AndrewR: agd5f, kernel option will be ok.
AndrewR: *module
agd5f: mjg59: yeah. unforunately, I don't seem to have a card with a thermal chip on it
mjg59: agd5f: Heh
mjg59: agd5f: Ok, I can probably find something and test that
Ghworg: Is the sensor the AMD GPU tool calls "Internal TSS" documented in the publically released docs?
agd5f: Ghworg: not yet
Ghworg: agd5f: OK, just checking I hadn't missed it
Obscene_CNN: notes I2C can be flaky at times if the pull up resistors on the lines are too high
stepomaticc: can someone explain to me what zaphod mode is ( can't find nothing on google + don't understand it ...)
adamk: stepomaticc: Separate screens on multiple outputs on a single video card.
stepomaticc: whats the difference from dual screen .. xinerama
adamk: xrandr and xinerama drive both monitors as one large screen.
stepomaticc: then with zaphod you can have 2 window manager each on 1 screen is that right ?
adamk: If the window managers let you, yes.
adamk: But you can not move windows between the two screens.
adamk: And, last I checked, using zaphod disables direct rendering.
spstarr: agd5f: i highly doubt the i2c changes broke my r1xx + TV tuner support, we still have analog tv up here for a bit more.
spstarr: er doubt > believe
agd5f: spstarr: there is no tuner support with kms
spstarr: oh
spstarr: well, then that goes out the window then :)
stepomaticc: never heard from it until today, is it working with the radeon driver and where can i get some more information , pointers
adamk: stepomaticc: I've not gotten it to work with radeon recently. When I last tried, I had no 3D acceleration on either screen.
adamk: Theoretically you create an xorg.conf file with two screen sections, two monitor sections, two device sections, etc.
agd5f: stepomaticc: it works. although some xservers are broken
adamk: agd5f: Does DRI still get disabled?
suokko: adamk: DRI should be working with KMS
suokko: but I haven't tested
agd5f: adamk: wuth ums, yes. I think it works with kms
stepomaticc: ok, merci
spstarr: looks at git commits
spstarr: hmm OpenGL 4.0
spstarr: you know, sooner or later we will catch up with this with the switch to gallium.
agd5f: Obscene_CNN: good hint
agd5f: andrewR: does the patch I posted on the i2c bug help?
Obscene_CNN: yes, I2C with pull up resistor values that are too high can't be driven as fast.
maligor: spstarr, heh, but only the r800 supports opengl 4.0
spstarr: only?
spstarr: an OpenGL 3.3?
spstarr: and
maligor: spstarr, OpenGL 3.3 is for everything else I think ;P
maligor: 4.0 is just for DX11 equivalency for the pipeline afaik
maligor: shameful that microsoft is pulling it along like that really, but I don't really see any immediate need to implement opengl 4.0 :P
chithead: some opengl4 / dx11 features like tesselation have been around for longer than r800
maligor: yeah, ati has had tesselation for quite a while
maligor: I don't really know how the original ATI stuff differ tho
suokko: 7 years of tesselation. I think
brot: i know that my good old radeon9000pro had some kind of tesselation called TruForm, and afaik the radeon8000 had support for it, too.
suokko: sorry 9 years that is :)
suokko: brot: 8500 that is
maligor: fglrx advertises: GL_AMD_vertex_shader_tessellator
maligor: that's on a r600
maligor: there might be enough differences for it to not qualify for the DX11 feature ofcourse
suokko: maligor: I read something that tesselation requirements in DX11 don't match r[67]00 hw directly
maligor: yeah, I haven't really verified it, but that's pretty much what I've heard also
brot: it might match the opengl tesselation requirements.
spstarr: suokko: hello
suokko: spstarr: hi
spstarr: anything else you noticed that looks bad?
suokko: spstarr: State emit takes fair share of cpu time with command stream checker but same problem exists in older generations too
maligor: don't suppose anyone's tried mixing other cards with radeon?
spstarr: suokko: anything we can do?
spstarr: suokko: im concerned we have more overhead than windows would even for the sake of CS checking for security, i would hope that isn't adding enough latency to cause problems
Obscene_CNN: well when you use four instructions to write every dword to the ring buffer I don't think the CS checking is going to be that significant
suokko: Obscene_CNN: It would help mroe if we had the "super shaders" that are one of gsoc project idea
suokko: Because that would reduce emit sizes
glisse: DX11 needs programable interpolation i think that the big change from DX10.1
airlied: Obscene_CNN: we don't write near as much stuff to the tring buffer
airlied: Obscene_CNN: have you got patches that speed up KMS btw?
airlied: I thought I'd only seen UMS speedups reported
Obscene_CNN: I have some minor speedups for KMS
airlied: like multiple fps in openarena?
Obscene_CNN: I don't have openarena installed
Obscene_CNN: but torcs shows improvement in FPS
Obscene_CNN: minor improvement
glisse: how much ? average ? mean ? stdev ?
Obscene_CNN: it shows improvement in the peak fps.
Obscene_CNN: the main thing it does is free up CPU time for the physics engine which makes the game playable
dougmencken: airlied, hi! what about OF radeons? any progress? I saw fedora's kernel 2.6.32.9-70.fc12.ppc now includes your patch so "[drm] Not an x86 BIOS ROM, not using."
airlied: dougmencken: that + offb fixup patch have gone upstream, it works on some of machines (r300)
dougmencken: airlied, ah, mine is rv100
spstarr: hmm
dougmencken: and there're difinitely some gamma problems: too yellowish and smth too blueish
spstarr: The OpenGL 3.3 specification is designed to bring as much of the new OpenGL 4.0 functionality back into OpenGL 3.x as possible while still retaining compatibility with existing graphics processors.
spstarr: Woo!
spstarr: that is good
brot: right, the new opengl specs seem to be really good.
spstarr: once Gallium starts work on more GL 3.x stuff
brot: i hope they start that work soonish.
Dr_Jakob: spstarr, brot: Already happening...
Dr_Jakob: At least getting the Gallium API up to spec.
glisse: maybe we should focus on 3.0 first ;)
spstarr: glisse: i'd go for that :)
spstarr: the r6xx supports OpenGL 3.x
spstarr: Dr_Jakob: Well, with all the work on Gallium over the years, now we will see
spstarr: so eventually, when a new GL spec comes out implementing it with gallium will be much less time between
spstarr: glisse: I will also test your gallium code once it has some more stuff implemented
brot: i am really looking forward to what gallium will do with my RV670PRO :)
glisse: well i will stop thinking too much about compiler and add feature this weekend
spstarr: my hope is, with gallium all the code path issues i hit now, mostly magically melt away via gallium's internal infrastructures
spstarr: glisse: heh
spstarr: glisse: well, we kinda need both no? :)
spstarr: glisse: how much time do you think it'll take to bring the r600g driver up to the DRI2 driver?
spstarr: you can cut and paste any of the code? especially the writing to register code?
brot: the dri2 driver already does a great job btw. kwin desktop effects work awesome here, and so does video playback. (using git from 2 days ago and 2.6.34-rc1)
spstarr: well, once the drm/ttm issues are solved
spstarr: the rest should just flow i guess
suokko: hmm. Looks like dynpm is a bit too aggreive in clock changes :/
spstarr: agd5f: how many clocks does the RV635 have?
spstarr: it only shows values/
spstarr: ?
suokko: It is even downclocking while I'm running torcs :)
spstarr: what is torcs?
suokko: car game
spstarr: oh
spstarr: how many FPS you get?
suokko: And I got GPU lock with torcs now with dynpm on :/
suokko: spstarr: I'm running it with tweaked visibility so it runs 15-25 fps
spstarr: that is still better than any games I get :)
suokko: and GPU reset failed :/
spstarr: kill the game
suokko: spstarr: dead lock too
glisse: suokko: my reset stuff ?
suokko: glisse: vanila git from today
glisse: oh so no
suokko: I should patch it :)
suokko: CP reset succeed (RBBM_STATUS=0x83F86100) <- But the fails to wait RBBM fifo
glisse: reset succeed with such rbbm_status is a lie
glisse: dammm i can read rbbm_status with looking at reg spec
suokko: psst rv280
glisse: they have similar bit up to r5xx
glisse: main diff is in 3d engine
glisse: and by the look of your i can tell its before r3xx
glisse: really scary ;)
suokko: You have looked at status too much ;)
glisse: yeah i am not human anymore, i am halfway to a gpu ...
spstarr: heh
suokko: btw, dynpm has a but. It doesn't set default clocks when unloading radeon module
suokko: And now it hard locked in module reload :/
agd5f: suokko: yeah, the algo for when to changes clocks needs work
suokko: no. It was jsut spinlock lockup
agd5f: shoudl be some adaptive timer
agd5f: like looking at fence history
agd5f: rather than the number of queued command buffers
suokko: yes
suokko: glisse: http://sprunge.us/gRWe
glisse: weird no radeon function in the stack
suokko: glisse: That what I was wondering too. But reloading radeon module caused it
suokko: [ 251.009625] BUG: key df0e3584 not in .data! agrep requesting for firmware
suokko: There is definedly large number of random bugs with this rc kernel that I'm hit :/
suokko: hmm. That key hex values is different in first load :/
spstarr: ew
suokko: That bug is some lockdep bug where the key values is not static
spstarr: suokko: i have to go UMS :/
spstarr: its just too sluggish
spstarr: ugh UMS
spstarr: the mouse cursor stalls when X starts or VT switching
suokko: spstarr: btw, I managed to get outside of tutorial building in Second Life. That means I'm stuck in tutorial now
spstarr: suokko: lol
spstarr: suokko: well, i didn't mean for you to play it :) just use it for stressing stack?
suokko: spstarr: But it probably would help testing if I got to main playing area
w1pko: hello guys, need a help with my radeon hd3450 and fedora. My mesa drivers are working, compiz ok, but 3d applications run slowly...As I try to run google eart, i get a message that I use OpenGL with software acceleration. ..and it's running slooowly ...any idea? thanks!
spstarr: KMS?
airlied: w1pko: LIBGL_DEBUG=verbose glxinfo
w1pko: airlied: sure, w8 pls
airlied: oh use pastebin pls ;-)
suokko: vau. I found torcs track runs at 60fps :)
suokko: So a lot of difference what level
spstarr: !
w1pko: sorry guys, I lost my chat history..somebody wanted the debug log of my glx: http://fpaste.org/wTdi/
hnsr: that was airlied I think
w1pko: hnsr: thank you
w1pko: airlied: http://fpaste.org/wTdi/
airlied: w1pko: seems fine, are you on 64-bit? using 32-bit google earth or something?
w1pko: yes, i'm using 64-bit f12 ...not sure with GE...checking
w1pko: airlied: jeez..i don't know, how to find out if my GE is 32-bit or 64-bit
airlied: w1pko: I think its 32-bit only
airlied: in theory you can install the 32-bit mesa libraries
airlied: yum install mesa-dri-drivers-experimental.i686
w1pko: am i supposed to uninstall 64bit drivers first?
w1pko: airlied: No package mesa-dri-drivers-experimental.i686 available.
airlied: forgets if Fedora does thi
airlied: wierd no multi-lib for that package
airlied: w1pko: do yum install mesa-dri-drivers.i686
Wizzup: went through a lot of pain to get multilib mesa on gentoo
w1pko: airlied: interesting: Package mesa-dri-drivers-7.7-4.fc12.i686 already installed and latest version
airlied: w1pko: then tell me what rpm -q mesa-dri-drivers.i686 is
w1pko: airlied: seems taht i have mesa-dri-drivers installed both for i686 and x86_64
airlied: w1pko: yup what version?
airlied: I'll give to the r600 32-bit driver rpm
w1pko: mesa-dri-drivers-7.7-4.fc12.x86_64
airlied: wget http://kojipkgs.fedoraproject.org/packages/mesa/7.7/4.fc12/i686/mesa-dri-drivers-experimental-7.7-4.fc12.i686.rpm
airlied: then yum install --nogpgcheck mesa-dri-drivers-experimental-7.7-4.fc12.i686.rpm
airlied: there is a bug with fedora mulitlib and that package
w1pko: airlied: ok, downloaded and installed.....reboot?
airlied: w1pko: shoudn't need to
airlied: just try ge again
w1pko: airlied: fixed!
w1pko: airlied: but with strange artefacts...that is probably a bug
w1pko: but it's finally hw accelerated...thanks!
w1pko: hmm...ok, GE is useless...freezes after few seconds of usage
w1pko: airlied: tried stellarium.. no difference
w1pko: airlied: hi, got the GE running with no problems...i just turned on mode setting...thank you! (i had nomodeset because X used to freeze after few minutes) this is now gone
soreau: Isn't there a bug where compiz would die after a few minutes or some performance issue after loading gnome using KDM?
soreau: on fedora?
w1pko: soreau: that could be it....but it's ok now
soreau: Is there a bug report?
w1pko: soreau: don't know
Jonimus: has anyone tried agd5f's new thermal i2c patch to see if lm_sensors picks the chip up?
Jonimus: Hmm it seems the r770's use a built in temp sensor so that did me no good :/
Jonimus: so has anyone looked into making a thermal driver for the rv770 yet or no since that patch just was released?
EruditeHermit: airlied, hey, got time to continue the bug hunt?
airlied: maybe in a while trying to get one last bug out of something
airlied: I'm still a bit lost as to what could be wrong
AndrewR: airlied, i uncomented debug printf in r200_blit, it seems working, but why so slow? http://pastebin.ca/1834985
meoblast001: hi
meoblast001: i'm a game developer who's been working on an engine for a few months now... soon i'll be adding some shaders, and i got some bad news from some people
airlied: AndrewR: welcome to AGP :)
meoblast001: is it true that the free radeon drivers do not have GLSL support at all?
airlied: meoblast001: on r300->r500 yes
BioTube: meoblast001: r600+ supports GLSL with KMS
AndrewR: airlied, Result: 197 reads in 4.000000 seconds = 1.796246 Mpixels/sec - so, suokko's patches may help ? (i don't have them applied right now)
meoblast001: hm.. .time for me to upgrade my card?
airlied: there is a r300g driver in development for r300->r500 to support GLS
airlied: GLSL
meoblast001: does it work at all?
meoblast001: this is sort of depressing because i was considering adding shaders soon
BioTube: just do what second life does and keep them disablable
meoblast001: how can i test them then? :P
BioTube: guinea pigs
meoblast001: plus, what about armatures, which are typically calculated using shaders
meoblast001: doing them on the CPU is possible, but not preferable
BioTube: to be honest, I've got little knowledge in the area of graphics
meoblast001: hm, i'll upgrade to r600 then
AndrewR: airlied, i'll test with agpmode=-1 ....
AndrewR: airlied, Result: 1300 reads in 4.000000 seconds = 11.853400 Mpixels/sec - and much, much less CPU usage ......
airlied: AndrewR: ouch
meoblast001: how well do the r600s work?
AndrewR: airlied, but ..... i'm not sure if 512 MB pci gart is really good idea on my 256 Mb-only machine .... or this line is bogus? [drm] radeon: 512M of GTT memory ready.
BioTube: meoblast001: my only complaint is that it occasionally locks up on VT switch
meoblast001: VT?
airlied: AndrewR: its not actual memory just space, though not sure what we do if we try and put 256 RAM into it ;-0
AndrewR: airlied, ttm will bite radeon?
AndrewR: [TTM] Zone kernel: Available graphics memory: 126780 kiB.
AndrewR: airlied, can those two will be more cooperative on space size ? (i prefer swap-less operations, in graphical world)
airlied: AndrewR: it won't allocate more memory than that for gpu objects
airlied: so you won't get to use all the gart space ;-)
spstarr: airlied: it is higher with glisse's new patches though
meoblast001: does the r500 series support enough GLSL to run a default shader?
meoblast001: one that creates the same result as no shader at all
airlied: meoblast001: with r300g yes in theory it should do most of the basics stuff
meoblast001: r300g, where can that be obtained?
airlied: mesa git
meoblast001: ok, thanks
meoblast001: airlied: should i fit "compile r300g" into my schedule or does it use a standard build system?
airlied: meoblast001: make sure you are running a KMS system
airlied: then its just a matter of --enable-gallium-radeon
airlied: flag to mesa configure
airlied: and you should have lib/gallium/radeong_dri.so
meoblast001: ok
airlied: ln that to r300_dri.so and set up LIBGL_DRIVERS_PATH to point to there
meoblast001: k, thanks
meoblast001: well, i might get lucky
meoblast001: shader support is not in this short 10 day stride i'm doing
meoblast001: at least in the draft (i might add it)
meoblast001: so that means i have 10 days to get a new card :P
meoblast001: i have the money, although it hurts to spend it
gcarter: Well, looks like Fedora 13 has solved my problem.
gcarter: test
gcarter: test
gcarter: test
gcarter: Anyone on?
gcarter: test
gcarter: Sure
meoblast001: please don't flood the channel
spstarr: if your gonna flood it, please dump something useful ;)
gcarter: Well, here is something useful.
gcarter: Fedora 13 absolutely rocks.
gcarter: It solved all of my RV670 problems.
gcarter: I want to give airlied and the mesa guys on here a huge hug.
gcarter: Kiss.
rworkman: With 2.6.33 (no radeon kms though), xf86-video-ati-6.12.5, libdrm-2.4.18, xorg-server-1.7.5, things are not working as expected here on an "ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]" in an old T30 laptop...
rworkman: Starting X without an xorg.conf doesn't work at all; it attempts to start and then dies, leaving an unusable console. Doing "X -configure" to generate an xorg.conf creates this: http://connie.slackware.com/~rworkman/xorg.conf.new (which also doesn't work) -- notice the Driver line for the graphics card having "modesetting" in it?
rworkman: Perhaps I'm behind the curve (maybe that's obvious), but it's not obvious to me how all of this is supposed to fit together now, especially in light of the fact that we do not want to enable radeon kms just yet
spstarr: gcarter: with KMS your milage/km will vary - alot -
Jonimus: am I the only one who has never had issues since enabling KMS?
spstarr: depends on what you mean by issues
Jonimus: I have had 0 problems/crashes/whatever since enabling it and my performance for the games I play has been about the same in KMS and UMS
Jonimus: the only issue I've ever had with normal use is the occasional corruption of my window decorations but that goes away by simply resizing the window
gcarter: KMS works perfectly.
gcarter: Right now, I am using openGL to play full screen 720 HD videos, at around a 50 frames a second with mplayer. Before I think I got a frame every 3 seconds.
gcarter: Thats at 1920x1200
gcarter: Plus the whole desktop 3D affects with KDE 4.4.1 blows my mind. :-)
gcarter: I would like to point out, releasing Fedora 13 Alpha during the week of my midterms isn't helping.
gcarter: :-)
AndrewR: airlied, http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg19841.html ?
AndrewR: airlied, this is what current ttm tries to do, with PAT?
AndrewR: airlied, is this theoretically possible to switch gart type on the fly?
airlied: AndrewR: yes, glisse had some thought to do this
airlied: yes current TTM pretty much does thast
AndrewR: airlied, or have two versions aroun, and point card at right one ... nice ...
airlied: AndrewR: the gpu can do agp and pcigart at same time no problems I think
AndrewR: airlied, cool, even my old rv280?
airlied: yes, the driver needs some work to do it, not sure if glisse ever wrote the patches