mancha: perl -e 'print pack("C", unpack("L", "1234")), "\n"'
spstarr: glisse: sleep for me, let me know if you found something.... im back to UMS for now.
MrCooper: MostAwesomeDude, soreau: Are you guys actually getting working hardware acceleration from the classic r300 driver since the MRT compiler changes? I'm not...
soreau: MrCooper: building very latest now, but 3D is working for both classic and gallium as of now
MrCooper: for me it's falling back to software rendering because the fragment shader fails to compile
soreau: You mean runtime compilation?
soreau: Which card are you testing with?
MrCooper: RV350
soreau: huh. That is exactly what I have here
MrCooper: I'll post to the list
soreau: MrCooper: Ok, now I'm getting it only after latest updates
soreau: MrCooper: Even though glxinfo does not report swrast, glxgears is slow as hell
soreau: hm.
MrCooper: soreau: see my mesa3d-dev post
soreau: MrCooper: link me please?
agd5f: soreau: try LIBGL_DEBUG=verbose glxgears
MrCooper: soreau: you're in To:
MrCooper: agd5f: that's not enough, need some RADEON_DEBUG=...
agd5f: MrCooper: ok
soreau: http://pastebin.com/m15becb0b
soreau: gallium seems fine, classic is b0rken
MrCooper: soreau: RADEON_DEBUG=pixel,fall glxgears
MostAwesomeDude: MrCooper: It works for me but I had to do a make realclean before it would work w/o segfault.
soreau: yup http://pastebin.com/m314b751e
soreau: I have no idea what changed between now and then..
MrCooper: not getting a segfault, only either software rendering or black window
soreau: I never got black window
soreau: though someone else reported this (no gears)
MrCooper: MostAwesomeDude: surely OutputColor[1..3] can't just be left uninitialized?
MostAwesomeDude: MrCooper: I thought they could be. Maybe they need to be ATTR_UNUSED?
MostAwesomeDude: Are you on a pre-r500? There might be a difference in the shader emit.
soreau: I see now.. I never tested latest classic until now :)
soreau: MostAwesomeDude: Yes we're both testing with rv350
MrCooper: MostAwesomeDude: see my mesa3d-dev post for details
MrCooper: MostAwesomeDude: ATTR_UNUSED seems to be -1, I tried that but it still results in compiler failure
MostAwesomeDude: MrCooper: Hm, I'm trying to remember what I put in Gallium, I thought it was ATTR_UNUSED.
MrCooper: num_outpus
MrCooper: num_outputs even
MrCooper: so I tried FRAG_RESULT_MAX, that fixes the compilation failure but only gives black window
MrCooper: MostAwesomeDude: btw the indentation of your MRT changes doesn't seem to match the surrounding code
MostAwesomeDude: MrCooper: Sorry, it's cherry-picked from the days of the dinosaurs. Feel free to fix it.
MrCooper: no thanks
MrCooper: the whole thing seems rather rushed
MostAwesomeDude: Sorry, I had thought that it wasn't that intrusive, and now it's snowballed.
soreau: MostAwesomeDude: Sorry, I failed to test classic by a loop hole (in my testing system)
MostAwesomeDude: soreau: No, me too.
airlied: did anyone bisect it?
airlied: I assume its the compiler changes
MrCooper: most definitely
MostAwesomeDude: :T
MostAwesomeDude: Gimme an hour or three and I'll bash on it.
dileX: RADEON_DEBUG=pixel? is that new?
MrCooper: not really
dileX: seems not to exist
dileX: http://paste.debian.net/58536/
MrCooper: that's r300g, we're talking about the classic driver
dileX: OK, oh thats long time ago I used
dileX: ...I used r300-classic
airlied: okay I've hacked it to work here
airlied: okay fixes pushed
soreau: airlied: worksforme
MrCooper: airlied: thanks, though 0 is FRAG_RESULT_DEPTH, not sure that'll always work...
airlied: MrCooper: yeah not sure about that either, maybe they should all be FRAG_RESULT_COLOR
airlied: I'd have to get nha's advice at that level
airlied: nha: ^ :-)
soreau: nha! :)
airlied: realises I rebased rawhide mesa in the breakage.
airlied: guess I'll be redoing that tomorrow
soreau: :P
evil_core: no more blackwindow in non-gallium, but all is choppy now :/
taiu: how many gears should I be able to run, cant get more that 3 ;)
suokko_: MrCooper: That dpms gamma problem. Could it be related somehow to blackscreen with directcolor visuals?
suokko_: taiu: What happens wit more than 3?
MrCooper: suokko_: not sure but probably not directly
suokko_: Maybe I have to try if setting that xgamma will help there
suokko_: I already checked that xgamma returned all 1.0 when screen is black
taiu: suokko_: waits in xcb_connect_to_fd
suokko_: taiu: I can' run 4 with kms
taiu: suokko_: what's your chip ? now the 4'th appeared but 2 are running and 2 stopped
suokko_: To obad our scheduler is far from fair and some of gears are getting less GPU time than others
MostAwesomeDude: All gears are equal, but some are more equal than others.
suokko_: yes :) Clearly more equal
suokko_: On e of gears is running at 50-80 fps and others are running at 250-350 fps
suokko_: Yes. One of gears is clearly starved while others are sharing gpu quite equally
xming: all your gears belone to us!
suokko_: btw, I don't run any composite wm just now if it has any effect to number of gears
AndrewR: hello all. Should i crteate bug against drm-radeon-testing branch? (it looks like i have small regression in edid parsing)
suokko_: AndrewR: Can you bisect which commit is causing it?
AndrewR: suokko_, yes, just give me some time ....
suokko_: funny. Moving the gears window that was starving made gain fps to same level as others
AndrewR: suokko_, http://pastebin.ca/1776866 (dmesg). I have vga-switch-v4 applied here, reverting it anyway for bisect ...
suokko_: So the initial position where gears winow was created was someow bad. Because opening new one will make that gears runnig slow. After I move the window to new location it starts running smoothly
MrCooper: suokko_: there's no explicit mechanism to ensure fairness so it's probably random
suokko_: yes. But it is funny that moving the window helps
suokko_: Maybe cause for the problem might be something else
suokko_: Even running 6 gears same time only causes problems for one that haven't been moved
suokko_: But problems always stop if I move the window
suokko_: btw, Could be we somehow use CFS to select which applicaton gets GPU time?
AndrewR: suokko_, and don't forgot gpu_nice ...
MrCooper: as I said, we don't 'select' at all
MrCooper: though maybe that was what you meant: whoever manages to get into the KMS ioctls first wins
AndrewR: suokko_, does drm-radeon-testing detect any power management profiles on your rv280? For me it is always default, not sure if discrete (and not power hungry) GPU actually need this ....
mokoloko: compiled latest mesa and there is now yellow border with every window under kde4 :D
mokoloko: actually only the active window has those yellow 1cm wide borders
Ivanovic: hiho
Ivanovic: i got some "graphics issues" with KMS radeon, like i described in this forum post: http://www.phoronix.com/forums/showpost.php?p=110845&postcount=23
Ivanovic: in a later post another user posted two pics that show the issues, too:
Ivanovic: http://i48.tinypic.com/12479kw.png
Ivanovic: http://i46.tinypic.com/20pa4yc.png
Ivanovic: agd5f: you wrote in one answer that there are also some EXA bugs in xerver 1.7
Ivanovic: of course i am using gentoo unstable which comes with xorg-server 1.7.x
Ivanovic: (atm xorg-server-1.7.4.901 )
Ivanovic: what should i set in my xorg.conf to check if this really is EXA related?
Ivanovic: that is: which other render engines are supported?
mokoloko: [13:33]
Ivanovic: mokoloko: my impression is that it is related to kms, not mesa
Ivanovic: let's see, will reboot with plain old modesetting driver and retest
mokoloko: Is it only with active window?
MrCooper: it's a kernel regression
mokoloko: for you too
Ivanovic: mokoloko: active window plus taskbar
MrCooper: http://bugzilla.kernel.org/show_bug.cgi?id=15186
Ivanovic: there it is the prog entry, the workspace switching and the clock
mokoloko: yeah I got that taskbar thing sometimes too
Ivanovic: MrCooper: i already had this with kms since 2.6.32
Ivanovic: ;)
MrCooper: hmm
Ivanovic: brb
Ivanovic: now without kms
Ivanovic: there seems to be no issue!
Ivanovic: in both cases 2.6.33-rc5
Ivanovic: in both cases basically the same xorg.conf
Pallokala: do I dare to enable dynclks on KMD and RV630?
Ivanovic: MrCooper: and like i said, i had the same issues with kms in 2.6.32 (right from the beginning IIRC)
Ivanovic: that was the first time i really tested kms with my rv670 card
Ivanovic: so no idea if there was a regression in some previous kernel
Ivanovic: since it seems to not happen with the same mesa version i really assume that it is kms
Ivanovic: no idea how to provide more/better information beside a case of "me too"
dileX: nice "mesa/st: bump the gallium version number"
Ivanovic: makes no difference if i use xrender or opengl as render backend for desktop effects
Ivanovic: i'll post a comment in that bug report that i have the same issue as the original poster just that it makes no difference if .32 or .33 is used
MrCooper: Ivanovic: actually then it's probably not the same problem
Ivanovic: MrCooper: ah, lovely one then
Ivanovic: so there might be several things leading to the same symptoms?
boris64: Hi radeon folks, anyone else seeing these error messages (drm:radeon_cs_parser_relocs) in dmesg on r770 with newest git stuff (kms/kernel/libdrm/mesa/ddx), which leads into a kernel oops (-> http://paste.pocoo.org/show/173366/)?
suokko_: Ivanovic: What happens if you have multiple windows open? Does same rendering bug happen if there is another window under the shadow?
Ivanovic: suokko_: yes, it does not matter how many windows are open
Ivanovic: (i always have several open)
Ivanovic: okay, rc6 still has the issue
Ivanovic: suokko_: the easiest way for test me though is with compositing active and looking at the taskbar
Ivanovic: eg with a fullscreen thunderbird where the window title is longer than he space for the text
Ivanovic: there is is basically guranteed for me to get a black rect over the window title and the workpane switching thingie
Ivanovic: now testing if things look different with the patches glisse attached to http://bugzilla.kernel.org/show_bug.cgi?id=15186
Ivanovic: brb
Ivanovic: okay, looks like the patch (the last one) does fix those issues for me, too
joss193: /
Ivanovic: MrCooper: so it might be caused by the same / a similar problem
Ivanovic: now testing the if stuff
Ivanovic: okay, thanks everyone for pointing me to this bug report!
Ivanovic: i am done testing
Ivanovic: result: exactly the same as for Robert Schedel
Ivanovic: cf http://bugzilla.kernel.org/show_bug.cgi?id=15186#c14
MrCooper: Ivanovic: the 2.6.32 kernel probably isn't vanilla then but has some DRM changes merged in
Ivanovic: MrCooper: it is plain vanilla
Ivanovic: MrCooper: gentoo vanilla-sources are vanilla
Ivanovic: ;)
clever: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02)
MrCooper: either it's not as vanilla as advertised or it wasn't the same problem, whatever
clever: i'm having trouble getting this to output on VGA
clever: ive managed to get it into mirror mode (laptop lcd+vga) but the laptop is the primary, so XV overlay doesnt work on vga
Ivanovic: MrCooper: maybe some kind of race condition?
clever: any tips?
MrCooper: nope, 2.6.32 does the same thing as the patch
Ivanovic: MrCooper: really a strange one then
Ivanovic: looks like things are gone with 33-rc6 with the patch anyway
suokko_: clever: Sounds like a bug. For me OGL worked in secundary monitor when I last tested dual-head
clever: i didnt see anything for setting output in xorg.conf
suokko_: clever: ?
suokko_: How do you configure your dual-head?
clever: suokko_: i checked the man page for radeon and dont think i saw any way to pick the output
clever: but when i restarted X with vga connected, it automaticaly went into mirror mode
Ivanovic: you set things via xrandr
Ivanovic: and i think you can set the output where Xv is *might* be done via xv_attr
Ivanovic: tough if you got some r6xx card it does not matter, since Xv is done via the shaders, so no "overlay only on screen 1" or the likes
suokko_: clever: http://wiki.debian.org/XStrikeForce/HowToRandR12
clever: i'll give it a try when i get back home
clever: no VGA cables on me at the moment
suokko_: And textured vieo is done using shaders. Even with r200
clever: suokko_: i dont think this card can use XV as a GL texture though
clever: ive run into that problem when i was using compiz
suokko_: clever: That is not same
clever: ah
suokko_: compiz is rendering in top xv output because it doesn't know about xv (Doesn't have anyway to know without DRI2)
clever: suokko_: my nvidia card can use XV as a GL texture, so the video can show up in 5 places easily and will be effected by the eye candy
clever: compiz is capable of doing it right, if the hardware can also
suokko_: clever: yes. That why DRI2 is there
clever: got a link to more info on DRI2?
suokko_: I don't know any single source explaining everything in one place but non-technical articles can be found from http://www.phoronix.com/
suokko_: horonix is also quite good news source for linux graphics drivers
suokko_: There is also technical iew what it is at http://www.x.org/wiki/DRI2
agd5f: clever: if you are using the video overlay it can only be used with one crtc at a time. to switch toggle the XV_CRTC Xv attribute
clever: ok, i'll give that i try next time
agd5f: clever: textured video doesn't have the limitation, so if you use that, it will display on all heads and work with composite
agd5f: you can select the Xv adapter by the port number
clever: i'm always seeing something about xv port 67
agd5f: clever: xvinfo will show you the available adapters
clever: yeah, ive used xvinfo alot to try and find my XV cpu usage problems on gentoo
clever: for some reason it was using double the cpu
clever: turns out dma was off by default in xorg.conf and i had to force it on
lordmetroid: I love the open source drivers
lordmetroid: Even though it lacks features
CartoonCat: yay progress!!
CartoonCat: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
adamk: CartoonCat: Sounds like your libdrm and/or xf86-video-ati are not compiled with KMS support.
adamk: Either that, or the radeon kernel module is getting loaded too late in the boot process.
CartoonCat: adamk: maybe libdrm, xf86 was done per the instructions in the topic, so it .should. have it. How to test
adamk: CartoonCat: Well if libdrm wasn't built with KMS support, then xf86-video-ati definitely wan't.
adamk: wasn't, even.
CartoonCat: loaded to late? oh buggers
adamk: You could check the output of ./configure (for xf86-video-ati) to see if it says that kernel modesetting is enabled.
adamk: Yeah, sometimes X starts before KMS has kicked in.
CartoonCat: oh kms should be kicking in long before X
CartoonCat: i manual startx, and iirc kms is starting with the vga console doenst it?
adamk: Then it's almost certainly a matter of libdrm and xf86-video-ati not supporting KMS.
CartoonCat: i do not see a explicit kms check in xf86 ./configure
adamk: CartoonCat: Depends on when the radeon kernel module is loaded, or if it's compiled into the kernel.
CartoonCat: [ 1.425549] [drm] radeon: kernel modesetting successfully initialized.
CartoonCat: so that part looks ok (to me, but im often wrong0
CartoonCat: so xf86 and or libdrm
adamk: Yep.
CartoonCat: ok, ./configure does not have anything like "checking for kernel modeset" or such, i can pastebin it if you like
adamk: Not really necessary.
adamk: At the end, you'd see it if KMS was available.
adamk: You'll need to build libdrm.
adamk: The latest version from git has KMS enabled. Not sure of the minimum version necessary though.
CartoonCat: configure: X server has new mode code
CartoonCat: thats the only line i see with mode
CartoonCat: ok well that was interesting
CartoonCat: now i dont lockup when using driver radeonhd, but now it says screen 0 is nor DRi capable
CartoonCat: the only errors in xorg log is Unusupported PowerPlayInfo Revision and Power Management
suokko_: CartoonCat: I think you are trying to build 6.12.4 version of radeon that doesn't have KMS support
kdekorte: CartoonCat: when you compile libdrm did you add --enable-radeon-experimental-api to the configure line? And then when you recompile xf86-video-ati did it say kernel modesetting: yes
suokko_: or alternatively your configure script is from 6.12.X
CartoonCat: ah buggers
kdekorte: Also when recompiling libdrm and xf-video-ati do a make clean first, when enabling KMS
Nille02: Hey I have find my problem with kms. if I connect my siplay with DVI-0 its not working. the display suspend and nothing but if I connect my display on DVI-1 its works like a charm
kdekorte: Nille02: what card and what kernel?
Nille02: HD3850 and linux-next
Nille02: I want to try it later again with the kernel from my titry .32
kdekorte: are you using an adapter on your DVI-0?
kdekorte: and does xrandr show two dvi connectors?
Nille02: yes dvi -> vga and the card has 2 dvi and one tvout
kdekorte: I have a 3650 card that needed a quirk to get the DVI ports properly recognized
kdekorte: possible that the dvi-0 is not wired for analog signals that the dvi->vga convertor needs
kdekorte: might want to check your product manual and see if it says anyhing about it
Nille02: thanks for this tipp
Nille02: but on windows and non kms its working
Nille02: in around 4h I can test again
kdekorte: in the kernel in drivers/gpu/drm/radeon/radeon_atombios.c around line 192 there is a quirks table
kdekorte: might want to see if your card is in there
kdekorte: Nille02: what does xrandr report for ports on the card? does it have two DVI?
Nille02: yes DVI-0 and DVI-1
Nille02: I the past my display was on DVI-0
Nille02: but it works only on DVI-1
Nille02: with kms
kdekorte: if you do.. dmesg | grep drm, does it list both ports at DVI-I ?
Nille02: yes
Nille02: and all is fine in the logs
Nille02: are you later on?
kdekorte: Nille02: usually
Ivanovic: Nille02: order of device scanning was changed with kms
Ivanovic: so dvi-0 became dvi-1 and so on
Nille02: for an spezial reasson?
Nille02: because with this I get in troubble with dual boot
kdekorte: Nille02: Ivanovic, I ran into that problem to. I have to displays and when I was switching between KMS and non-KMS the positions kept flipping
Ivanovic: no idea if there was some reasoning behind this
Ivanovic: i just heard in here that this was the case
kdekorte: Ivanovic: I think it was the way ports were discovered in KMS, in non-KMS it walked the atombios tree one way, and in KMS the other
nha: airlied: MrCooper: MostAwesomeDude: if you were talking about r300_fragment_program_compiler::OutputColor this morning, the idea is that if unused, it should be different from all output registers, which is why I initialized them to the highest number; I realize now that maybe that's unwise if register numbers can have holes (can they? once upon a time I thought they couldn't [that's why there are explicit maps to semantic names] but maybe I
nha: was mistaken?)
nha: in theory, assigning -1 should also work (though it's an unsigned, so maybe ~0 would be more politically correct)
nha: also, hooray for MRT :)
suokko_: nha: btw, If we have negatie indexing in shader shoudl ew emit a add operation so that negatie indexing is changed to positive because no hw support for negative ones?
suokko_: Just the piglit asm parser test arl-01.txt is giving warning about negative indexing.
suokko_: nha: also piglit fbo-3d is assuming npot support
nha: suokko_: in principle yes, except we need to look at what happens with too large offsets, do they then work correctly?
nha: I think we'd have to carefully look at the range over which the addressing is done, and shift accordingly
nha: actually, that was a big annoying problem in Mesa, and I don't think it has changed: there is no information at all about which ranges are affected by relative addressing
nha: suokko_: oops
nha: (about fbo-3d)
suokko_: But even if I fix the depth then r200 is failing the test. Rendering is black white mess :/
CartoonCat: ok well, now mesa does not compile swrast_dri.so
CartoonCat: it did compile radeon_dri.so, and i put that in usr/lib64/
CartoonCat: so whats the deal now?
suokko_: CartoonCat: radeon_dri.so sounds wrong
suokko_: It probably should be r600_dri.so (if you have HD 3000+ card)
CartoonCat: suokko_: RS690, x1200
suokko_: CartoonCat: Then it is r300_dri.so that you want
CartoonCat: oy
FireBurn: Is the x1250 supported with the new r300g driver?
suokko_: yes/no
FireBurn: Err which is it?
CartoonCat: FireBurn: QuantumSupport!
suokko_: Log answer: It will be supported but r300g is still not ready
CartoonCat: so its just very buggy atm
FireBurn: Schrodinger's Gerbil
CartoonCat: suokko_: what do i need to do to get back to a palce to move forward from?
FireBurn: Do you know what's supported on it
suokko_: FireBurn: r500 cards have the best initial support because MostAwesomeDude is testing r300g with r500
suokko_: CartoonCat: You probably need to do configure again
suokko_: --with-dri-drivers=swrast,r300
CartoonCat: and that would be for mesa, or xf86 ?
suokko_: mesa
suokko_: for ddx you just checkout the master branch and do the autoreconf && ./configure
suokko_: wait
CartoonCat: that was done, and it said it had kernel mode setting
suokko_: good
suokko_: Did you do make clean && make && sudo make install?
CartoonCat: for? mesa? ddx ?
suokko_: ddx
suokko_: mesa needs that too if you have run configure again
CartoonCat: i think so, but im all discombobulated now
CartoonCat: ddx is drm-2.4.17 ?
CartoonCat: going over my notes i dont see a ddx, oy
suokko_: ddx=xf86-video-ati
CartoonCat: doh
CartoonCat: it was installed at some point, but i have nfc what its stae is now
CartoonCat: state*
CartoonCat: i want ot say "it looked like it worked right"
suokko_: Do you know where it is installed?
suokko_: ie. What was prefixthat you used for configure
CartoonCat: i used the line right out of the howto, so where ever it does it
CartoonCat: ./autogen.sh --prefix=/opt/xorg && make && sudo make install, and in /opt/xorg/lib/xorg/modules/drivers/ is ati and radeon_drv
suokko_: CartoonCat: Then you just need the xorg.conf line
suokko_: mesa can wait for later
CartoonCat: ok
CartoonCat: suokko_: the module load line is already there
suokko_: So now if you start it should detect KMS and start correctly
CartoonCat: what would i see in the xorg log to tell me if it detected it correctly or not
suokko_: (II) [KMS] Kernel modesetting enabled.
suokko_: And no (EE) lines from radeon
CartoonCat: well i dont have a KMS, and ive always had the EE for power settings and Unusupported PowerPlayInfo Revision
suokko_: Did it load radeon_drv from /opt....?
suokko_: (II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so for me because I'm usin system one just now
CartoonCat: http://pastebin.org/85968
suokko_: aah, It is loading radeonhd
suokko_: You need to put radeon in xorg.conf
CartoonCat: it is =\
CartoonCat: mesa # cat /etc/X11/xorg.conf | grep radeon
CartoonCat: Driver "radeon"
adamk: What was the first release of xf86-video-ati with 2D acceleration for r600/r700?
suokko_: egrep -i "(radeon|drm)" /var/log/Xorg.log
CartoonCat: maybe it failed back to radeonhd ? if radeon failed? oy, ill restart x
CartoonCat: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
CartoonCat: stil getting a mismatch
CartoonCat: time to hose it all and start over
suokko_: CartoonCat: Can you paste the whole log?
suokko_: There is next few lines that would tell a lot more wwht is going wrong
CartoonCat: sure, i just git pull'd xf and it had some changes so ill recompile that
suokko_: CartoonCat: That error which you have looks a lot like some build conflict. Meaning that you have something too old in your system
CartoonCat: im guessng its leftovers from gentoos xf86/mesa/libdrm
evil_core: ecause of KMS
evil_core: get newer xf86-video-ati
CartoonCat: i just merged then unmerged em with a flush so hopefuly that wil deal with that
evil_core: or disable kms
CartoonCat: bah why is wgetpaste failing
chithead: wgetpaste -s ca
CartoonCat: evil_core: KMS is working great on the kernel side, now its ot get xf86 working
CartoonCat: http://pastebin.ca/1786225
evil_core: so get master xf86-video-ati
CartoonCat: ty ty chithead
evil_core: stable xf86-video-ati will not work with KMS(DRI)
evil_core: ;DRI@*
CartoonCat: evil_core: I have master, its compiled, it was isntalled, but i think something was left over from gentoos packages
evil_core: DRI2*
chithead: you were told multiple times that your xf86-video-ati is too old to support dri
chithead: (II) Module radeon: vendor="X.Org Foundation"
chithead: compiled for 1.6.5, module version = 6.12.4
adamk: CartoonCat: Did the ./configure stage in xf86-video-ati say that kernel modesetting was enabled?
evil_core: so you must install it
CartoonCat: adamk: Yes it did
chithead: it was obviously not installed properly
suokko_: CartoonCat: Loading /usr/lib64/xorg/modules/drivers//radeon_drv.so
CartoonCat: chithead: yes obviously, but how can I knwo that when it didn error on install
suokko_: So it is loading your system radeon
chithead: CartoonCat: what suokko_ said
adamk: CartoonCat: Did you specify the correct path with --with-xorg-module-dir when you ran configure?
suokko_: CartoonCat: So my guess is that you have some typo in xorg.conf modulepath config
suokko_: This doesn't look correct: http://paste.debian.net/58621/ offset for levels after first one are way too huge in my option
airlied: nha: the issues was with the callback stuff it ends up in get_used_ptr and index >= RC_REGISTER_MAX_INDEX
airlied: if we init the OutputColor to an illegal value
nha: ah, of course
LordVan: hi.
LordVan: anyone know how support for Radeon HD 5750 is coming along?
adamk: 2D is available via user modesetting from the radeon driver in git.
adamk: There is no 2D or 3D acceleration, though KMS support should arrive relatively soon, hopefully.
wirry: but now accelation yet
okias: http://pastebin.ca/1786275 - lastest git kernel, this errors was probably trigered by KDE4.4 splash screen
okias: on splash screen didn't appeared Icons, only in place of first icon damaged texture, which flicker..
okias: I updated mesa in same time, so it can be too mesa bug, but I don't use either XrendeR or OGL...
Neo_The_User: thanks agd5f for r8xx support!
suokko_: okias: Can you bisect that error?
suokko_: Did it work before correctly?
okias: suokko_: yep
okias: suokko_: but about bisecting - it's really slow machine :-( Celeron 2,6G
okias: last working kernel was somewhere about rc4...
suokko_: okias: You can limit bisecting to drm directory only
suokko_: And then only rebuild the drm&friends
suokko_: git bisect with path drivers/gpu
okias: suokko_: I try that as last option, I have drm compiled into kernel..
suokko_: Then it won't be so easy :/
suokko_: make SUBDIRS=drivers/gpu is very nice command
Obscene_CNN: airlied, I have a question about the drm code in the kernel. In the file radeon_fence.c in function radeon_fence_emit the variable irq_flags is passed to other functions but not initialized is this a bug (kernel2.6.33-rc2) ?
Ivanovic: MrCooper: okay, it was all the same issue
Ivanovic: early in the 2.6.33 cycle it was fixed though for a short period of time, cf http://bugzilla.kernel.org/show_bug.cgi?id=15186#c15
Ivanovic: MrCooper: so this explains things, rigth?
Ivanovic: ;)
shadowmaster: print $winname
airlied: Obscene_CNN: no
Obscene_CNN: okay
Obscene_CNN: it just doesn't make sense though
Obscene_CNN: its an uninitialized value and as passed as a value (not a pointer to a value) so a value can't be returned.
airlied: Obscene_CNN: its a macro
Obscene_CNN: oh
Obscene_CNN: okay
AndrewR: suokko_, i was wrong, i don't know good commit in drm0radeon-testing tree ..may be something wrong with config there, or with tree itself. But reverting all i2c and power management patches doesn't help me with wrog X resolution. But Linus's main tree works excellent
AndrewR: just in case someone want to look at doom3-demo segfault on rv280 KMS current Mesa: http://pastebin.ca/1786451
AndrewR: ops, my mesa not so current anymore .... git pull
honk: mhh.. I've got 2 4850 cards in my system (for crossfire in windows) - is there any way to shut down the unused card while in linux? :]
glisse: agd5f: can you check if there is anythings special with 0x5480 (hdp flush on r6xx/r7xx) when used through the ring
glisse: the regression doesn't make much sense
glisse: unless writing this reg through ring is a nop
glisse: anyway enought r6xx/r7xx playing, i am still wondering what make those user having this corruption
glisse: zzzzZZZZzzz
Nille02: glisse: are you there?
agd5f: glisse: I don't see anything special with regard to the ring, but if it works via mmio, and not ring, stick to mmio
Nille02: mybe you remember my problem with the display that shutdown if i try to use kms. the problem is that the use DVI-0 as DVI-1 and DVI-1 as DVI-0 with kms. and if i plug my display in DVI-1 the xserver work
chithead: doesn't the kms numbering of displays have an offset of 1?
Nille02: (II) RADEON(0): Output DVI-0 disconnected
Nille02: (II) RADEON(0): Output DIN disconnected
Nille02: (II) RADEON(0): Output DVI-1 connected
Nille02: but the display is in DVI-0
agd5f: glisse: some regs are only accessible via the ring, e.g., WAIT_UNTIL on R5xx. in this case perhaps the reg is only accessible via mmio
airlied: agd5f: when w ewere hitting the flush reg direct on r300 we were getting hangs
airlied: its annoying ;-)
suokko_: Is Z buffer tiled in r200?
airlied: suokko_: yes
airlied: oh wait thats a trick question
airlied: but I think yes
suokko_: because glReadPixels is reading Z buffer in tiled order
suokko_: But returned values are incorrect
airlied: some of the chips always tiled some had optional
suokko_: But whole Z buffer should be same values so that is not causing read errors ...
suokko_: Then next problem is if Z buffer is accessible to radeon_span
airlied: "The depth buffer is always tiled and there is no possible way to turn it off."
airlied: that answers that then,
airlied: its from the R200 docs
suokko_: glClearDepth();glClear();glReadPixel(GL_DEPTH_COMPONENT); is failing
agd5f: airlied: well, the hdp reg seems to work via the ring on r3xx, it's just r6xx/r7xx that's broken
airlied: agd5f: so we should do it different on each then ;-)
agd5f: airlied: exactly
airlied: suokko_: fail
agd5f: only chip were you could get a non-tiled z buffer was rv100
airlied: the r200 Z code came from the docs
agd5f: IIRC
airlied: yeah I think that was it
agd5f: suokko_: it might have broke when brianp reworked the surface formats lots of Z stuff broke
agd5f: probably got switched from z24S8 to s8Z24 or vice versa
suokko_: Problems is that Z buffer is all junk
suokko_: After _mesa_meta_Clear should have just cleared it
suokko_: All pixels to single value
agd5f: suokko_: I don't think meta clear will work on Z
agd5f: since it's tiled
agd5f: I thought we bailed on meta clear for depth
suokko_: It just renders single quad with z test set to always
airlied: meta clear should work since it uses the hw in the end
Nille02: or someone else know why the desktop is not working if i plug my display on DVI-0 ( kms think its DVI-1)
suokko_: Maybe there should be some flush before ReadPixels is passed to sw handler
suokko_: Just in case if Z buffer is kept in cache
airlied: suokko_: we flush the Z cache after drawing
Nille02: i get the problem he is try to start the xserver with 1024x786 but kms use 1280x1024 and if i force the xserver to use 1280x1024 its work
suokko_: Nille02: sounds like time for a bug report
suokko_: unless it was your xorg.conf having some old modelines
Ivanovic: agd5f, glisse: if you want some tests done in my env (as in "if you got a patch to check") feel free to post it in the report
Nille02: it was more or less empty
Ivanovic: (that is regarding those strange corruptions that seem to be "rather common" on r6xx/r7xx hardware with kwin
Ivanovic: anyway, i should already be deep asleep, night
Nille02: suokko_: http://noctarius.pastebin.com/d3caeab40
Nille02: and if i uncommend the preferredmode line i get broken tty
suokko_: Nille02: Are you sure that your ddx supports KMS?
Nille02: yes
suokko_: airlied: Where is that flush code?
suokko_: grep -In ZCACHE returns no hits in r200
airlied: suokko_: damn this could be embarassing
toastedmilk: Does the Radeon driver work for X1900 in 9.04 for OpenGL?
suokko_: airlied: I guess that could explain random rendering errors with r200 in some games
airlied: suokko_: wow if we are missing cache flush that is quite bad
suokko_: toastedmilk: yes
airlied: suokko_: I'm hopefully just not awake enough to find it
agd5f: airlied, suokko_: IIRC, the idle ioctl did it on ums
suokko_: r200_reg.h doesn't have hits either
airlied: I think its DSTCACHE
airlied: agd5f: can you find it? I'm scared if we don't have that code.
airlied: who let glisse go to sleep
suokko_: So it is in kernel side only so KMS doesn't emit it
agd5f: airlied: it's in radeon_cp.c in the pre-kms drm
airlied: yeah I'm not finding it for KMS ;-0
agd5f: that might explain the r1xx/2xx bugs with kms :)
airlied: I used to do it in my old kms code
airlied: seems Jerome's rewrite lost some more stuff
airlied: agd5f: and r300
airlied: I can't find it for that either
airlied: though we should have idle flushing
agd5f: in theory WAIT_UNTIL should flush all caches
airlied: like it should happen befreo we emit the fenecs
airlied: agd5f: with idle flushing yes that should happen
airlied: wonders if works ;-0
agd5f: me too
airlied: most of the r100/r200 wiedness were due to the state emission be bogus
airlied: not emitting state for large parts of the gpu in mesa wasn't so good
agd5f: we do it explicitly the draw commands on r600, but it should probably be moved to the drm
suokko_: OUT_RING(RADEON_RB3D_ZC_FLUSH | RADEON_RB3D_ZC_FREE);
suokko_: But then question is when that should be emited.
suokko_: I guess always when comman buffer is flushed
airlied: suokko_: after every CS before enceing
airlied: fencing
suokko_: kernel or mesa?
airlied: since fences rely on it being flushed
airlied: kernel would be best place to start I supose
airlied: at least to see if it improvesl ife
toastedmilk: Does anyone know the terminal command(apt, perhaps) to see if I have any remaining fglrx packages installed?
suokko_: aptitude?
toastedmilk: yeah, that worked.
okias: hmm, something doesn't seems to be ok: http://pastebin.ca/1786561
okias: R200 work, but that errors wasn't in dmesg before...
suokko_: Is there anyway to read the data in vram with gdb?
airlied: suokko_: no it sucks
airlied: if you can find the surface offset
airlied: ou can read it from the resource files in sysfs
airlied: or the other thing I used to do was make mesa dump it to a file
airlied: when it hit the span code
airlied: yay seems to build an rpm now
suokko_: airlied: Depth largest readback error was 0.317413 bits
suokko_: So that fixed a glean test
airlied: suokko_: glean being too pickY?
airlied: or the cache flushing worked?
suokko_: Before I reloaded the kernel module it was 23 bits max error
suokko_: That test allows a bit error
suokko_: one bit that means
suokko_: so cache flush fixed it
suokko_: I did add cache + zcache flush+free to r100_fence_emit
suokko_: *ERROR* Cube texture offset greater than object size 71584 69632
suokko_: But I don't understand what would cause it now suddenly
suokko_: airlied: The cache flushes also fixed random rendering bugs in sauerbraten
airlied: suokko_: woot send patch to list and beat glisse on way past ;-)
suokko_: airlied: Maybe that is causing the glyph corruption too
suokko_: if there is no cache flush from ddx after some operations
soreau: MostAwesomeDude: compiz++ crashes with gallium http://sprunge.us/LhCj any idea why?
MostAwesomeDude: soreau: You configured with --enable-debug, right?
MostAwesomeDude: Oh, found it, looking.
soreau: MostAwesomeDude: It crashes with compiz-0.8 too http://sprunge.us/cXNe
soreau: probably the same thing
soreau: MostAwesomeDude: It should have --enable-debug, the bt points to the lines in the r300 code
soreau: with classic, compiz works
MostAwesomeDude: soreau: Run again with RADEON_DEBUG=fp and give the error message it puts out?
soreau: ok
suokko_: airlied: What about the fixed libdrm patch for section mismatch? That would prevent users from getting huge useless log file with bogus errors
soreau: MostAwesomeDude: Here is the additional output http://pastebin.com/m2dcfe4c7
MostAwesomeDude: Hm.
MostAwesomeDude: Yeah, there are five texture indirections but that hardware can only deal with four.
MostAwesomeDude: Which plugin causes this?
soreau: no idea, but the log points to #7 0xb72c7880 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 whatever that is
MostAwesomeDude: Well, the error is pretty straightforward and understandable.
MostAwesomeDude: Compiz is asking too much. There's no real way to check for this; I'm sending off an email to the rest of the Gallium devs.
soreau: Well, it wasn't doing this before the mrt addition :P
MostAwesomeDude: Really.
MostAwesomeDude: Oh, duh. Before, it wasn't using MRTs.
MostAwesomeDude: Either that, or I badly biffed on this MRT code. :T
soreau: MostAwesomeDude: Seems alpha blur is the culprit somehow
soreau: Specifically, gaussian alpha blur
airlied: suokko_: oh I should push that
soreau: but with classic it works, so idk
MostAwesomeDude: soreau: You can use GALLIUM_ABORT_ON_ASSERT=0 to force it to not die, but I'd be careful.
airlied: suokko_: pushed the libdrm fix
soreau: MostAwesomeDude: That seems to be ignored as it still dies with compiz: r300_fs.c:205: r300_translate_fragment_shader: Assertion `0' failed.
MostAwesomeDude: soreau: Weird.
soreau: MostAwesomeDude: I think mrt addition is doing more harm than good as I'm noticing less performance with classic, crashes with gallium and no 'pro' to the 'cons'
MostAwesomeDude: >:T
MostAwesomeDude: I don't think I was prepped enough on the compiler changes.
soreau: MostAwesomeDude: seems something else broke alph blur with classic before the mrt addition so alpha blur's not working on classic anyway. However with gallium, alpha blur works before mrt addition without crash
soreau: not sure what broke alpha blur on classic though so that might be worth a bisect
soreau: actually it crashes with classic too, I'm confusing myself I think
soreau: I'll do some concentrated tests and get back with some results
agd5f: airlied: http://people.freedesktop.org/~agd5f/r600_curb_cache_flush/
agd5f: gets a small performance boost in mesa and ddx
cxo: I get a gem object lookup failed error with the current git
cxo: then a "failed to parse resolution"
cxo: drm:radeon_cs_ioctl *ERROR* Failed to parse resolution !
cxo: gdm tried to start x twice, it started and then crashed, worked the 3rd attempt. text was blurred on the screen, but after logging on desktop looks ok
cxo: this problem wasnt there on Friday
airlied: agd5f: interesting
cxo: Had to revert back to 33-rc5, X was just too unstable
jesse_wk: hi
jesse_wk: i am wondering why the firmware can't be found here
jesse_wk: r600_cp: Failed to load firmware "radeon/RV630_pfp.bin"
soreau: Did you review the link in the topic here?
mancha: hi airlied, have you had a chance to look at vram/gtt fragmentation problems on "low" mem setups yet?
jesse_wk: soreau: yeah, but that's for another firmware
jesse_wk: soreau: the one that's missing here is already in kernel and in /lib/firmware
soreau: What is giving you this message?
jesse_wk: if i boot in runlevel 3 with nomodeset, and modprobe radeon modeset=1, it can work
jesse_wk: dmesg that's it
jesse_wk: one min
jesse_wk: http://dpaste.com/154351/
airlied: jesse_wk: initrd?
jesse_wk: airlied: i am not sure, i just point the bootloader to what the kernel installed
jesse_wk: to /boot
jesse_wk: but the bootloader is extlinux, if that matters
jesse_wk: maybe i hit this debian bug, Radeon kernel modesetting requires pre-initramfs firmware loading, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550392
jesse_wk: ?
airlied: sounds like it
jesse_wk: airlied: thanks, i will look more into it
Jonimus: I'm getting some corruption in neverball on my HD4670 mobile
jesse_wk: but, it seems radeon doesn't respect CONFIG_FIRMWARE_IN_KERNEL=y ?
Jonimus: it worked fine on my Desktop with the HD4850 so I'm not sure what the issue was
spstarr: airlied: if you still have that W500 you're not seeing text glyph corruption with -rc6?
spstarr: in KMS, UMS is fine
Jonimus: http://thestorm.taricorp.net/Uploads/neverball.png
airlied: spstarr: not near it at the moment
spstarr: ok
Jonimus: any Ideas on that corruption?
Jonimus: or should I just submit a bug report with that screen shot?
spstarr: some heat improvements in -rc6 w/o KMS
spstarr: 68C instead of 75C
pepee: hi
pepee: I can't see the tty. kernel 2.6.32, driver radeon from a ubuntu ppa
pepee: anybody?
spstarr: .32 is so outdated now
spstarr: your playing with fire
spstarr: this code is in rapid development
pepee: hmm
pepee: do you recommend the normal ubuntu version
pepee: anyway, wich is the kernel option for recovering the tty?
pepee: i had the same problem before, but i don't remember it...
taiu: airlied: btw i timed the bo mapping change in radeon_dma, the results are 55 and 66 in openarena and 13,8 -> 15,9 fps in nexuiz
airlied: taiu: so worth reverting then
taiu: this was Pentium4 with rv740 and head and with the patch reverted