airlied: its already in the kernel
soreau: ok thanks
agd5f: airlied: found the problem. radeon_encoder->active_device isn't set at fixup time
airlied: ah oops
agd5f: I guess I should use radeon_encoder->devices
qtqt: is it possible this segfault is caused by the radeon driver? http://pastebin.com/d24d04b85
agd5f: but how to deal with TV vs VGA for fixing up the mode
agd5f: qtqt: update your driver
fudje: wow I remember that one....
airlied: agd5f: do you have the connector?
agd5f: airlied: I could probably get it
airlied: you might need to try the set_encoder
airlied: something like set_ active device does early
agd5f: airlied: maybe radeon_encoder_set_active_device() in encoder_fixup()
airlied: I wonder what the side effects of moving prepare up are
agd5f: or radeon_encoder_set_active_device() at the top of fixup and and then clear it at the end
airlied: yeah it we fail we need to put back what was there
agd5f: well, prepare() touches the hw
agd5f: so if fixup fails, we need to restore it
agd5f: airlied: actually it might be ok since crtc_funcs->mode_set() can fail too
soreau: airlied: This is what happens when I try to boot current drm-next http://omploader.org/vMmpqcg
fudje: I presume you don't have console scrolling at this point?
airlied: soreau: can you boot nomodeset then modprobe radeon modeset=1
soreau: airlied: I built everything into the kernel :P
fudje: that was silly :P
airlied: probably not the best idea ever
soreau: Well it loads kms immediately when booting the kernel which is nice me thinks :P
soreau: when it works of course
soreau: But I guess I can rebuild it out of kernel for testing
soreau: Or.. as a module I mean
fudje: soreau, do you init initramfs?
fudje: use*
soreau: fudje: No, just vmlinuz
soreau: What all would I need to build as module? Just radeon?
fudje: radeon, drm, agpgart if you use it....
soreau: ok
airlied: radeon/drm is usually enough
soreau: Alright, rebuilding now
fudje: Following on from before, would it be preferred to fall back to PCI mode (and have rully rully slow accel) when AGP turns out to not actually be available, or whinge about it and stop loading?
agd5f: airlied: radeon_encoder_set_active_device() in fixup seems to do the trick
agd5f: also cleans up the atom dpms function as a side effect
agd5f: airlied: sent a possible patch to the list
El_Angelo: quite annoying that the source of mesa comes with all this glew crap
El_Angelo: isn't it possible to use a configure flag to throw that out?
El_Angelo: --disable-demos
El_Angelo: or something
El_Angelo: afaik that is not there now
dileX: El_Angelo: look what ./configure --help tells you
El_Angelo: dileX: are you sayint it's there? or are you just guessing?
dileX: I know
El_Angelo: cause obviously i did take a look at configure --help
El_Angelo: then i don't see it :s
El_Angelo: --disable-glw --disable-glu but that doesn't seem to be related to glew?
El_Angelo: or is it?
dileX: then log your build - then you'll see the configure options set
El_Angelo: is Glw the same as glew?
dileX: El_Angelo: sth like this
El_Angelo: yes i have that too
El_Angelo: now i'm completely confused
dileX: El_Angelo: dont think you have the same, because I set some configure-params individually
El_Angelo: well
El_Angelo: not the same
El_Angelo: but i don't see the difference that matters :s
El_Angelo: the word glew is not in your config.status
El_Angelo: and in mine neither
dileX: (get the mesa source of your distro, see their c-p setttings)
El_Angelo: dileX: i am the distro maintainer
El_Angelo: untill now we have always just deleted everything related to glew
dileX: which distro?
El_Angelo: why does that matter?
MostAwesomeDude: glw and glew are two different things
dileX: El_Angelo: curiosity?
El_Angelo: lunar
El_Angelo: http://paste.debian.net/49063/
El_Angelo: this is mine
El_Angelo: grmbl
El_Angelo: stupid thing didn't copy the macros
El_Angelo: dileX: mind sharing your configure command?
qtqt: ok so i upgraded the radeon driver and it still segfaults http://pastebin.com/d113cff40
dileX: El_Angelo: its special and for testing r300g now
dileX: (and for building from GIT)
qtqt: does it still look driver-related or shld i take this back to #xorg?
fudje: qtqt: Any particular reason for using Xinerama?
qtqt: because i'm trying to do multiple cards and xrandr doesn't seem to support that yet
fudje: Ah, I see that now :)
fudje: Although, I think that's an entirely different crash from the one you were having before. It does look driver related though.
qtqt: yeah :) here's the xorg.conf for that also FWIW: http://pastebin.com/d50b2c745
qtqt: oh, ok
fudje: I'm just wondering whether using EXA instead of XAA would fix it, but you'd get no acceleration without DRI, which is turned off because of Xinerama....
fudje: But if you're using multiple cards, yeah, xrandr is not an option.
qtqt: acceleration would be nice, but i can also try that and see if that isolates the problem
El_Angelo: what are those state-trackers?
El_Angelo: --with-state-trackers[=DIRS...]
fudje: Gallium stuff.
fudje: You probably don't want any for distro packages at this point?
qtqt: would i want to do Option "AccelMethod" "exa" on all 3 device sections?
El_Angelo: indeed
El_Angelo: i still don't see how i can disable glew related stuff from being built
El_Angelo: guess i'm just stupid
MostAwesomeDude: There will be pain and suffering if you enable Gallium for a distro. Just sayin'.
El_Angelo: i won't
qtqt: oh wow that actually did something
fudje: qtqt:
fudje: whoops
fudje: http://lists.freedesktop.org/archives/mesa-commit/2009-February/006706.html
fudje: (That's for El_Angelo)
El_Angelo: grmbl
El_Angelo: thnx fudje
fudje: You could try patching configure.ac....
El_Angelo: imho that makes no sens at all
Pallokala: hi
Pallokala: is there any tricks for improving the performance of sdl-games like openttd?
dileX: [08:40:40]
dileX: El_Angelo: ^^
fudje: qtqt: what did it do?
qtqt: getting the log for you
El_Angelo: patching glew seemed to have helped
El_Angelo: thnx fudje
El_Angelo: actually implementing a --disable-glew would help even more :) but this is something that works for me
qtqt: i've never seen X do this before ... so I have what looks like one screen - i think? - spread across the Gateway and the Dell, but the gnome desktop is actually too big for it and when i move my cursor to the bottom the whole thing scrolls down with the cursor. very strange
fudje: I bet it's very slow.
qtqt: here's the log http://pastebin.com/d6cea34b5
qtqt: fudje: yes you're right it is!
qtqt: the X2gen on the PCI card is still dark tho
fudje: Odd, your log suggests that render acceleration is working with EXA... I didn't think that was possible without DRI :/
soreau: airlied: I've been trying to capture the output of modprobe radeon modeset=1 without success. I tired '> output 2>&1' and even tried sshing in to capture it but the output goes to the box I'm sshing into
fudje: soreau: It should show up in /var/log/syslog on that box
fudje: Or if you run 'dmesg'
soreau: fudje: It seems to be there in /var/log/messages.. how do I tail the last 50 lines or so?
fudje: tail -n 50?
fudje: 50 lines sounds an awful lot though
soreau: fudje: Thanks
fudje: qtqt: I think, at this point, the problem you're having is that multiple cards is broken in Xorg by now. You could, conceivably, try adding to the Extensions section of xorg.conf: Option "RANDR" "Disable"
soreau: airlied: Here is the output http://pastebin.com/m4d4e930b
fudje: I don't know how well it'll work though
fudje: LOL
qtqt: heh i'll give it a shot
qtqt: but i did have a creeping feeling that i'm fighting the inevitable
fudje: soreau: I'd almost put money on that it's trying to derefence rdev->ddev->agp and it's NULL
soreau: fudje: What's that supposed to mean?
fudje: soreau: It means your AGP bridge is not loaded properly
qtqt: maybe i'll have 3 heads in 2011, or go back to ubuntu hardy heron :)
qtqt: thanks for the effort tho, it's appreciated
fudje: soreau: Can you `modprobe -r radeon' on that system then `modprobe radeon modeset=1 agpmode=-1'?
soreau: I will try, bbiab
fudje: I'm pretty sure I've been getting the same error for the last week, but on a r600
airlied: soreau: forget agp support? we might need some more ifdefs
soreau: fudje: You were right
fudje: airlied: I'm pretty sure I've tracked down the problem on that one and ifdefs won't help
soreau: I am in X now
soreau: from drm-next kernel
fudje: soreau: Not neccessarily right per sé
fudje: however, are you on an amd64 system?
soreau: Nope, x86
qtqt: oh wow this is weird i don't even have a console anymore
fudje: hmm.
soreau: hmm indeed
soreau: airlied: What I did was make agp as a module as well as drm
soreau: So what is going on here
soreau: ?
airlied: did you load an agp bridge driver?
airlied: normally i keep agp built in
soreau: Well I thought you said to make radeon as a module and in order to do that, ... hmm
soreau: I think I got confused
soreau: There is Radeon under DRM and Radeon under AGP support
soreau: So back to the drawing board I guess
fudje: but I think you're oopsing at radeon_agp.c line 137
fudje: I need to re-break my system and workaround again, I'll get back to you
soreau: airlied: To be clear, I want AGP Support built in and AGP Support>Radeon[?] and then DRM as module and DRM>Radeon[?]
soreau: I am confused now
fudje: soreau: can you pastebin lspci?
airlied: didnt think there was radeon agp option
soreau: airlied: It says ATI chipset
fudje: that's not radeon ;)
soreau: fudje: lspci -nn | grep VGA?
fudje: um no
fudje: interested in PCI bridges at this point
soreau: http://pastebin.com/m6fba9bf9
soreau: Well I think I know what you're getting at and what I am doing wrong
fudje: :)
fudje: Before you fix it though
soreau: Since I have intel mobo/bridge, I probably want AGP>Intel and not ATI chipset
soreau: Is that correct?
soreau: Because I had Intel and ATI agp enabled before but took it out since the merge conflict about intel
soreau: just tries it
fudje: Ack I've broken my build tree completely now
El_Angelo: am i correct to assume that swrast is installed best by default?
airlied: blames oq in r300g not working on some other parts of r300g
fudje: http://pastebin.com/d2e84c81c <-- Should stop it from causing an oops
fudje: but you still wouldn't have working drm
fudje: I'm not sure whether I should do that or try to force it to fall back to PCI...
airlied: yeah probably should fallback up a levl if that happens
fudje: I wonder, is there any way to check that before entering chipset specific code
fudje: I mean, I was just going to write to fallback into r600.c but if it's affecting other chipsets, ...
soreau: airlied: That was my fault for not building my kernel right. Works now but I have video=VGA-0:800x600 for kernel parameter and it still does 1280x1024 and confines the output to the upper 800x600 portion of the screen
MostAwesomeDude: airlied: Might be better to blame it on not being line-for-line copied from r300 classic. :3
fudje: soreau: That and the driver doesn't bother to check if it actually has an AGP bridge to acquire
soreau: fudje: Ok. Thanks for the enlightenment :)
soreau: I had always suspected I should have only agp>intel but I always compiled both just in case
fudje: Mmm, it always helps to know what device you actually have. Mind you, that doesn't always help; I'd though for the last couple of years that I wanted the VIA one because I have a VIA 8237R/K8M800 AGP bridge, but it turns out that in fact I need the amd64 one.
soreau: go figure
soreau: is wondering if 'video=VGA-0:800x600' is the correct kernel param syntax
fudje: Apparently it'd because AMD64 cpus do weird stuff, or something....
airlied: soreau: if your connector is VGA-0 yes looks fine
airlied: MostAwesomeDude: it is now ;-)
MostAwesomeDude: airlied: Does it work?
airlied: MostAwesomeDude: no, hence my TODOs getting slowly worse
airlied: though it could do with testing on a !rv530
MostAwesomeDude: Hm.
MostAwesomeDude: Sounds like you've adopted my coding philosophy.
MostAwesomeDude: "Sure, it doesn't work, but now it's much more elegant in it's failure to work."
soreau: tries video=800x600
fudje: "If it breaks, put it on the TODO list and forget about it"?
MostAwesomeDude: *its, even. Grammar fail.
airlied: summons nha ;-)
fudje: wishes unlinking kernel trees was a little faster. Maybe three or four orders of magnitude.
airlied: MostAwesomeDude: no idea how to do the last ZTOP test
airlied: need nha to figure that out
MostAwesomeDude: airlied: Force it to bottom for now. The docs aren't clear on it, but (5) Can't do ZTOP when doing OQ.
fudje: unfortunately I think I need a new tree...
MostAwesomeDude: So for pretty much everything, it needs to be on the bottom for now.
airlied: MostAwesomeDude: the only one missing now is the FP uses kill case
airlied: I've ported all the others
MostAwesomeDude: Ooh, that one's icky.
MostAwesomeDude: I have a strong feeling that we're going to have to move ZTOP to the derived state then.
airlied: sounds likely
airlied: though I'm not really up on the gallium state stuff yet
MostAwesomeDude: Basically, if it can be set up independently of the rest of the card, it belongs with the state object that sets it in Gallium.
MostAwesomeDude: Otherwise, it's derived, and we've gotta calculate it right before flush.
MostAwesomeDude: *s/flush/draw/
airlied: oh also the arbocclude text doesn't render which is annoying
airlied: busted on rv410 as well
MostAwesomeDude: I noticed that. It just hangs; if you check in gdb, it's waiting on a BO map.
airlied: no I fixed all that
MostAwesomeDude: Oh.
airlied: it runs now, but misrenders and doesn't print out the value
MostAwesomeDude: Hm.
airlied: works fine under softpipe
MostAwesomeDude: Everything works under softpipe though.
airlied: indeed
airlied: I'll wait until the other bits are more fixed until I tackle it again
soreau: Seems to work with video=800x600 but compiling radeon into the kernel causes that error
soreau: The one I showed a pic of :P
MostAwesomeDude: Hm. Looking over patches now.
MostAwesomeDude: I hate how RV530's gotta be special-cased.
MostAwesomeDude: Is there a reason to not add R300_NEW_QUERY to R300_NEW_KITCHEN_SINK?
airlied: MostAwesomeDude: how would you propose doing rv530 any dufferenT?
airlied: sounds stupid to suggest not special-casing a special case
MostAwesomeDude: airlied: No, it's the right way to do it. I just hate that it requires the special-case.
fudje: it's simple
fudje: employ ninjas to replace all rv530 chips with something else
airlied: MostAwesomeDude: its not really special, the hw works like that
airlied: it would be a shit driver that didn't reflect how the hw works
MostAwesomeDude: I know. It's just icky.
airlied: it should be in NEW_KITCHEN_SINK
MostAwesomeDude: And also ce5cba040 is wrong.
MostAwesomeDude: Or I think it is. Lemme take a closer look.
airlied: oops< I thought it was all fs
airlied: adds now
MostAwesomeDude: Yeah, okay.
MostAwesomeDude: So that's definitely wrong, but I had it wrong too.
MostAwesomeDude: Need to move the ZTOP state out of DSA.
airlied: MostAwesomeDude: it should be CSO stuff then, you can probably do that better than me
MostAwesomeDude: Yeah, just gotta move it to derived and set up an atom for it.
MostAwesomeDude: Hm. While I'm at it, I really should create CSO keys for shaders.
MostAwesomeDude: IIRC ZTOP's controlled by by just z_buffer_top, right?
airlied: yes AFAIK
soreau: I figured it out
soreau: If AGP support is compiled as module, radeon support can't be compiled in or else it will cause problems
soreau: (well agp support was compiled in but agp>intel was compiled as module)
fudje: that's broadly correct.
airlied: MostAwesomeDude: I get the feeling we'll have to overhaul the whole cmdbuf stuff like classic driver
airlied: we raelly need to know how much CS we have left and when to kick it out early
airlied: running ipers just falls over in a heap
MostAwesomeDude: Unfortunately, I don't know if we can do anything better than check at the beginning of each dirty emit.
MostAwesomeDude: The good news is that only shaders have variable size, and we can measure things easily.
airlied: well we may have to "fix" gallium ;-)
MostAwesomeDude: But Gallium's allowed to rebind state at just about any time.
MostAwesomeDude: Personally I'd rather "fix" our lack of HW contexts, as long as we're wishing for things. :3
soreau: Awesome, everything woeks now
soreau: works too
airlied: we don't have hw contexts though
airlied: so fixing that would involve doing r600 ;-)
soreau: airlied: The deal with video= so I figured out is it needed to be VGA-1 not VGA-0 (as xrandr shows)
airlied: soreau: oh crap bitten by backwards compat creap
airlied: I might rip that out
soreau: :)
soreau: I just got a hunch and tried it
airlied: if you look in /sys/class/drm u can see the real one
soreau: much nicer to have the boot output fill the screen
airlied: MostAwesomeDude: I might ask Zack/Keith about how best to work it
soreau: is content
airlied: even if we do it before a flush we may have some variable size things
MostAwesomeDude: airlied: Please do. Also, I've got patches to use caps for blitters.
airlied: I suspect we should rework the whole flush mechanism like i965
soreau: airlied: $ ls /sys/class/drm \n card0 card0-DVI-I-1 card0-SVIDEO-1 card0-VGA-1 controlD64 ttm version
MostAwesomeDude: You mean, the chipset for which there's no working driver? :3
airlied: MostAwesomeDude: no I mean the classic i965 ;)
airlied: instead of the big if (NEW_X), emit NEW_X, clear NEW_X thing
glisse: soreau: it should fallback to pci ?
airlied: we have a struct with ->check, ->emit, ->state
glisse: what did happen when intel wasn't builtin ?
airlied: glisse: see fudje patch above
airlied: if agp acquire fails
airlied: glisse: http://pastebin.com/d2e84c81c
airlied: MostAwesomeDude: then we can just to a check loop to work out the CS size in advance
airlied: flush or don't flush, then do an emit loop
soreau: glisse: http://omploader.org/vMmpqcg :)
glisse: oh yeah this check is good :)
mcgreg: hi ... "AMD Releases OpenCL ATI GPU Support For Linux" is still flgrx-only?
soreau: Now I have this other bug that is somewhat annoying but I'd probably have to file a report about it
soreau: After starting X with S-video plugged in, compiz ezoom works but the upper 800x600 remains static (does not zoom) until setting S-video --*-of VGA-0, then works even still when setting S-video back to --off
airlied: blames compiz, sounds like a bug with overlapping xinerama geometries
soreau: So.. how do you change resolutions for outputs in tty?
soreau: from CLI
airlied: not yet
soreau: Ahh :)
soreau: Very cool that it is already working as kernel param. I like it a lot :)
soreau: Now that I have all warnings and boot up looking pretty good, maybe I can figure out how to install a boot splash for gentoo :)
MostAwesomeDude: airlied: Just built and pulled, and I get a CS section loop and segv.
MostAwesomeDude: *pulled and built, even.
MostAwesomeDude: Nevermind, got it now.
airlied: hehe. make clean ftw ;-)
fudje: Yay now I have a working pair of trees
hoo-hah: hello
soreau: hey-hoo-hah
hoo-hah: soreau: hey man
airlied: MostAwesomeDude: http://people.freedesktop.org/~airlied/clueless_attempt_one.patch but that is just the really dumb version
airlied: and also doesn't actually work
MostAwesomeDude: Hm. Have you tried dumping the OQ BO to see if it's actually getting written to?
SmallCat: are you guys trying to make glsl to work? or what is that fragment_shader standing?
SmallCat: also vertex_shader
airlied: MostAwesomeDude: well it changes
airlied: since I write 0s to it first
MostAwesomeDude: Shouldn't that be ~0 ?
MostAwesomeDude: 'Cause 0 is perfectly legal to return.
airlied: ye I wrie those ;-)
airlied: I didn't change that from your code really
MostAwesomeDude: Hm. I thought I got the logic right, but I'm not totally sure now.
MostAwesomeDude: I probably wrote it in the same 2AM frame of mind as right now. :3
airlied: yeah I think that bit made sense
dileX: hola, r300g pushes :-)
mikkoc: airlied: do you have any idea about what's going on here: http://bugs.freedesktop.org/show_bug.cgi?id=24218
airlied: mikkoc: nothing springs to mind, I have an rs780 in the office I'll see if I can steal some time to boot it
mikkoc: airlied: ok, well, mine is a 785g chipset, but it loads rs780, not sure what's the difference
SmallCat: MostAwesomeDude, the current status for radeon&Mesa, perf of vertexes and shaders, do they work+textures?
MostAwesomeDude: SmallCat: Yep.
SmallCat: MostAwesomeDude, nice,then are you sure you'd like to make glsl the hard way, driver way, it ends up as different interface for all chips, plus lot of chip specific code, plus generally difficult to program?
MostAwesomeDude: SmallCat: That's not what we're doing at all.
MostAwesomeDude: GLSL is turned into an intermediate representation by Mesa/Gallium, and then each driver assembles that IR into hardware-specific instructions.
MostAwesomeDude: We do a similar thing for the older vertex and fragment programs too.
airlied: kdekorte: did you test that vanilla kernel I forget?
MostAwesomeDude: Hm. For a simpler goal, we should get readPixSanity working.
SmallCat: MostAwesomeDude, ok, see you might be really capable of doing so, and gallium , i saw little bit of that one also, but i think it lacks the flow, mesa tokenizes glsl too
MostAwesomeDude: SmallCat: Gallium can do it. Have faith.
MostAwesomeDude: airlied: readPixSanity, yeah? :3
SmallCat: MostAwesomeDude, ah maybe, i'm not sure, but it didn't include those 19 defines like i965 and libsh have, or probably i just didn't notice that part
SmallCat: in airport i tried to analyze that cooldavid front-end too, maybe got opened half of files there, but i thought that one, woudn't force flow on as well, if there isn't any NVp/f extension that takes care of those ops
fudje: quit
fudje: gah
fudje: /'s help
MostAwesomeDude: airlied: Pushed the ztop stuff, tried to get it to belong to context instead of dsa but for some reason it wasn't going for it.
MostAwesomeDude: I'll look at it again tomorrow. Hopefully Dr_Jakob can shed more light on CSO then.
adamk_: :q
adamk_: D'oh.
arkascha: My X server/graphics card locks the moment any of the desktop effects from kde are used. By locks I mean a blank screen, and no reaction to keyboard, no switching to a virtual console.
arkascha: The system itself is accessible without problem via network. I use Xorg on a Radeon X1550 board on an x86-64 running opensuse-11.1.
arkascha: Any hints what might be wrong ? I did not encounter any problems weeks ago.
arkascha: Only after upgrading some two weeks ago these problems started.
arkascha: xorg-x11-7.4-53.1
arkascha: oh , right, OpenGL compositing is active. x
soreau: use a real compositing wm ;)
twoerner: how good will a 57xx or 58xx work with xf86-video-ati and mesa from GIT?
chithead: twoerner: not at all
adamk_: twoerner: There is definitely no 3D acceleration and I doubt even modesetting works yet.
twoerner: not even accelerated 2d ?
chithead: the drivers have no pci ids for the cards yet, so will not even attempt to do anything with them
twoerner: this is something, that could be changed easily ...
chithead: twoerner: patches welcome
adamk_: There is also no guarantee that simply adding the pci ids will work.
SmallCat: MostAwesomeDude, i'll try for first time, looks like all 10 main worries went off, actually most of them very quickly really, like multi-master etc. but i don't know 3.0 at all, and which changes that could bring, and even if another libsh thread works, i get so far and bliting the same backbuffer with libsh shaders produces flicker, then i don't know what to do
twoerner: i am thinking of buying a new card 4770 or 5770, therefore the question
soreau: twoerner: If you want to use the open driver with 3D right away, go with the r700
chithead: I understand that agd5f has received some cards and is working on it. so if you check back in a week or two, you would probably get more information
soreau: wonders how different r6-7xx is from r8xx
soreau: chithead: Ah so they finally got some, eh?
twoerner: soreau: i have heard that a 4770 will have problems with the drivers as well - is that correct?
chithead: 4770 works with 2d and 3d acceleration
twoerner: chithead: ok
adamk_: twoerner: Well the drivers are relatively new for that card, but they mostly work.
soreau: twoerner: 3D support is relatively very new, so you may have some minor issues
adamk_: There is still lots of room for improvement.
soreau: ;)
da1l6: id
twoerner: soreau: i am using the drivers with a 2600XT and a 3870 - these are mostly ok
da1l6: nm
adamk_: twoerner: So what problems did you hear about with the 4770?
twoerner: image corruptions for example
soreau: twoerner: If I am not mistaken, those are both r6xx which uses the same code for r7xx
twoerner: s/image/screen
adamk_: Yeah, I doubt you will see any more corruption with the 4770 than you would with the 3870.
soreau: gets some minor corruption in some games even on his rv350
soreau: tests the game with latest drm-next
soreau: Hmm.. seems the ezoom bug has disappeared..
amarks: 2D on r600/700 is still not bug free, but somewhat usable
soreau: Nope, still here
soreau: along with the X crash I am able to reproduce with et
amarks: soreau: your on gentoo yes?
soreau: Yes..
soreau: amarks: Why?
amarks: totally off topic, do you use firefox
soreau: I have it installed, yes.. *wonders where this is going*
amarks: see http://forums.gentoo.org/viewtopic-t-796476-highlight-.html
amarks: it's bugging me
amarks: wondering if you've experienced it
soreau: Well, you are completely correct
soreau: This is completely off topic for this channel ;)
soreau: (and no, I have not experienced such)
amarks: ok thanks
soreau: Use chromium. It's nice
amarks: i stick google squarely in the "search engine" only corner
amarks: but i'll take a look
BeteNoire: hi, is there any particular reason for segfault caused by free driver at the end of shutdown?
hoo-hah: chromium is crap
hoo-hah: sure its fast, but you lose out on functionality provided by fx extenseions
hoo-hah: extensions*
hoo-hah: imo
soreau: hoo-hah: I just installed it the other day. What is fx extensions?
hoo-hah: firefox :)
hoo-hah: soreau: I just found the howto on putting the firefox profile in tmpfs
hoo-hah: page load is more responsive
hoo-hah: awesome stuff :)
mcgreg: the only real good browser is opera :P
hoo-hah: back when 1.44 FDs were the main transfer medium ;P
dileX: cool: Updated R5xx 3D Programming Guide
soreau: wonders if r3xx will ever have AA caps
BeteNoire: where do i post bugs about free driver, can you remind me?
jcristau: bugs.freedesktop.org
rouhiai: Hmm... are the powersaving features for older radeon cards going to be ported to work with KMS drivers?
rouhiai: Currently my Mobility Radeon 9000 needs the radeonfb module to be loaded, if I want to keep it suspended properly. Without it my battery life is shortened dramatically while the laptop is in suspend mode.
rouhiai: And if I have understood correctly the radeonfb module conflicts with KMS.
dileX: rouhiai: yes. # CONFIG_FB_RADEON is not set
mokoloko: tried latest fedora snapshot 20091011 and madriva 2010 rc2 both kde and moblin variant ---> all froze as soon as I got on the desktop, so I was wondering if this was related to the new radeon driver stuff for my radeon 4850 card?
mokoloko: Just wondering, because well that hasn't happened before :D meaning last couple round of ditsros (last spring and autumn)
adamk_: It is certainly possible. If the previous distributions were using a kernel older than 2.6.30 then you didn't have direct rendering enabled in the X server.
mokoloko: yup 2.6.27 and 2.6.29
adamk_: mokoloko: Does the entire machine lockup? Any chance you can login remotely from another machine?
mokoloko: Yup I have to press the power button to boot
mokoloko: Can't switch VT's... Nothing responds
mokoloko: Can't try login remotely
adamk_: It will be hard to debug without access to the machine. I guess you can start by determining if it really is related to direct rendering by disabling DRI in your xorg.conf file.
mokoloko: Alright will try that, but mainly I was just interested to see if something like that has happened lately for someone else?
adamk_: Personally I haven't heard of anything like thta.
mokoloko: well will come back to whine if this happens with fedora 12 beta cd's :P
sannes: In the danger of jinxing it, after a bios update, I have had no problems with running kde4 with compositing and running nexuiz (for hours) with kms and dri2 ..
SmithyUK: Hi all. I have just set up debian on my machine. Have used fglrx and compiled all that in using module assistant, but pretty sure X is not using it as window movement is not smooth and so forth. My guess is teh xorg is not properly configuerd, but it certaily looks like it's pointed at the fgllrx drivers. Can anyone advise what I should check, please?
adamk_: SmithyUK: Check the open topic please.
SmithyUK: oops, apologies
kdekorte: sannes, what card are you running?
sannes: rv770
kdekorte: mokoloko, I've been having the same problems with Fedora 12, there is a bug report maybe you could contribute to http://bugzilla.redhat.com/show_bug.cgi?id=517625
kdekorte: sannes are you using your own kernel or one from your distro?
sannes: kdekorte: 2.6.31.y + drm-next
kdekorte: sannes, yeah that is a good combination
sannes: kdekorte: I think what was happening for me was that memory was corrupted and fed to the card somehow .. X actually crashed once without me doing anything special and logged a corrupt path in the log .. so, I did two things, one I set the governor to ondemand instead of performance and updated the bios .. and after that I have had no crashes .. atleast not of 8h of kde4 usage with wobbly windows and a couple of hours in nexuiz (altough it is slow when played un
mokoloko: kdekorte: sure
agd5f: mokoloko: on some systems (especially toshiba and asus laptops) the bios sets up the mtrrs wrong
mokoloko: this is normal desktop with some asrock motherboard and pentium dual core 2Ghz@3.2Ghz (that overclock hasn't caused any issues ever)
kdekorte: sannes, I've had issues with the Fedora kernels, but not when I roll my own and it does seem like a missing flush at times
kdekorte: Possibly could be a compiler optimization as well
glisse: kdekorte: did you tested the kernel airlied built for you ?
kdekorte: I didn't see where it was hosted... the message scrolled off before I got it
agd5f: taiu: did you see my comments yesterday about the r6xx/r7xx trig functions?
kdekorte: glisse, do you know where that kernel is?
taiu: agd5f: yes, got it
glisse: kdekorte: http://koji.fedoraproject.org/scratch/airlied/task_1742695/
agd5f: taiu: cool
kdekorte: glisse, thanks
kdekorte: taiu, have you looked at bug #24281, I know you looked at that code before...
taiu: kdekorte: haven't had time to implement ...
taiu: there's some other oddities to do this properly
kdekorte: taiu, ok, just wanted to make sure that bug didn't get lost as it affects the output quite dramatically
taiu: e.g piglit tex-indirections where 2 adjacent tex intructions use previus one's output - this produces garbage
taiu: i believe in this case they have to be separated to separate clauses
taiu: agd5f: another one also, WPOS provided to fragment shader - from quick look at piglit test I feel that y what is provided seems inverted
agd5f: taiu: I didn't quite parse that.
taiu: agd5f: seems y 0 is top of window i think ogl has y0 from bottom
agd5f: taiu: ah
agd5f: taiu: we should start tracking this stuff on the dri wiki
agd5f: I'll start an r600todo page
taiu: good idea
kdekorte: glisse, that vanilla kernel seems stable... can't make it crash like I can the normal fedora kernel
kdekorte: glisse, however I have colormap issues only on the second display with that kernel that I don't have with git kernels
kdekorte: oh that is really funky... I have a texture that when spanned across two displays the left side is perfect, the right side it outlined
rnoland: agd5f: FRAG_ATTRIB_WPOS appears to be handled ok, any reason it isn't enabled?
rnoland: FOGC possibly as well...
rnoland: haven't tested that yet though.
agd5f: rnoland: not sure. probably never got enabled. taiu noted some issues with WPOS
kdekorte: agd5f, I have a picture of this weirdness I am seeing, do I bother opening a bug on it, or should I just talk to airlied
kdekorte: since it is a custom kernel he rolled for me
rnoland: agd5f: well, i'm re-running piglit now with WPOS enabled....
rnoland: so we will see
taiu: rnoland: no reason, just oversight afaik
rnoland: taiu: ok...
agd5f: kdekorte: file a bug and attach the pic
kdekorte: ok
rnoland: will finish testing and make up a patch...
agd5f: added http://dri.freedesktop.org/wiki/R600ToDo
rnoland: agd5f: y0 inverted?
agd5f: rnoland: read the scrollback
marvin24_: agd5f: interrupts?
agd5f: marvin24: in progress
marvin24_: so not "todo"
marvin24_: ;-)
agd5f: marvin24_: ah yes. feel free to add that
marvin24_: agd5f: do you have some prediction when it will be finished?
agd5f: marvin24_: it's written already. just got to figure out why they aren't getting re-armed properly
marvin24_: agd5f: thanks!
kdekorte: agd5f, fdo bug #24528
rnoland: why does the depthstencil test suck so hardd?
taiu1: :) I guess it reads the depth buffer quite a lot
rnoland: it all but kills my machine for the duration of that test.
taiu1: and the formula to calculate the correct pixel is quite a piece
taiu1: see r600_1d_tile_helper in radeon_span.c :)
otaylor: Hmm, there shouldn't be any pitch constraints for render-to-texture, should there?
rnoland: error: [drm:pid85085:radeon_cs_ioctl] *ERROR* cs->dwords too big: 16393
rnoland: agd5f: should this get broken up into more chunks?
agd5f: otaylor: nothing more than the hw requirements
agd5f: rnoland: yes, it should be flushed earlier
otaylor: agd5f: mm, but the hardware requirements should be hidden behind the scenes right?
agd5f: otaylor: yeah
rnoland: agd5f: ok, so silly question.... where should that occur?
agd5f: rnoland: I think the accounting is broken in certain cases
otaylor: What I'm seeing is if I create a texture with a non-multiple-of-16 width, and then use glFramebufferTexture2D to render to it, the rendering happens with the wrong pitch
rnoland: agd5f: well, i've not seen this before today....
rnoland: i'm getting it in vdrift now...
otaylor: (I think it's non-multiple-of-16, might be non-multiple-of-8)
agd5f: rnoland: bisect?
rnoland: of course i have been running piglit
hnsr: is it a known problem with current (or yesterdays) git drm-next/xf86-video-ati that colors in X are a bit.. off? everything seems more blueish than it does with fglrx and my other machine with nvidia (sharing same monitor)
rnoland: agd5f: well, i just enabled WPOS and FOGC in r700_assembly.c
rnoland: but i'm not sure if that is impacting it or not....
agd5f: rnoland: I don't think it should, but I'm not sure if they generate any additional state beyond the shader itself off hand
tzaeru: odd how NWN and Spring both end up with such a low performance
tzaeru: while I can play TC:E and Tremulous just fine, which are FPS games.
rnoland: agd5f: i still find r600_cs_process_relocs() very hard to grok....
rnoland: it does some rather odd things...
mjt: folks, I asked this for some 10 times already for about 4 days but got no answer so far.. what to do with screen corruption in kms case?
agd5f: rnoland: what about it?
rnoland: agd5f: for one, the test for asicoffset >= eoffset is inside the loop where neither value changes...
mjt: i mean like this one for example: http://www.corpit.ru/mjt/radeon-kvm-corruption2.jpg
rnoland: so that should probably move up before the loop.
rnoland: but more specifically should it actually exit(0) or return -EINVAL is another question.
rnoland: and ...
rnoland: cs->packets[relocs[i].reloc_indices[j]] = 0xC0001000;
rnoland: /* reloc index in ib chunk */
rnoland: cs->packets[relocs[i].reloc_indices[j] + 1] = offset_dw;
rnoland: that doesn't really make sense to me yet....
agd5f: it appends the reloc packet info to the command stream
otaylor: mjt: you can file a bug and try to characterize the problem and how to reproduce it exactly, and hope someone fixes it
agd5f: rnoland: anything in the command stream that requires a reloc includes reloc info after it in the command stream
mjt: otaylor: file a bug where?
agd5f: 0xC0001000 is a packet 3 no-op
agd5f: so the CP just skips it
otaylor: mjt: bugs.freedesktop.org
mjt: oh
agd5f: but we use it in the drm to look up the base address for the bo and fix up the stream before submitting the hw
agd5f: offset_dw is the offset into the reloc stream we send to the drm
agd5f: that's where the drm looks up the bo info
agd5f: the asicoffset >= eoffset check could be moved outside the loop
rnoland: should it exit or error?
agd5f: probably just error
agd5f: exit is probably left from early days
mjt: otaylor: thanks!
rnoland: my experience before fixing WPOS was that i got a 0 size buffer and returning -EINVAL allowed it to continue
rnoland: though it did crash a short while later...
rnoland: so it does screw things up if it just errors and returns... but i'm not sure which is worse...
agd5f: 0 buffer size most likely means the shader failed to compile which isn't handled properly yet
otaylor: rrb->pitch = texImage->Width * rrb->cpp;
otaylor: Shouldn't that be
rnoland: i'm sure we should do something if it returns error....
rnoland: agd5f: right, it was barfing on WPOS
otaylor: rrb->pitch = texImage->RowStride; ?
agd5f: rnoland: r600_cs_emit() checks the return and bails if it's an error
rnoland: ok....
agd5f: otaylor: probably
otaylor: agd5f: will test once I get mesa to set up to build on this machine
PsyMan: http://www.corpit.ru/mjt/radeon-kvm-corruption2.jpg <-- this definately looks like wrong panel info
rnoland: agd5f: actually... should radeon_bo_legacy_validate() return error for a 0 length buffer?
dileX: MostAwesomeDude: your g-b mesa-branch is compileable. glxgears fine with r300g. openarena fails (black screen)
agd5f: rnoland: probably
rnoland: ok, let me fix that up and send you some patches...
rnoland: sigh, the inconsistent whitespace in mesa makes me crazy....
El_Angelo: (EE) RADEON(0): Timeout trying to update memory controller settings !
El_Angelo: (EE) RADEON(0): You will probably crash now ...
El_Angelo: hmm
El_Angelo: 2.6.32-rc4, mesa git, libdrm git, xf86-video-ati git on r700
MostAwesomeDude: dileX: Thanks for the testing.
MostAwesomeDude: I anticipated that that branch would be fine for now.
MostAwesomeDude: I need to add the actual fallbacks though.
El_Angelo: is there anything i can try?
okias: Hello. Any idea, why I getting this: [drm:igp_read_bios_from_vram] *ERROR* bad rom signature
okias: and why lastest ddx still refuses use DRI2/3D with lastest kernel (.32-rc4)?
agd5f: okias: you can ignore that
agd5f: that's a surround view check
okias: agd5f: oki, thanks and what about lastest ddx version mismatch (2.0 and 1.77 or what)
rnoland: agd5f: ok, patches in your inbox...
rnoland: my comfort level working in mesa isn't that high... so either feel free to commit them or tell me too...
rnoland: oa, ut, and nexuiz seem good with them.... still not sure why crashing in vdrift is bugging the kernel though.
BeteNoire: hi, anyone can help with this bug https://bugs.freedesktop.org/show_bug.cgi?id=23623 ?
Plouj-: hi
Plouj-: is there a list of active developers for this driver?
hnsr: i guess you could look at the git commit logs
airlied: kdekorte: thanks for that, me tries to figure out what the next step is
kdekorte: airlied, your welcome
kdekorte: you're welcome
kdekorte: airlied, any idea what could cause the funky colors on only the second display?
airlied: kdekorte: grab the latest -ati from koji
airlied: http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-ati/6.13.0/0.10.20091006git457646d73.fc12/
airlied: nha: btw you can probably add the ztop for fs usess kill test interface I wasn't sure and I don't think MAD did it
MostAwesomeDude: I didn't, no.
nha: airlied: k, thanks for the info
MostAwesomeDude: I also couldn't figure out how to not piggyback on the DSA state.
MostAwesomeDude: Not sure why.
MostAwesomeDude: But putting the ZTOP register in its own struct, or in the context directly, led to bad things for some reason.
airlied: still hasn't reached his first goal of making texrect work
airlied: I can only blame the fragment shader
kdekorte: airlied, rebooting into vanilla kernel and new ati driver
airlied: it draw either texture on its own, but texture 1 seems to GL_REPLACE not GL_ADD texture 2
airlied: that should be texture 0
nha: airlied: is this on R300 or R500? is it related to texcoords, or what's wrong? does it not work for 2D textures?
kdekorte: airlied, with the vanilla kernel and the new ati driver from koji I still get "lava" on the gdm screen
kdekorte: but only on the second display
airlied: nha: 2d textures are busted as well
airlied: multitexarray test
airlied: nha: on an r500
nha: okay
nha: airlied: which tests are failing exactly?
nha: it might be just any test, but who knows
airlied: mesa progs/tests/ multitexarray and texrect
airlied: compared to sw rendered
nha: okay
airlied: I wasn't brave enough to figure which piglit test was comparable
nha: that's fine
nha: but my todo list for the weekend is just getting longer ;)
airlied: well I'll try and get some time to look at it, but I'm travelling this weekend/next week
airlied: I might bring the r500 laptop but its heavy
nha: well, I need to protect the reputation of r300/compiler and show that the bug is actually in r300g ;P
MostAwesomeDude: XD
MostAwesomeDude: Finding the bug for readPix would be even better IMO.
nha: my clone hasn't arrived yet, and I can only do so much ;)
airlied: nha: i'd believe it is, I just don't know where
airlied: the fp isn't really that complex
airlied: two texture reads + an add
airlied: kdekorte: could you attach a dmesg from a broken kernel to the bug?
kdekorte: broken, one were it locks up?
airlied: yup
airlied: I'm playing guess the Fedora patch that screws us game.
kdekorte: ok...
nha: do *any* multi-tex applications work? I remember that there's some register fields to map the texture ids in the shader to the texture image units, maybe those aren't set up correctly?
airlied: nha: I haven't seen any
airlied: those two demos are the simplest ones so I'd guess not
kdekorte: airlied, I;ll get you a working and a broken and diff them...
airlied: mjg59: how do I turn off aspm at boottime?
airlied: or am I crazy for blaming it for possible gpu related fail
nha: airlied: see TX_FILTER0, the highest nibble is an ID field
airlied: nha: oh I see it in the legacy driver, sneaky (hw_tmu << 28)
MostAwesomeDude: hat.
airlied: I forgot about that, I'll see if I can sneak sometime today
MostAwesomeDude: Stupid sticky w key.
MostAwesomeDude: *ahem*
MostAwesomeDude: What.
nha: MostAwesomeDude: btw, I saw you mention a CSO for scissor and viewport
nha: does that even make sense? Are any calculations necessary to derive the register state for scissor and viewport?
MostAwesomeDude: nha: I'd like to have them, yes.
nha: I mean, the main point of those caches is to avoid doing expensive recomputations
MostAwesomeDude: It's not really that important, I guess.
kdekorte: airlied, is the a patch for the pci_cache_line? Appears that there is in a broken kernel, can I disable that on the kernel line somehow?
MostAwesomeDude: But it's maths that doesn't require any context.
nha: MostAwesomeDude: The code in set_viewport_state is trivial; I bet that if you introduced a hash table to cache results, it would actually be significantly less efficient than it is now
nha: same goes for scissor
MostAwesomeDude: nha: Alrighty.
airlied: kdekorte: kdekorte oh can you pastebin the dmesg?
dileX: airlied: Documentation/kernel-parameters.txt says: pcie_aspm=off (see
kdekorte: airlied, the diff?
kdekorte: or both of them
airlied: kdekorte: the full broken one should be enough
kdekorte: give me a sec
airlied: kdekorte: also yum install nopaste
airlied: then you can dmesg| nopaste
kdekorte: airlied, broken kernel -> http://pastie.org/655092
kdekorte: diff between broken and working -> http://pastie.org/655098
airlied: kdekorte: can you try pcie_aspm=off on the comand line to see if it fixes broken kernel
airlied: dileX: thanks.
mokoloko: tried todays fedora 12 snapshot and it still lock ups (radeon 4850) :'(
dileX: airlied: n.p.
airlied: kdekorte: I might try making a git tree with some Fedora patches in it later so we can track down the crazy one
airlied: the cacheline one seems like a good place to start,
kdekorte: airlied, rebooting with pcie_aspm=off, mokoloko you might try that too see if it helps
mokoloko: will do
kdekorte: airlied, switching to console and back fixes the gdm color issues "lava" on the second display
kdekorte: also with pcie_aspm=off I haven;t been able to lock up the machine yet, normally I could do it by now
mokoloko: what does it do exactly?
airlied: active power management stuff
mjg59: airlied: What kind of fail are you seeing?
MostAwesomeDude: It's SATA power management, isn't it?
airlied: mjg59: kdekorte above
kdekorte: airlied, yeah I would say that is the thing that is causing the lockup...
airlied: mjg59: gpu lockups with aspm turned on
kdekorte: mjg59, machine will hard hang when doing simple scrolling in gnome-terminal (up and down about 5-6 times) with dmesg in the window
mjg59: What card?
kdekorte: airlied, I also tried my video application using clutter, resizeing the window rapidly (that used to trigger it to) and that worked fine
kdekorte: mjg59, rv635
mjg59: Right
mjg59: So we need to be able to disable it on a per-chipset basis
mjg59: Sigh, etc
mjg59: Hm. Though, Vista enables by default.
kdekorte: the question is, is that feature in the linus kernel, cause I only see it using a fedora kernel
mjg59: So I wonder if we're just doing something more latency sensitive?
mjg59: It's there, but not on by default
airlied: mjg59: is it chipset or pcie device fail?
mjg59: I was meaning the gpu
kdekorte: mjg59, what kernel flag enables it, cause I use the Fedora .config
airlied: disable it for all VGA class devices ;-)
mjg59: kdekorte: It's a patch to the fedora kernel
kdekorte: so I can check and see if it is enabled in mine
mjg59: It's not enabled by default in upstream
kdekorte: mjg59, in my kernels that work I have this CONFIG_PCIEASPM=y
mjg59: 21:29 < mjg59> kdekorte: It's a patch to the fedora kernel
mjg59: 21:29 < mjg59> It's not enabled by default in upstream
kdekorte: I thought that flag would enable it? or is there more to the patch
airlied: mjg59: can you enable it at boot on non-fEdora?
mjg59: Yes
mjg59: pcie_aspm=force
kdekorte: let me try that
airlied: mjg59: got a pointer to a what aspm does?
airlied: I suspect gpus probably have some "special needs
kdekorte: mjg59, booting with that option on the kernel line, is there a way from dmesg to determine is forced on?
airlied: agd5f: maybe you can ask around internally
mjg59: airlied: The chipset and pcie device negotiate to place the link in a link power saving state
mjg59: kdekorte: printk(KERN_INFO "PCIe ASPM is forcedly enabled\n");
mjg59: airlied: It's specced in the pcie docs - you should be able to grab them from the pci sig website
kdekorte: mjg59, ok it is on... let me see if I can crash it
kdekorte: airlied, well with it forced on one of my kernels, I can't lock it up...
kdekorte: there is did it...
kdekorte: took it little longer
kdekorte: machine is not hung hard... just X
kdekorte: X is using a full CPU... but I am still getting audio out from a video
airlied: it looping wiating for the gpu
kdekorte: yeah, seen that before
airlied: mjg59: http://support.microsoft.com/kb/937500 hehe.
otaylor: agd5f: I was on the right track, but it was a little more complex - https://bugs.freedesktop.org/show_bug.cgi?id=24533
airlied: bridgman: you might want to ask around about ASPM issuse with GPUs for us inside
MostAwesomeDude: Hm. Wonder how they got it restarted. Must be deep secrets.
kdekorte: airlied, is there a way to just have the driver say hold the power high? Also is it possible that the card is still running at full power and the pcie lowers it, and the card doesn't and so the gpu crashes due to not enough power?
mjg59: kdekorte: It's link power state, not power supply to the card
BeteNoire: hi, anyone can help with this bug https://bugs.freedesktop.org/show_bug.cgi?id=23623 ?
airlied: its more likely some latency issue where the gpu expects a reply on the link and doesn't get it and dies
mjg59: airlied: If you can get a .inf file for it, there's a stanza in there that can force Windows to disable ASPM for the device
kdekorte: mjg59, what does pcie_aspm give us to the kernel? I know MS enables it, but what is the net gain to enableing
airlied: kdekorte: got the Windows driver CD for it?
mjg59: kdekorte: Power saving
kdekorte: airlied, Windows, what is windows?
kdekorte: I can download the driver and get the inf out....
airlied: hopefully bridgman can get some inside gossip on it
mokoloko: kdekorte: didn't help ---> still freezes
agd5f: mjg59, airlied: some people have had hangs from using the pcie link changing code in the ddx on r6xx/r7xx
airlied: mjg59: its all hw done?
kdekorte: forgot how huge windows display drivers are... 25MB just for the driver
mjg59: airlied: The transitions are, yes
airlied: mjg59: http://forums.amd.com/game/messageview.cfm?catid=260&threadid=110337&enterthread=y
airlied: looks like crossfire mighr have issues anyways
mjg59: The biggest savings with ASPM are going to be on x16 devices
mjg59: So I'd prefer not to just turn it off on all radeons
mjg59: But it'd be easy enough - we just need to add a flag to struct pci_device and then let radeon flip that
airlied: I'm hoping AMD can help out here
airlied: but otherwise I don't fancy fixing this ona a case by case basis
airlied: esp as it manifests as a hang after a certain mount of time
MostAwesomeDude: nha: You're too kind to credit me with shader hax. The negative addressing workaround was osiris' IIRC. :3
kdekorte: airlied, just emailed you the .inf files
gsedej: Hi! is it possible to have 1/4 FPS on glxgears on x1400 with KMS on? (I know, glxgears is no good benchmark...)
stikonas: that probably indicates software rendering
MostAwesomeDude: I'm honestly not completely certain that will work right due to the extra offset incurred by the SUB inst.
nha: damn
nha: credits to osiris then
nha: in theory, it should work perfectly fine
nha: unless we get bizarre floating point rounding problems
nha: but the values involved should be small enough for this not to be a problem, no?
MostAwesomeDude: Yeah. IIUC maths in the shader is always floating, but I can't see any rounding problems from that.
MostAwesomeDude: The predicate swizzles are more iffy; I don't think we've ever tested them.
nha: we've never ever used predicates, so...
nha: my branch work uses alu result, not predicates
MostAwesomeDude: Gotta leave soon. Before I go... did you have any theory on the readPix fails?
nha: no, I've ignored it mostly, having my head in other things
Axodious: hey, i see this is a channel for open-source ati drivers and have a question that isn't directly related to drivers but this is the closest i could come... i recently upgraded my computer to a i7 860 with a gigabyte p55-ud3r, i got 2x 4870s and crossfired them, i just now realised that the motherboard is 1x 16x and 1x 4x instead of 2x 16x (only supported on the x58 chipset) or 2x 8x...
Axodious: does anyone how much (if any) of a performance hit would i be looking at?
MostAwesomeDude: Good call.
MostAwesomeDude: Axodious: I prefer pears to apples, honestly. Much juicier and sweeter to me for some reason.
MostAwesomeDude: I know that answer's not directly related to your question, but that's the closest I could come.
Axodious: k, thought it was worth a try.. thanks though
MostAwesomeDude: In all seriousness, if you can afford two 4870s, I don't think you're going to have HW performance problems.
Fry-kun: hi
Fry-kun: who do I need to bug about finishing up/closing an EDID quirk bug?
Axodious: well i've been reading all day today getting mixed results about it bottlenecking
Fry-kun: I'd do it myself if someone told me what needs to be done :P
Axodious: it's just so confusing between 4870, 4870x2 and the pcie channel speed
kdekorte: Axodious, if you are really concerned about it, maybe you should swap out the MB for one that meets the specs you want
Axodious: i plan to, was just trying to see if i could get a solid answer on it, if someone said i wouldn't see a hit or it would be very marginal i probably wouldn't swap it
Axodious: anyway, thanks for your help and sorry to bother you
kdekorte: Axodious, it probably depends on what you are doing... crysis.. you might.. most things probably not
agd5f: nha: flow control in vertex shaders isn't part of the actual shader program
agd5f: it's sort of like you define the chucks of alu code you want and use the VAP_PVS_FLOW_CNTL* regs to move around
nha: agd5f: so it really only consists of those external registers? in particular, there are only those non-dynamic jumps and loops?
agd5f: as far as I know
nha: then at least I understood it correctly
nha: yeah, that's the impression I got from reading the docs, but who the hell designs hardware like that?
nha: oh well
agd5f: the VAP comes from r200
agd5f: so it was probably a hack to add support
nha: I hope there are no subtle caveats like the FLOW_CNTL* regs can only be used in a certain ordering or something
nha: yeah, that sounds plausible
stikonas: agd5f: I have some display corruption (strange black stripes, eg when editing image with gimp, chromium logo in about box and in sometimes other places) on RV730 with 2.6.32-rc4 xserver 1.7 and git versions of mesa & ddx
stikonas: do you know what can I do to find the cause of it
stikonas: I'm using KMS
agd5f: stikonas: switch to drm-next
stikonas: ok, thanks
agd5f: or revert 49c458e544ae14514209ed80ea6829ca1b18ddf0
stikonas: probably drm-next would give some other benefits
nha: MostAwesomeDude, airlied, others: http://dri.freedesktop.org/wiki/R300Compiler some rather shallow, high-level documentation
WhiteRabbit56: You guys are bad for my studies.... I've been trying to to follow and figure out what you are talking about all day instead of paying attention in classes...
WhiteRabbit56: Although it has taught me some valuable information
nha: WhiteRabbit56: I'm glad we're that interesting - although it may not mean much, sometimes *anything* is more interesting than classes ;)
nha: but as long as you're learning, everything's good ;)
WhiteRabbit56: haha nope it's interesting... I'm currently studying software engineering so this stuff is what I like
nha: ah, nice :)
nha: Have you ever done any graphics programming, e.g. using OpenGL?
WhiteRabbit56: tried... never got anywhere
nha: :/
WhiteRabbit56: I have looked at the radeon code a little bit... I understand some but most of it is things that pertain to OpenGL
WhiteRabbit56: so I'm lost
nha: yup, unfortunately things are not very accessible if you don't know OpenGL
nha: Gallium is a lot better in this respect, but there are still implicitly OpenGL things
nha: although they're more abstracted from OpenGL
nha: in Gallium, it's really more a general 3D programming background that's required
nha: i.e. both people with an OpenGL and a Direct3D background should be able to make sense out of it
WhiteRabbit56: hmm... i might look into that... I've done a little Direct3D coding
Dr_Jakob: WhiteRabbit56: DX10 or DX9?
WhiteRabbit56: well I know it was before DX10...
WhiteRabbit56: but I can't remeber if it was DX9 or earlier than that
WhiteRabbit56: either way I know that I need to brush up on my 3D programming skills before I can dig to far into any of this
Dr_Jakob: oh okay, when it comes to interface its more inline with DX10.
spstarr: agd5f:
spstarr: [16035.520518] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16693
spstarr: [16035.520521] [drm:r600_cs_legacy] *ERROR* Failed to initialize parser !
spstarr: even with commented out changes to render
rnoland: spstarr: hrm... that is kinda like what i was getting earlier if i crash in vdrift...
spstarr: yes
rnoland: Oct 14 14:07:46 balrog kernel: error: [drm:pid95382:radeon_cs_ioctl] *ERROR* cs->dwords too big: 16393
spstarr: some badness
spstarr: seems to crash more with that commented oit
spstarr: out
rnoland: commenting what out?
spstarr: [02:01]
spstarr: this seems to make things trigger that error more now
rnoland: oh, yeah
spstarr: reverts
BeteNoire: thx
laska: airlied: can you look to this http://pastebin.com/d606d9fed
laska: airlied: i have a "task events/0:9 blocked for more than 120 seconds." in ttm_bo_wait_unreserved
airlied: laska: doing anything special at the time?
airlied: or is X hung I assume so.
laska: i play in openarena just before it, then exit from the game and strange thing: can't type anything in terminal, but giu app works just fine
laska: so anything not connected with terminals work just fine, i can surf web, chat with friends, but can't open any terminal and switch to text console from X11
airlied: wierd.
laska: i use 2.6.32-rc4 with patches from you drm-next except "drm/radeon/kms: properly handle mode id with native mode changes"
laska: airlied: (if it significant) i use multiseat X11 configuration with two radeon cards
airlied: laska: oh that might matter alright
laska: i can post also my xorg.conf and logs of both X11
kdekorte: airlied, you still want those .inf files.. your mail server bounced them back to me, cause they were "unacceptable"
airlied: kdekorte: send it to airlied@gmail.com
airlied: laska: yeah if you could open a bug on bugs.freedesktop.org it would be best
airlied: so we can track it
laska: ok
kdekorte: airlied, sent
airlied: mjg59: so I should expect a pci_disable_aspm or equiv to appear before F1@?
laska: airlied: bug to xorg/driver/radeon ?
airlied: laska: yup
kdekorte: airlied, just as an FYI, I booted into the -56 kernel (rawhide current) with pcie_aspm=off and everything seems to be working fine
airlied: kdekorte: excellent thanks for the help tracking that down, I'll try and get some thing sensible done for F12 final
rnoland: agd5f: i have a couple of other minor tweaks and cleanups for the kernel you might want...
kdekorte: airlied, I should be thanking you for finally getting my card working... definitely nice to have 3d and no fglrx (hate that thing)
laska: airlied: https://bugs.freedesktop.org/show_bug.cgi?id=24536
Wizzup: I'm afraid that's not enough
dmb__: airlied, don't think that helped, might need a little +b action
dmb__: :P
laska: airlied: i also have some problem second X11 like: (a) image bifurcation in some videomodes and (b) monitor sometimes unexpectedly report about unsupported frequence and refuse to show any image
mjg59: airlied: Do you want that?
airlied: laska: yeah mention that as well
laska: airlied: done
DanaG: http://www.bit-tech.net/news/bits/2009/10/14/ati-stream-sdk-now-supports-opencl/1
DanaG: dang, I know it's not for Linux, but it still does raise the question:
DanaG: Why are R600 cards left out? Is there something significantly different in R700?
MostAwesomeDude: Double-precision instructions on r700, I think.
DanaG: ah.
DanaG: I wish the idea of MXM had caught on better... then perhaps I could replace my HD3650 with a 4650, some time down the road.
DanaG: I mean, I have MXM... but there's the whole VBIOS issue, and all that. =þ
dmb__: trying to figure out if buying a 8770 is worth it
dmb__: erm
DanaG: s/8/5/?
dmb__: 5770
dmb__: yeah
dmb__: right now i have a cheap r7xx
dmb__: that is shit
dmb__: sorry for the language
dmb__: my bad
DanaG: eh, no big deal to me, at least.
TCW_: We are all used to shit... more or less ;)
TCW_: dmb__, what sucks with your card?
DanaG: http://www.insidemacgames.com/forum/lofiversion/index.php/t36536.html -- aah.
DanaG: bottom post.
airlied: wierd TMDS on crtc1 on legacy appears busted under kms
dmb__: TCW_, 2d, 3d, can't even run a zsnes game smoothly :)
dmb__: TCW_, it was a $20 card
zhasha: dmb__: that doesn't sound right
fly_: Hey, was wondering does anyone else get a hard freeze with OpenGL? i've got Composite disabled and I dont get any errors maybe im missing something
dmb__: zhasha, can't use the open source driver atm, b/c modesetting isn't working on it
dmb__: looks at agd5f again :)
zhasha: dmb__: closed driver counseling is in #ati
fudje: "FGLRX Users Anonymous"?
SmallCat_: zhasha, what are the differences nowdays, closed and open, only ogl extension or performance too, tv-out sounds like ok and video now for open one as i heard newer cards?
zhasha: SmallCat_: Has anyone really been far even as decided to use even go want to do look more like?
dmb__: zhasha, not really interested in the closed driver :)
fudje: And you're letting modesetting hold you back?
dmb__: heh
dmb__: i'll do all i can to help fix that
airlied: agd5f: ping?
SmallCat_: zhasha, i didn't pick up the point from that sentence:)
zhasha: SmallCat_: I didn't pick up the point of yours either
hnsr: well im not picking up anything either because my back hurts
SmallCat_: zhasha, but new extensions 3.0 ones i took a look at, looks like libsh abstraction again, once state tracker is there
fudje: finds that xf86-video-ati with KMS, DRI2 has better redirected rendering performance than catalyst
zhasha: SmallCat_: I honestly don't know what you're getting at. Could you ask someone else?
SmallCat_: http://developer.nvidia.com/object/opengl_3_driver.html bunch of extensions to implement for open source
airlied: GL3 won't be happening anytime soon for open source
airlied: http://dri.freedesktop.org/wiki/MissingFunctionality explains why
fudje: that would be the patents?
MostAwesomeDude: I've been advised to call them "enhanced functionalities."
airlied: well some bits yes, but there a lot of work before patents are the final blocker
fudje: heheh
DanaG: oh yeah, on R350, what's the OpenGL version in hardware?
MostAwesomeDude: GL 1.5.
MostAwesomeDude: Technically.
MostAwesomeDude: We'll probably squeeze GL 2.0 out.
DanaG: Spiffy. Though, I'm not actually familiar with the OpenGL versions themselves.
DanaG: At least DX7, DX8, DX9 progression is more obvious.
dmb__: was glsl part of the 2.0 standard?
dmb__: or was that later
airlied: 2.0
dmb__: oh
MostAwesomeDude: Okay, so softpipe no longer dies horribly on readPixSanity. Yay.
MostAwesomeDude: Also, got ZTOP moved into its own state.
fly_: grr
SmallCat_: MostAwesomeDude, probably ecnhasements yes, need to read txt files and sgi for every single of them, and if some gpugpu has samples for similar functionalities, 2.0 is glsl 1.2 right?
MostAwesomeDude: SmallCat_: No, GLSL 1.1 is in GL 2.0.
MostAwesomeDude: This is officially frustrating. Some of the tests *sometimes* fail, and the viewport asserts appear to have no impact whatsoever on whether or not it fails.
DanaG: interesting.... "clearspd" seems to be a nifty torture-test for graphics drivers. or at least for fglrx. =þ
DanaG: It lags everything while you drag the window around.
DanaG: Now, to figure out what clearspd actually does.... =þ (time for google).
fudje: I had the impression X was a nifty torture test for fglrx.
DanaG: * Simple GLUT program to measure glClear() and glutSwapBuffers() speed.
DanaG: =þ
DanaG: hmm, somebody try clearspd on radeon, perhaps.
spstarr: agd5f: so about this
spstarr: [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16391
spstarr: shall I log a bug?
MostAwesomeDude: DanaG: It calls glClear() and then glutSwapBuffers(), as fast as it can.
MostAwesomeDude: On r300g, we actually got it to more or less max out the 3D engine's fill rate.
DanaG: Nifty.
fudje: DanaG: This makes it and Xorg claim almost 100% CPU with radeon + KMS + Redirected DRI
fudje: Rate: 6400 clears in 2.086s = 3068.07 clears/s 4.90892e+08 pixels/s
DanaG: Now try dragging the window around. =þ
spstarr: turns off more textures
DanaG: It's also interesting in terms of scheduling, too -- with fglrx, it breaks up audio.
DanaG: =þ
fudje: Hmm, didn't try it with audio happening
MostAwesomeDude: It's got a few command-line options; force buffer swaps on, and then see if it still kills your CPU.
hnsr: nvidia is pretty bad at that too, i drag a window playing video around and my system grinds to a halt, and i have to wait 20 seconds for video/audio to resync
fudje: heh, doesn't affect audio for me :)
fudje: MostAwesomeDude: No noticeable difference except the clear rate seems to drop to 1/4
MostAwesomeDude: fudje: Hm. Ideally, it shouldn't interfere with the rest of your system...
MostAwesomeDude: ...but on the other hand, it's a useless torture test. :3
fudje: Actually, that's not quite right. with +swaps Compiz drags the window smoothly.
fudje: Moving on, I get the impression that texture performance isn't too good for r600 at this point?
SmallCat_: hnsr, hmm, you get a freeze wihile moving video window? that's not good:)
fudje: ...where do I start hacking?
spstarr: fudje: the code is still hot
SmallCat_: MostAwesomeDude, have you got some pointers that makes you belive that hw flow could work in gallium, that 1.5 2.0/1 step should be the biggest?
SmallCat_: and i think while you are a good pianist maybe even same good programmer, that is massively complicated
MostAwesomeDude: SmallCat_: Gallium lets us take small steps. We don't have to add big chunks, just lots of small bits of functionality.
SmallCat_: so tell me , once one library is released like lgpl one version, can some change of feature releases and licence affect that releases lgpl?
fly_: Has anyone else experienced hard freezes with OpenGL? it happens in google earth as well as glxgears thusfar
spstarr: yes
spstarr: but more details
spstarr: what does dmesg show
fly_: http://www.pastebin.ca/1621424
spstarr: oh r3xx-r5xx
fly_: yup
agd5f: rnoland: send them along
agd5f: airlied: pong
airlied: agd5f: my rv380 TMDS won't work on crtc 1 under kms
airlied: agd5f: I noticed in the DDX we mask off a lot of regs in FP_GEN_CNTL that we don't touch in the kms code
agd5f: airlied: crtc 1 as in the second crtc or the first?
airlied: second one
agd5f: airlied: ok
airlied: I'm sort of hovering around some rmx related fail
airlied: even though I'm not using the rms on it
airlied: rmx on it even
airlied: radeontool hasn't produced anything obivous yet I'm just dumping more bits now
agd5f: lots of the crtc stuff needs to be set right in fp_gen_cntl since the timing can come from several different sets of timign regs IIRC
airlied: yeah I never really figured out all the FP_ FP2 stuf
airlied: the bit that was missing was fp_gen_cntl &= ~(RADEON_FP_RMX_HVSYNC_CONTROL_EN | etc.
airlied: about 8 bits
airlied: also either DDX or kms has a bug with the FP_SEL_CRTC?
airlied: but that is !r300 so not my current issue
agd5f: FP_SEL_CRTC how so?
airlied: for crtc 0 DDX does save->fp_gen_cntl &= ~RADEON_FP_SEL_CRTC2;
airlied: fp_gen_cntl |= RADEON_FP_SEL_CRTC1;
airlied: is what KMS does
airlied: I don't have docs to check which is right
agd5f: 0 is crtc0 1 is crtc 1
airlied: so the &= ~ seems right not the |
fudje: seems to me the |= is redundant in that case, yes.
agd5f: airlied: yeah, should be cleared for crtc0
agd5f: fp2_gen_cntl has the logic right
agd5f: also we want to clear all the fp_gen_cntl bits like the ddx does
SmallCat_: MostAwesomeDude, lets say during validation, maybe then couple of regs or temps are needed, will try to port fbo's here, probably need to read still :(, either way internal solutions isn't an option for me, can't understand much of those regs there:)