airlied: mattst88: not sure how you can avoid unaligned access with atom
spstarr: heh, nice, the game server just coredumped
airlied: mattst88: though if you can find any outsdie the atom code them it might be more fun
dougmencken: airlied, here? I built a new kernel with your patch
dougmencken: glxinfo | grep renderer --> OpenGL renderer string: Software Rasterizer
airlied: dougmencken: cool got the dmesg?
airlied: dougmencken: oh I didn't expect that to fix thingsyet, just a good place to start seeing what was wrong next ;-)
dougmencken: ok, pasting it
dougmencken: and what does that patch do? just ignoring card's firmware?
airlied: dougmencken: yupp ignores the OF stuff since we can't parse it
airlied: so X starts and you can see stuff now?
airlied: pastebin the X org log
airlied: wierd you get two offb framebuffers not sure I handle that twoo well
dougmencken: x log - http://pastebin.com/m6168643f
airlied: just as an aside can you test the offb patch at http://people.freedesktop.org/~airlied/scratch/ppc/offb-test.patch
dougmencken: at this time, can I just build one module, not the entire kernel?
airlied: well a rebuild should just build the changed files
airlied: that patch changes the kernel itself
dougmencken: hmm okay, so another 16 hours :)
airlied: are you using make kpkg or something?
airlied: dougmencken: install ccache
airlied: dougmencken: can you pastebin lspci -vvnn
airlied: dougmencken: also ls -la /sys/bus/pci/devices/
dougmencken: ah, it's due to that (manually building was much faster); of course, pasting
airlied: hopefully the next bug is just userspace
airlied: that patch is just an extra cleanup
DanaG: random: http://www.techeye.net/software/amd-and-nvidia-bitchfight-over-open-source-support#comment-3057
airlied: loves when an xpress200 users gives out
airlied: its like I bought a cheap laptop and it didn't work kinda bitchin
dougmencken: http://pastebin.com/m51062555 and http://pastebin.com/m153ae894 << root version
DanaG: oh yeah, if rv250 is DX7 / OGL1.3, does that mean it doesn'
DanaG: doesn't have to have NPOT support?
Neo_The_User: compiling error on mesa r600: http://pastebin.ca/1792292
airlied: DanaG: yes just rect support
airlied: dougmencken: okay wierd
airlied: oh maybe not
airlied: dougmencken: can you strace Xorg startup?
airlied: dougmencken: ssh in and run strace -o xstart Xorg
dougmencken: never done that before
airlied: and get me xstart
airlied: make sure X isn't running
airlied: also ls -la /sys/bus/pci/devices/0001:10:15.0/
mancha: is xstart distro-specific?
airlied: no thats just an output file name
dougmencken: so, to write it by real pen: 'strace -o xstart Xorg' and pastebin that file
airlied: dougmencken: yup
mancha: ah ok, brain fart here, didn't see the -o :/
Neo_The_User: i haven't got a compiling error in mesa in a very long time.
mancha: for ppl actively debugging stuff, a cli irc client would be a wise choice
Neo_The_User: uses irssi
fireun: mancha: and screen
dougmencken: Fatal server error: Cannot move old log file ("/var/log/Xorg.0.log" to "/var/log/Xorg.0.log.old"
Neo_The_User: I got that error compiling xserver from source the wrong way about the xorg log
mancha: fireun, indeed
airlied: dougmencken: as root?
airlied: grab ls -la /sys/bus/pci/devices/0001:10:15.0/
dougmencken: btw, when I logged out from X, I got "Out of range" on my monitor, so it required to type 'reboot' blindly :/
dougmencken: okay, I'm in plain tty now
dougmencken: may I pm it to you?
airlied: yeah without X running
airlied: yeah pm the sys bus stuf
airlied: I may disappear soon to grab a bus, but I'll bbl
Neo_The_User: :( my dad is making me go to bed
Neo_The_User: good night all. :D All great people!
mekius: does texture_from_pixmap work with the latest stuff for r600?
mekius: So I've installed just about everything from the git repos and have modesetting and 3d working, but for some reason glxinfo is reporting my server and client glx version as different values. Anyone know what I'm missing or is this normal? Pastebin here: http://pastebin.com/m14edf641
cxo: Why would 3dmark03 on wine say that an r700 doesnt support DXT1 and DXT3?
taiu: cxo: because it doesn't?
cxo: Thats highly unlikely. DXT has been in DirectX since like 6.0
cxo: Just trying to understand how direct3d capabilities are drawn up using opengl extensions
cxo: hmm GL_EXT_texture_compression_dxt1 i think its called
cxo: Which is from openGL 1.3 or something
cxo: how come its not shown in glxinfo?
AndrewR: cxo, wine uses OpenGL driver .. and current open-source driver doesn't support it (yet)
AndrewR: cxo, *s3tc on r6xx
cxo: Any idea why the open source driver doesnt support that function yet?
AndrewR: cxo, i saw discussion about this problem here, hopefully it will be resolved in not too distant future ... want link?
cxo: yeah sure
AndrewR: cxo, http://people.freedesktop.org/~cbrill/dri-log/index.php?date=2010-02-05&channel=radeon&show_html=true&highlight_names=&update=Update&date=2010-02-05
cxo: by the way, do you know what dependencies i need to get piglit running?
AndrewR: cxo, 06:27, 06:48 ... No, piglit magically started to compile on my system after i updated it few times ....
cxo: Ok that was a bit over my head. So you need tiling for dxt
cxo: And tiling hasnt been implemented because?
AndrewR: cxo, because most developers are busy , with other bugs ?
airlied: dougmencken: hey, so ls -la /sys/class/drm
airlied: dougmencken: also boot with drm.debug=15 and get that dmesg without starting X
airlied: I've no idea why the drm isn't bound to the device in sysfs
AndrewR: airlied, hm, so drm_max_debug isn't 9 (as i incorrectly assumed)? ....
cxo: Now arent gl functions that arent implemented in hardware, done in software? so shouldnt dxt just work, but be slow?
MostAwesomeDude: cxo: Patents.
cxo: So certain gl functions cannot be implemented in software due to software patenting?
airlied: AndrewR: no it goes to 15 now I think
airlied: shops &
AndrewR: airlied, thanks, on next boot i'll try this value (in attempt to extract more info for this weird rv280 i2c bug).
AndrewR: MostAwesomeDude, not sure if i understand this correctly, but GL implementation allowed to use some intrnal_format instead of requested_format, internally, so one can just decompress all s3tc textures, defeating whole compression idea ... it was "Force s3tc" option in driconf? But it doesn't work on r600 ?
MostAwesomeDude: AndrewR: You can't decompress in software.
MostAwesomeDude: And the AMD guys aren't allowed to add in the S3TC info.
cxo: ... add in the S3TC info to? the driver?
MostAwesomeDude: Or the docs.
cxo: Oh because it belong to S3 Graphics, and AMD pays royalty for using it?
MostAwesomeDude: I haven't checked, but I bet there are three or four spots in the r600 texture format list marked "Reserved," and those are for FXT1 (maybe), DXT1, DXT3, and DXT5, in that order.
MostAwesomeDude: No, it belongs to Microsoft. DXTC.
cxo: maybe i misunderstood what they meant by "While S3 Graphics is no longer a leading competitor in the graphics accelerator market, license fees are still levied and collected for the use of S3TC technology,..."
MostAwesomeDude: No, it's just that S3 permits MS to sublicense, and all the vendors sublicense through MS because they don't like S3 getting that much of the pie.
cxo: So basically, we (the foss community) are unlikely to ever get S3TC support?
MostAwesomeDude: Not quite.
AndrewR: MostAwesomeDude, wild idea .. implement libdxtn on GPU ..... and load it as shader(s).
MostAwesomeDude: AndrewR: Still covered by the patent.
AndrewR: MostAwesomeDude, just for personal use only ;)
MostAwesomeDude: AndrewR: For personal use, just go get the lib yourself.
cxo: Well if S3TC is patented, how are we going to do it with an open source driver?
MostAwesomeDude: The patent covers implementation, not usage.
AndrewR: MostAwesomeDude, yes yes yes .... i have this lib. I can dream in wild dimensions
MostAwesomeDude: So just use the hardware, which is already licensed and paid for.
MostAwesomeDude: You can't compress, but you can decompress.
MostAwesomeDude: Very few apps actually ask the GL library to do the compression, and generally games that use it have their textures pre-compressed, so it's not a problem.
cxo: So its just a matter of kicking on S3TC function on the radeon hardware?
AndrewR: MostAwesomeDude, i was thinking from tech point of view .. if AMD GPU (r6xx) powerful and flexible enough for offloading this from CPU (and bus)
AndrewR: MostAwesomeDude, *this compression op
MostAwesomeDude: AndrewR: What's the point?
MostAwesomeDude: It's not computationally expensive.
MostAwesomeDude: And it's not going to get you out of the scope of the patent.
AndrewR: MostAwesomeDude, awoid CPU compression step ... some sort of two-pass rendering. Not sure if it possible with current OpenGL
cxo: So how does all this affect the ability of the driver? to render DXT stuff?
MostAwesomeDude: AndrewR: Still covered by the patent.
MostAwesomeDude: cxo: It doesn't, really.
cxo: ok :) i think i'm lost now
AndrewR: MostAwesomeDude, Reimplement whole pipelane inside GPU .... extremely bad idea .... (probably not possible)
MostAwesomeDude: AndrewR: And it's still covered by the patent.
AndrewR: MostAwesomeDude, basically we come to simple conclusion ......
cxo: S3TC compression is done in hardware, so the radeon driver just needs to implement the interface? Which will then gives us GL_EXT_texture_compression_dxt1 and GL_EXT_texture_compression_s3tc and etc..?
AndrewR: MostAwesomeDude, sorry, i simply can't see point in all this patents, if they stop people from doing things differently. Not in ways it was done 10 years ago ....
AndrewR: MostAwesomeDude, but .. this is life
MostAwesomeDude: cxo: Decompression only. No compression.
MostAwesomeDude: AndrewR: And? You're not the only one affected. If you seriously care, then go out and make your voice heard.
cxo: ok Decompression is only done in hardware?
MostAwesomeDude: Well, it's not really decompression.
MostAwesomeDude: But you can render from a compressed texture to a colorbuffer, effectively creating a decompressed copy.
cxo: so we'll never get s3tc "compression" in the open source driver?
airlied: not by default
MostAwesomeDude: You could implement it freetype-style, but nobody's done it.
airlied: its there if you download libtxc_dxtn
MostAwesomeDude: Alright, sorry, but I haven't slept in 36 hours...
cxo: Dont patents in the US only last 20yrs. (Maybe even less in the tech industry)
taiu: cxo: we'll get it eventually ;)
MostAwesomeDude: IT DOESN'T MATTER. ON-THE-FLY COMPRESSION IS OVERRATED. ALL GAMES OUT THERE RIGHT NOW, IN THE FIELD, PRE-COMPRESS TEXTURES. TOOLS LIKE GIMP ONLY USE GPUS FOR DECOMPRESSION, NOT COMPRESSION.
AndrewR: cxo, 20 years is like infinity ... in computers .... (myself not from US, so i don't know details)
MostAwesomeDude: Our current state might not be legally tenable, but it's fine for conformance and performance.
airlied: also libtxc_dxtn's compression sucks
MostAwesomeDude: Besides, we haven't lost 'em all. We won Theora.
cxo: AndrewR, well we're still trying to get 10yr old ati cards to work on linux :)
MostAwesomeDude: cxo: Rage 128 and r100?
Nightwulf|work: hi all
AndrewR: airlied, sucks in waht sense? Does it producted wrong results? Or just have wrong speed?
spstarr: airlied: im anxious to try out new code :)
airlied: AndrewR: the results are less than fantastic
taiu: cxo: I have it semi-working ... but the code is ugly, so I cannot push it
airlied: like it works its just not as good as the nvidia/ati compressors
airlied: fixed bugs in it once
airlied: MostAwesomeDude: we just theora GLSL
MostAwesomeDude: airlied: Yeah, I'm excited for that stuff. I should probably jump on that sometime soon.
airlied: MostAwesomeDude: get GLSL working first ;-)
MostAwesomeDude: airlied: I should do a piglit run with nha's tree, thanks for the reminder. :3
airlied: MostAwesomeDude: so I started ripping out u_simple_screen.h
airlied: but it might be next week before I make to compiling again
cxo: What i dont get is why all the games that work on nvidia driver dont work on the radeon driver as well. Unaccelerated api is done in software automatically, so shouldnt everything just work?
AndrewR: cxo, software mixed with hw rendering tend to be even slower, compared to pure software
cxo: yes. but shouldnt the client app just work anyways?
AndrewR: cxo, it was reason for some GoogleEarth is slow on r300 bug reports .... disabling some fallbacks via driconf workarounded it
AndrewR: cxo, if you have new overpowered CPU - you can try llvmpipe ... may be it will give you something
airlied: cxo: the driver doesn't fall back to sw for things it doesn't know are broken
airlied: if it was smart enough to know it was broken it would be smart enough to fix itself
airlied: also falling back to sw for some GL things like anything frag shader related is really crappy
airlied: you'd end up with spf not fps
AndrewR: remember sw fallback on r128 in ut2k4 ... it was .... unplyable .....
cxo: I dont get how that works. Why doesnt the driver know what api is implemented and and what isnt?
airlied: cxo: it might not implement them all correctly
airlied: we also don't have sw fallbacks for every possible thing
airlied: and if we did it wouldn't help
airlied: as CPU is not a gpu
dougmencken: airlied, http://fpaste.org/YNOr/ << ls ...drm
dougmencken: drm.debug=15 is a kernel argument?
cxo: So I'm guessing there are lots of partially completed (ie. broken) accelerated api in the driver?
airlied: cxo: its mostly the shader compilers
airlied: als othe APIs aren't awlays speced well
airlied: some the same app on different drivers can die in interesting ways
airlied: dougmencken: okay this is wierd
dougmencken: got strace out?
airlied: ls -la /sys/devices/pci0001:10/0001:10:15.0/d
airlied: ls -la /sys/devices/pci0001:10/0001:10:15.0/
airlied: dougmencken: yup, don't worry about the debug=15 yet
dougmencken: okay, need to | fpaste (I started to like iy :) ls -la /sys/devices/pci0001:10/0001:10:15.0/d ?
airlied: yes without the d at the end
airlied: wow sysfs must have some wierdass issues on poewrpc
cxo: hates how absurdly steep the learning curve is for writing graphics drivers
airlied: dougmencken: rpm -q libdrm
dougmencken: libdrm-2.4.17-1.fc12.ppc ;)
MostAwesomeDude: cxo: The curve isn't any less steep for, say, writing asm.
MostAwesomeDude: Or writing non-trivial compilers.
airlied: dougmencken: I'll build a test package for you
hnsr: hey i wrote asm once
dougmencken: cool, I'll be happy to test it
cxo: Like any idiot can write a sound card drivers, toggle a gpio here, do a bit of PCM there. Modulation techniques are taught to almost all engineering students in 2nd year.
cxo: But graphics driver? You need to know opengl, and then you got to know the graphics architecture and its ISA, and then you need to join all those dots up together somehow
airlied: and really you can focus on one or two bits
dougmencken: you guys are doing the great job, thank you
airlied: gave up at re-learning compile theory
MostAwesomeDude: Hm, I seem to have lost the r300g test list.
MostAwesomeDude: Oh well, I don't think the r300 list causes hardlocks, just lots of warnings. :3
cxo: I mean MostAwesomeDude bitches about me bitchin. But its not like i dont want to contribute. Thanks to unemployment I've got a lot of free time these days. But if you've used ati cards on Linux as long as I have, you'd have either committed suicide by now or turned into a cynical grumpy troll like me
MostAwesomeDude: cxo: I got started *because* I hated fglrx.
MostAwesomeDude: I'm largely irascible due to lack of sleep.
cxo: yeah you've said that before. But i'm not comp.sci. I just cant start writing graphics drivers. Sure I can write ASM for a few chips, but its not like I can actually study the r700 docs and actually contribute something that wouldnt have already been done by the time i figure out how to do it
MostAwesomeDude: I'm not very CS either. My formal education sums up to roughly two years. I'm further on a music degree than CS.
airlied: dougmencken: http://koji.fedoraproject.org/scratch/airlied/task_1973665/
airlied: get that libdrm package and install it
cxo: So how did you learn all this opengl crap then?
dougmencken: focuses my browser
MostAwesomeDude: Wikipedia and an undying loathing of fglrx.
dougmencken: which one?
dougmencken: plain, debuginfo, devel?
hnsr: MostAwesomeDude is the intersect, he flashed and knew instantly how to program graphics drivers :p
hnsr: (if that didn't make sense, go watch Chuck!)
MostAwesomeDude: I spent high school working on WP, practicing various instruments, reading books, hacking boxes. There's a reason I have a GED.
cxo: Yeah but thats sorta like me learning to play the sax by looking on the internet. I've had years and years of formal music education. But a total n00b couldnt just pick up the sax and learn how to play at a reasonable rate purely from wikipedia
amarsh04: failed to finish a degree at his uni, but nonetheless worked there a few years in IT and now has a stepdaughter at uni studying music
dougmencken: ok, I got the plain one and 'rpm -i libdrm-2.4.17-1.fc12.wtf.ppc.rpm'
dougmencken: $ rpm -q libdrm --> libdrm-2.4.17-1.fc12.wtf.ppc ; what to do now?
airlied: dougmencken: plain + devel might be needed
airlied: dougmencken: reboot and try start X
dougmencken: airlied, yep, got them both; any strace required or just normal startx?
airlied: just normal X startup
airlied: and get the log again
dougmencken: cat /var/log/Xorg.0.log | fpaste --> http://fpaste.org/NLVC/
airlied: damn my patch must've been wrong
dougmencken: and what about kernel patch removing break on first fb found?
airlied: that shouldn't fix this bug its just a cleanup for the two offbs
dougmencken: my cpu is wasting time now, so can I try to re-build kernel again with your two patches
MostAwesomeDude: I just looked at piglit's blendFunc for the very first time.
MostAwesomeDude: God, it's like The Ring. :C
airlied: dougmencken: can you try another strace now
dougmencken: of course, but loggin out X.org now means to be blind (monitor can't display after that)
dougmencken: i.e. reboot will be needed
dougmencken: okay, rebooting now
Nille02: has it a reasson why the IRQ firmware is not in the git?
airlied: Nille02: new fw doesn't get added to the kernel
airlied: there is a linux-firmware tree, just waiting for the maintainer
Nille02: why? because if the kernel can't wind it I get no accel
Nille02: ah ok
dougmencken: cat xstart-wtf | fpaste --> http://fpaste.org/uIs3/
airlied: dougmencken: wierd ls -la /sys/devices/pci0001:10/0001:10:15.0/drm
Tommeh: I've discovered as of last night, that with 2.6.33-rc7 (and 22.214.171.124) I'm actually having problems using R600 KMS with Compiz.
Tommeh: I can boot Ubuntu with those kernels (from the kernel PPA) with KMS disabled and Compiz works fine.
twnqx: airlied: if i wanted to trace the command stream from the ddx to the kernel module, where would i plug the logger?
Tommeh: If I turn KMS on, that works fine as far as I can tell, but then I can't enable compiz.
Tommeh: It's confusing :(
svenstaro: Tommeh: You will probably need to reocmpile all mesa stuff for KMS
Tommeh: svenstaro: really?
Tommeh: I've been lazy so far and simply used the xorg-edgers PPA :)
svenstaro: Tommeh: Easy to test. Just run glxgears --version and glxinfo |grep render and see what it tells you
airlied: dougmencken: got another libdrm building
svenstaro: It probably mismatches and falls back to software Tommeh
airlied: twnqx: radeon_cs_emit in libdrm
Tommeh: Some strange behaviour from glxgears :(
svenstaro: Tommeh: Ah :)
Tommeh: I move the glxgears window and the image 'sticks' to my desktop.. Moving a window over it erases.
svenstaro: Are you on software or hardware rasterizer?
twnqx: airlied: thanks, gonna try to understand the structures next :)
Tommeh: svenstaro: at the minute, I've opted to run with KMS disabled, so I'm using compiz at the minute - presumably that would be hardware?
airlied: dougmencken: http://koji.fedoraproject.org/scratch/airlied/task_1973764/
airlied: dougmencken: another libdrm
airlied: twnqx: its hw packets mostly like in the R5xx docs
Tommeh: glxinfo | grep render says: 'direct rendering: Yes'
chithead: Tommeh: also check opengl renderer string
dougmencken: airlied, getting it
Tommeh: chithead OpenGL renderer string: Mesa DRI R600 (RV620 95C5) 20090101 TCL
chithead: I think the issue may be resolved in dri2/kms
soreau: Tommeh: This issue is fixed by using kms
soreau: With dri1, gl apps while using compiz have always behaved this way
Tommeh: soreau: the original problem is that - enabling KMS loses openGL :(
dougmencken: # rpm -q libdrm libdrm-devel --> libdrm-2.4.17-1.fc12.wtf2.ppc ; libdrm-devel-2.4.17-1.fc12.wtf2.ppc ; so what now? reboot, x log, strase?
Tommeh: I'll try and reboot to get tests with KMS enabled some time today.
soreau: Tommeh: Enable KMS, then pastebin your X log
airlied: dougmencken: yup try X on its own get log, if still not working strace
Tommeh: I *think* might have that, as I knew someone would ask, soreau :)
dougmencken: okay, rebooting
soreau: Tommeh: grep -R modeset /var/log
Tommeh: soreau: http://pastebin.com/d1e95dad
Tommeh: That's a copy of my log from last night, with all the same packages - but with KMS enabled.
Tommeh: Now with KMS disabled today, on the same config, I can use compiz.
Tommeh: With KMS enabled - compiz is broken.
soreau: Tommeh: Looks like something is wrong with the way it's initializing, possibly failing to load firmware or some other issue. To find out more, we'd need to see dmesg output from the running KMS session
dougmencken: $ cat /var/log/Xorg.0.log | fpaste --> http://fpaste.org/OJ2I/
airlied: this is just wierd as
airlied: dougmencken: get an strace again and I'll have to dig some more tomorrow if I can't figure it out
dougmencken: okay, but what's wrong?
airlied: its like sysfs works differently on ppc
Tommeh: soreau: interestingly, it loads two pieces of firmware when loading KMS
Tommeh: I will find output
airlied: we check for files in sysfs to know if KMS driver is runing
airlied: and for some reason the checks are failing on your system
Tommeh: But the firmware is not the _rlc.bin firmwares.
Tommeh: So I think the firmware loading is OK..
dougmencken: [drm] radeon kernel modesetting enabled. << it's from current dmesg
airlied: dougmencken: yup X is failing to learn it
airlied: the kernel seems fine now
dougmencken: so strace then, okay, rebooting ;)
Leonidas: I have a problem logging in to the freedesktop bugzilla, anyone knows what's wrong?
Leonidas: I always get "The username or password you entered is not valid."
twnqx: likely the username or password you entered is invalid.
Leonidas: nope. I even tried resetting my password
Leonidas: got a proper token and reset it to the password that I was typing in and, well - no change
xming: likely you have a broken capslock/shift key
dougmencken: cat xstart-wtf2 | fpaste --> http://fedoraunity.org/static/limit/ ... hmmm ... --> http://pastebin.com/m6bb8a674
airlied: dougmencken: wierd, I'm out of ideas I'll have to play on my ppc tomorrow and see if I can get benh to take a look
dougmencken: okay, so I'm starting to rebuild a kernel with two patches
Leonidas: xming: no, as you see I am able to type in lowercase
airlied: dougmencken: cool I'll poke around some tomorrow and see if I can figure out why ppc sysfs acts different to other arches
airlied: zzz ^
dougmencken: also, can you point benh to me? say it's about sound support and snd-powermac driver in kernel
Leonidas: uhh, I can change the password all I want, it still does not let me log in. Tried with different passwords, different browsers
Leonidas: actually, i wanted to post a bug report
Leonidas: there seems to be some texture problem with R300, is this the proper channel to write?
amarsh04: yes, might not be developers in channel right at the moment though
amarsh04: is off to work
twnqx: hm.. the struct redeon_cs_int, as used by radeon_cs_emit, has a uint32_t * packets. is this only one packet, or multiple?
lordheavy: groumf http://pastebin.fr/6805
twnqx: and if multiple, how is the limit defined... fixed size, or some termination point?
mcgregor: lordheavy, you're a
mcgregor: lordheavy, you're not alone
lordheavy: yes :-)
mcgregor: but from the phoronix forum I beliebe bridgeman stated if you replace drm with dri, it would work
lordheavy: http://cgit.freedesktop.org/mesa/mesa/diff/src/mesa/drivers/dri/r600/r600_texstate.c?id=debf00e5fc3828f63e0f99d72c7fa6cd6ce012c5 typo , DRM instead of DRI
airlied: twnqx: its an array of packets, defined in the R5xx documents
airlied: CP packets
twnqx: yeah, reading that doc right now, but the types have different sizes, so i just wonder how to find the end of the array :)
twnqx: hmm and where's appendix b...
twnqx: uh... prolly a typo, should read section 6.2 and not B.2
twnqx: ugh... i like code lines that have /* WTF? */ in them
Kurko: hello! I install kernel 2.6.33rc7 and when I boot I got this error: r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
Ivanovic: Kurko: http://wiki.x.org/wiki/radeonBuildHowTo#TroubleshootingExtraFirmwareforR600.2BAC8-R700
Kurko: should firmware works with this kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc7/ ?
glisse: firmware doesn't change
twnqx: meh... my packet decoder only shows opcode packets where the opcodes are not listed in the docs
keltor|away: what needs to be enabled to see the radeon kms in the kernel config?
[Enrico]: kernelpanic_: iirc the drm and the staging driver to make kms the default (but with lastest rc it is no more in staging)
[Enrico]: kernelpanic_: be aware there is no KMS option. if you compile radeon you get both KMS and UMS and you can select which to boot with radeon.modesetting in kernel line in grub config
keltor|away: this would be 126.96.36.199
[Enrico]: kernelpanic_: then in the staging driver tree you can find an option to make radeon kms the default one if you wish
[Enrico]: ops sorry kernelpanic_ wrong tab completition
[Enrico]: keltor: those message were for you
keltor: [Enrico]: ah, there doesn't seem to be a option then in 188.8.131.52, so between 184.108.40.206 and 220.127.116.11 something happened
keltor: do you know what the kernel config option was?
Ivanovic: [Enrico]: have you enabled staging drivers?
keltor: i have
Ivanovic: if you have done so you can select kms by radeon.modeset=1 appended to your boot line
[Enrico]: keltor: enable DRM, then DRM_RADEON this way you will get also kms, but it will not be used by default. if you want it by default enable STAGING and DRM_RADEON_KMS too
[Enrico]: Ivanovic: yes i have
Ivanovic: that is: only if the driver is compiled into the kernel
Ivanovic: if it is built as module make sure that the module radeon is loaded with modeset=1
Ivanovic: beside this you will need a recent libdrm either with --enable-experimental-api or from sometime last week (active by defualt in there)
keltor: i got it :D
[Enrico]: Ivanovic: i'm pretty sure it works with radeon.modeset=1 even if it is a module since it parses the kernel line
keltor: DRM_RADEON was a module
Ivanovic: of course you also need xf86-video-ati from git
keltor: yes i have the dependencies, i'm just going from 18.104.22.168 to 22.214.171.124
keltor: (and i upgraded the dependencies to code current as of today)
keltor: i'm just hoping for fewing boots to black screens :)
keltor: time to test it ...
mattst88: airlied, I think in most cases, the unaligned accesses in atombios code can be fixed with an added (*uint8_t)& or similar, but tracking them down is the hard part.
mattst88: I guess that'll be my job. :)
mcencora: agd5f: hi. could you find out how fglrx on r300 deals (just the general idea) with FBOs with attached Z24_S8 texture, and then renders from such texture?
agd5f: mcencora: I suspect it blits to a temporary buffer
mcencora: agd5f: then what? converts 24bit int to 32bit float in software?
mcencora: (r300 can't render from X24_Y8 INT or X32 INT format)
agd5f: mcencora: nevermind. I was thinking of something else
mishehu: so were david airfield's drm-next patches actually incorporated into vanilla 2.6.32 ?
mishehu: or airlied
mishehu: whatever the guy's name is (not looking at the page)
agd5f: mishehu: what patches?
mishehu: agd5f: "You need same user space drivers as for older cards. That means mesa master, libdrm master and ddx master. But kernel has to be from Dave Airlied's drm-next branch that will be merged to 2.6.32."
mishehu: I've got a radeon hd 4890 card
agd5f: mishehu: yes. Dave is the drm maintainer, so he trees get pulled upstream by linus
mishehu: and the way I'm understanding this is if I want 3d on the card, I need to use the kms drivers
agd5f: mishehu: you don't need kms.
agd5f: but you need 2.6.32 for kms or ums for 3d on r6xx+
mishehu: I just popped in 2.6.32
mishehu: should I be using libdrm 2.4,14 or should I still be using the most recent git checkout?
chithead: 2.4.14 is ancient
stikonas: mishehu: git version of libdrm enables libdrm_radeon by default
taiu: mcencora: is this some r300/r500 difference ?
mishehu: alright I'll git'er'done
mcencora: taiu: yes, r500 can sample from such formats, but r300 can't
spstarr: looks at git changes
mishehu: what's vmwgfx in libdrm?
mishehu: anything I should enable?
adamk: IT's for vmware graphics.
adamk: As I understand it.
mishehu: ok don't want don't need :-)
agd5f: taiu: your patch seems to fix bug 26471. did it also fix the other games with GL_SHORT?
Neo_The_User: hi all. *just got up*
Neo_The_User: oh the patch fixed my issue
Neo_The_User: abotu the r600_texstate.c compiling error. thanks guys!
taiu: agd5f: etqw will display some more stuff with it, sauerbraten needs the FMT_16_16_16_16 hax ontop
jdstrand: agd5f: hi! bryce mentioned last week that I might want to talk to you about http://bugs.freedesktop.org/show_bug.cgi?id=26302 ([M7 LW] desktop runs out of video memory on ATI Radeon Mobility 7500)
jdstrand: agd5f: I'm still having problems with the driver and updated the bug (and the launchpad bug) accordingly. I'm very keen on getting it fixed. If there is any more I can do that can help, please let me know
glisse: jdstrand: this bug is more about userspace
glisse: or we are not reporting one limit properly
jdstrand: I suppose I should mention that I am not a kernel or xorg dev, so fixing this myself would be difficult
jdstrand: (I've not looked at the kernel/xorg radeon driver before)
glisse: yeah it somethings we need to fix
glisse: it's on my todo list
twnqx: agd5f/glisse: is there documentation for the rv635 command opcodes beyond R5xx_Acceleration_v1.4.pdf ?
jdstrand: glisse: I am more than happy to test patches, etc. I've got several radeon bugs open in Ubuntu (as seen in comment #7 in the freedesktop.org bug)
glisse: twnqx: r6xx doc
twnqx: hm ok
agd5f: twnqx: yes, in the r6xx r7xx 3d accel guide
glisse: none of the r5xx are valid for r6xx
twnqx: that explains.
glisse: well nop is :)
twnqx: seeing mostly 0x68/0x69, and those aren't in r5xx
agd5f: glisse: do we take into account the fbdev allocation when we report vram limits?
jdstrand: glisse: that said, most of those are when not using KMS/EXA/compiz. I'm hopeful once the KMS/EXA/compiz issue it resolved (ie the freedesktop.org bug), it will all work really well
glisse: agd5f: yeah, at least we did
glisse: but small vram is still an issue
glisse: i am wondering if it's compiz related
glisse: like double buffering not being properly accounted
twnqx: so i added a call to radeon_cs_print() just before csi->csm->funcs->cs_emit(csi) - that should catch all commands sent to the kernel for KMS, right?
twnqx: actually, if a GPU stalls with KMS, but not without... wouldn't that mean that there's a difference in the command stream handling between KMS and UMS that is causing it? or could actually different command streams be generated?
MostAwesomeDude: twnqx: All of the drivers that do both KMS and UMS have to change the contents of their command streams because KMS command streams are checked.
twnqx: so the checked contents crashes my GPU while the unchecked doesn't? :P
zmjdroid: Hey, what were the commands I can add to xorg.conf to get thex300 to output on s-video again?
glisse: twnqx: the way things works are different too
glisse: for instance on ums we don't bind/unbind memory dynamicly as in ttm
twnqx: you mean VRAM? or system memory?
glisse: system memory
glisse: in ttm the gpu memory controller is under a lot more stress than in ums
twnqx: i kinda doubt that's the reason
twnqx: that would mean that filezilla causes more stress than firefox or mplayer
suokko_: glisse: What if some operations in filezilla result to CPU trying to access VRAM? Is there any easy wy to detect that?
suokko_: twnqx: You could try sysprof to detect where cpu time is going
suokko_: You will need quite a lot of debug symbols to produce meaning full output
twnqx: uh... i don't have cpu lockup...
glisse: suokko: you have lockup ?
glisse: you are on agp right ?
twnqx: i can ssh into the system, and i bound an acpi hotkey to "reboot" which works...
suokko: No lockups for me but I have agp
suokko: aah. That is hang and not stall :)
twnqx: well, the screen fades to white, and X doesn't do anything
twnqx: it doesn't lock up the busm true
twnqx: but that should be difficult with pcie anyway.
twnqx: gawd... i forgot almost everything about writing C programs...
Neo_The_User: twnqx: all i know, is that its a pain in the ass to write one
glisse: jdstrand: you run compiz ?
Neo_The_User: gotta go. bye all. thanks for the texstate patch
cxo: When I run the Advanced Pixel Shader test on 3dmark2001se, half the screen just shows up blue
spstarr: glisse, suokko: hello
spstarr: glisse: how will the GPU crash recording work?
glisse: for the moment i don't know
glisse: i was thinking of recording the oldest ib for which the fence wasn't signaled
glisse: as it's likely the guilty one
glisse: but i need to improve the dumping
glisse: to also dump the vertex buffer
jdstrand: glisse: KMS/EXA/compiz is the main bug, yes. There are other bugs with other combinations. no KMS, XAA, no compiz (with RenderAccel off) doesn't crash or lockup
jdstrand: glisse: s/crash/crash compiz/
spstarr: glisse: yeah, KMS right now on r6xx locks up system, it happens each time I use KMS right now
jdstrand: glisse: KMS without compiz will eventually lockup
jdstrand: (with EXA)
jdstrand: (of course)
spstarr: suokko: any more ideas or tests I should run for gpu stalls?
twnqx: spstarr: every app?
suokko: spstarr: Write a patch to fix the top 2 problems ound ;)
twnqx: for me only filezilla&thunderbird so far :P
twnqx: firefox, xchat & rxvt work
twnqx: gkrellm and e17 as wm too
spstarr: suokko: I would need to understand more of the structures first
Obscene_CNN: spstarr: what are you looking for ? bug or measuring performance?
spstarr: performance seems good for simple to mid-rendering
spstarr: Obscene_CNN: stalls that are blocking GPU from rendering a frame
twnqx: spstarr: just fix the $hang/$stall/$whatever
spstarr: twnqx: if it was that easy, we'd have perfect drivers ;p
twnqx: i don't need perfect, just usable
twnqx: and somehow non-kms fails to suspend
Obscene_CNN: spstarr, you could try my last set of patches http://www.phoronix.com/forums/showthread.php?s=a77e80930b8ceaca8cc884c886dafdf6&t=21335&page=4
Obscene_CNN: there is an issue applying them against the latest kms code.
spstarr: its damin hard, you have to deal with a lot of different things
spstarr: Obscene_CNN: looking
Obscene_CNN: I hope to have a new set by the end of the week
cxo: are they going into mainline?
Obscene_CNN: my patches will probably never go into main line (too hard to maintain
cxo: are they a hack?
Obscene_CNN: yes, but I could run astyle to clean them up
cxo: but its only for non-kms (i'm reading...)
Obscene_CNN: i did do some kms stuff, but I might have introduced a bug in the last patch
glisse: spstarr: are you using linus tree ?
Obscene_CNN: Gnome-terminal sure flies when I compile stuff
cxo: i usually minimize the terminal from preventing it slowing down the build
cxo: Is Torcs and Racer different code bases?
suokko: cxo: make &> build.log
Obscene_CNN: i do to, but I have been using build time of gettext and ncurses as one of my benchmarks. I have shaved 5 seconds of a build time of 8 minutes and 50 seconds
cxo: racer is like a gazillion times better looking
cxo: 440s, 5s? 5seconds isnt comparable, thats ~1%
cxo: cant multiply
cxo: 530s :)
Obscene_CNN: yes but a compile spends very little time outputing to the screen
cxo: i think i save about 50% by &> /dev/null
cxo: looks like Racer has become closed source :(
cxo: I knew it was too good to be open source :)
Obscene_CNN: I have been using torcs for benchmarking quite a bit but I'm not getting an improvement in frame rate any more. I do get an improvement on cpu time spent doing the physics simulatiom however.
suokko: Obscene_CNN: Time to optimize GPU side then
twnqx: should i be worried if the first command i'm seeing from the driver is not documented?
Obscene_CNN: I can measure that by having one of the computer car drivers do a practice run. The more time the cpu has to spend on the physics simulation the lower their lap times.
suokko: twnqx: Can you find where from source it is coming?
twnqx: but first do write the decoders for the documented commands to reduce the number of errors ;)
agd5f: twnqx: it might be in the code only
twnqx: what do you mean, in the code only?
agd5f: twnqx: a couple of the packets weren't in the accel doc
agd5f: but they are documented in the code that emits them
twnqx: well, 0x28 is documented for r500, but not r600
twnqx: 0x24 is not documented in either
glisse: twnqx: ignore r5xx when looking at r6xx hw
glisse: only revealent part in r5xx doc are theory on ring buffer
twnqx: it's in the defined list of packet3 commands
twnqx: is there documentation somewhere on what those do, or is it just taken from AMD's code?
glisse: twnqx: there is desc in r6xx doc, if packt is not their than there is desc in mesa code
glisse: but most of the packet3 missing from the doc are straightforward
glisse: iirc it flush stuff
glisse: agd5f: there is somethings that puzzle me in r600/r700 mesa code
glisse: the DB_DEPTH_SIZE computation seems to be the same since the begining of the driver but yet and i am seeing erronous values on some old mesa
glisse: ok, its bug in mesa
glisse: should have dump the value earlier i wouldn't have loss time, i have too much faith in code :)
suokko: glisse: What would you object in http://sprunge.us/LJIT changes?
agd5f: twnqx: you can look at the ddx too. IT_START_3D_CMDBUF is 0x24. it was for the old 2d emulation on early r6xx chips. we never used the 2d emulation, so it just basically to set the cp logic for 3D mode
Ivanovic: agd5f: as you might have seen on the list, the patch attached to the frogatto report fixes rendering
glisse: suokko: looks good
jdstrand: glisse: fyi, our kernel guy spun a new kernel. I don't know the commits but I'll report back either way
glisse: Ivanovic: mind giving pointer ?
jdstrand: (specifically for this bug: http://people.canonical.com/~manjo/lp507148-lucid/v2/)
Ivanovic: glisse: just a case of "only float support for opengl on r6xx so far"
Ivanovic: the patch adds the requires support for small, too
suokko: jdstrand: If ou have any problems in non-kms path. Can you try to downgrade xf86-video-ati to 6.12.1?
jdstrand: suokko: 6.12.1 was in Ubuntu 9.04 release (which did not have KMS). A user of mine with the exact same hardware is running that and it runs well with the following xorg.conf file: http://paste.ubuntu.com/373485/. She runs compiz and I think the most important part of the xorg.conf is that she uses XAA
steele^: hi people. I was hear a few days ago and I have a bugreport. What is the debug level or amount of info needed?
suokko: jdstrand: I meant that could you test the old driver with new kernel and mesa if they work when you boot with nomodeset?
suokko: If old driver worsk in that case then there is some regression that should be looked
steele^: background is: I have an evergreen chip, 5750, and X starts but my monitor shuts down. but I can still ssh into my maschine BUT there is no X running
suokko: jdstrand: Do you know how to do it bisect?
jdstrand: suokko: ok. with the 6.12.99+git20100126.e5933fd7 in our devel release, I encountered the bugs listed in http://bugs.freedesktop.org/show_bug.cgi?id=26302#c7. no KMS/XAA/no compiz seems solid in that version and the ones from xorg-edgers.
jdstrand: suokko: are you mostly interested in no KMS/XAA/compiz?
jdstrand: err 'no KMS', with XAA and with compiz?
suokko: steele^: Xorg.log, dmesg and gdm.log (kdm.log if you use it) should give enough
suokko: jdstrand: yes. No KMS+XAA. If they work with 6.12.1 but not with 6.12.99 then it would be nice to find which commit caused the regression
steele^: suokko: I don't use gdm nor kdm
suokko: steele^: Hod do you start the X?
xming: when will drm-radeon-testing be rebased on Linus' tree? Sometime after .33 is released?
suokko: (Just to know where stderr goes because there might be sometimes information)
steele^: suokko: I'm an arch linux user. We have a Console Display Manager "cdm" where you can decide after loggin, still without X. Very handy if there is no Xorg :)
agd5f: steele^: you need xf86-video-ati from git master for evergreen support
steele^: agd5f: I have that. Fresh compiled
agd5f: steele^: your best bet is kms
agd5f: using drm-radeon-testing
steele^: should I create a Xorg.conf ?
agd5f: steele^: no
jdstrand: jdstrand: ok. I should be able to get 6.12.1 easily enough, the bisects will be harder as I haven't built xorg outside of Ubuntu packaging. I may be able to get some help with it though
agd5f: steele^: the ums code still has some issues with some configs, but the kms code is working well. I haven't had a chance to go back and look at what's wrong in the ums case yet
steele^: agd5f: Sorry, I don't know what ums is. Usermode mode setting? kms = kernel mode?
suokko: jdstrand: buildin xf86-video-ati should be fairly easy from git. There is only a few dependecies
jdstrand: bryceh: is there anything special I need to do to get 6.12.1 radeon drivers compiled on lucid? what about git bisects? (suokko is requesting it for no KMS+XAA+compiz regressions)
steele^: agd5f,suokko http://codepad.org/zeevk1nV
steele^: my Xorg.log
jdstrand: bryceh: ie for lp: #513956)
agd5f: steele^: the ums code still has some issues with some configs, but the kms code is working well. I haven't had a chance to go back and look at what's wrong in the ums case yet
bryceh: jdstrand, for the X drivers, we have a fairly recent git snapshot in there now. For the kernel drivers, talk to apw he has l-b-m with newer bits available
steele^: agd5f: ok.. that you told me that two times means I did not understand what you want to tell me
jdstrand: bryceh: suokko wants the current KMS (which I have the latest from manjo already)
bryceh: jdstrand, for bisecting, please see http://wiki.ubuntu.com/X/Bisecting
agd5f: steele^: http://wiki.x.org/wiki/radeonBuildHowTo
jdstrand: bryceh: I am running the xorg-edgers. suokko wants me to run xorg from jaunty on lucid though. I have a feeling I am going to have a tough time with that in packaging...
bryceh: why xorg from jaunty?
bryceh: jdstrand, ^
suokko: bryceh: only ddx just to see if the drier has regression
bryceh: suokko, ok
bryceh: suokko, but would the jaunty -ati debs actually work with the lucid xserver? wouldn't they need a rebuild at least?
jdstrand: bryceh: that is what he meant
bryceh: jdstrand, apt-get source xserver-xorg-video-ati ; dch -i to change to lucid ; upload to a ppa or pbuilder or debuild it ; dpkg -i both the ati and radeon deb
bryceh: jdstrand, I don't think there's any other dependencies to worry about
jdstrand: bryceh: ok. I'll try it out then.
jdstrand: suokko: it is going to be a while-- I am testing a new kernel for the KMS+EXA+compiz bug and it doesn't typically show up for several hours
jdstrand: (or more)
jdstrand: I haven't found a reliable reproducer yet...
spstarr: glisse: I am using linus tree
spstarr: glisse: it basically is -rc7 since there hasn't been many commits since i pulled from linus
spstarr: glisse: if you have any patches for me, I will try them
spstarr: glisse: will test : http://marc.info/?l=dri-devel&m=126580047600933&w=2
glisse: don't think it will help
spstarr: ok :/
spstarr: for my GPU lockups i mean
spstarr: stalls is a different matter
glisse: it might or might not but i don't have high hope for that with this patch
spstarr: i wont apply it given your confidence level :)
spstarr: glisse: this http://marc.info/?t=126569466600006&r=1&w=2 looks interesting for removing locks
spstarr: well lesser locks
suokko: spstarr: I would say it is more important to have horter locks than lesser
suokko: But of course less locking is good too
jdstrand: bryceh, suokko: I think that the xorg-xserver-dev is too new? http://paste.ubuntu.com/373509/
spstarr: suokko: I'm assuming with the more locks there is more context switches needed vs less.
suokko: spstarr: Locks cause context switching only if there is contention to the lock. That makes sort locks a lot less like to cause context switches compared to locks that are held relative long in shared path
suokko: jdstrand: too bad :/
spstarr: suokko: seems logical to me
WhiteRabbit56: hey is anyone here aware that the "Brightness" sliders still don't work in ioquake3 games
WhiteRabbit56: (this is tested on a hd 2400xt and a hd 2600pro)
cxo: I think there is a bug present in both fglrx and in radeon
Obscene_CNN: just one?
cxo: That I've hit, yes.
cxo: There is workaround that wine uses on fglrx because of a driver bug that seems to be necessary with radeon as well
cxo: (i think you can start reading from comment 40ish)
airlied: glisse: the ram limit is just fragmentation mostly
airlied: userspace gives kernel buffers udner the reported limitt and thek nerl fails to place them from what I cn see
cxo: Is it because the developers are tainted from seeing the fglrx code, that we have the same bugs
glisse: airlied: it shouldn't fail it should go to the slow evict everybody else
glisse: either the limit we report is wrong, either userspace miscompute its usage
suokko: cxo: Or same hardware limitations
airlied: glisse: I don't think we have evict every body lse code
airlied: or did that appear when I wasn't looking
spstarr: airlied: is the TTM equivent to the VM in how it treats memory pages, marking them dirty etc?
glisse: it's ttm which will do that
spstarr: concept wise
airlied: glisse: the problem is you have to restart validation
airlied: so I dont think TTM can do it
airlied: if you are validating buffers and buffer 3 won't fit because buffer 2 is in the way from a previuos validation
glisse: maybe there is a third explanation :)
airlied: you can't kick buffer 2 out
glisse: yeah that is the third explanation
airlied: since its reserved by the validationj
airlied: the only way to do it is kick everyone out and restart validation
airlied: or do validaton largest buffer first at fixed offsets
airlied: which forces things out
AndrewR: suokko, hey, new patches ....
glisse: well this why i was thinking to transaction validation at one point
airlied: glisse: I've done the evict all and make work stuff before for Intel
glisse: i am not saying we can't do it
glisse: in fact i will do it tomorrow, i think now the checker things is fully backed
glisse: i am bore to death of testing it
glisse: spinning the compiz cube is fun 1 times ;)
glisse: ok send, so i tested it on r7xx,r6xx in ums/kms, with old/new mesa/ddx : testing was compiz,quake3,firefox,couple of mipmap demos of mesa and the lovely glxgears
glisse: oh i also tested kde
glisse: anyway i hope it won't break anythings
glisse: i am still a bit unsure about the mipmap computation
che: does anyone have a pointer about: radeon_texture.c:94: radeonFreeTexImageData: Assertion `!image->base.Data' failed.
suokko: che: bug in mesa dri driver
che: suokko, any idea what i can do to get that fixed?
che: suokko, the same code seems to work with intel driver on another box ;)
suokko: che: What code it is?
che: well it is hard to test ;)
che: www.iris2.de ;)
mishehu: if the assert() fails it mean the object doesn't exist in memory
suokko: It means that image is already mapped and assertion is to protect against wrong mapping of images
mishehu: different meaning of assertion than I'm used to
suokko: I just don't yet know why it would be wrong to map same image twice
suokko: At least one case which asserted was undefined case on OGL spec
che: maybe it helps to state that the backend in use is ogre
mishehu: ogres are like onions
mishehu: they smell bad
mishehu: and have layers
suokko: che: Ogre has large number features
mishehu: (sorry, couldn't resist)
che: yes i know but atleast it is used in other projects aswell.
mishehu: puts his hat on the channel floor upside-down
suokko: che: I was just hoping simpler test case than ogre ;)
che: yeah i agree that the test case is rather huge
che: hmm it even happens when i clock on options in the game
che: there it just queries a few things
che: let me check
che: well atleast i can tomorrow... on another box ;)
che: available resolutions e.g. rendering subsystem...
papillon81: sorry, but with the latest radeon-drm-testing i still get GPU hangups when starting Flightgear: [drm:radeon_fence_wait] *ERROR* fence(ffff8800cdac5140:0x000429C0) 510ms timeout going to reset GPU
che: just tried the ember client www.worldforge.org ... it is available atleast in fedora getting another problem (i am running on the fedora development version)
che: it also uses ogre as backend but that could be a different problem ;)
suokko: AndrewR: You had that che's error. Did you solve it?
glisse: che: which gpu ?
AndrewR: suokko, no ... (building kernel right now, spend last full day sleeping :/)
che_: sorry i missed the last few messages ;)
che_: actually yes... flightgear causes a gpu lockup here aswell ;)
suokko: che_: Which gpu?
glisse: will give a try to flightgear latter
glisse: che: any specific thing that trigger lockup in flightgear ?
che: starting it up
glisse: ok good,
glisse: so i don't have to flight around world :)
glisse: hopefully this one will lockup here
che: hehe :)
papillon81: glisse: it also takes quite long to startup, compared to UMS
che_: hmm this is a lua trace but maybe it gives more of an idea
suokko: che_: Can you open bug report about iris crash?
papillon81: che_: i could run FG through gldb
papillon81: but that's probably leading nowhere
suokko: che_: What version of mesa you have?
AndrewR: suokko, you fixed my bug (oops with benchmark=1) http://pastebin.ca/1793223
suokko: AndrewR: I tried it too and after it oopsed you know what I do ;)
suokko: AndrewR: Looks like your gpu to main memory access is tad slower than mine
AndrewR: suokko, this is with agp 4x (it works this run)
suokko: Then you get surprising close values to what 4x theoretical limit is
suokko: AndrewR: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.ati/12852
AndrewR: suokko, i don't have your "slow Xv" bug .... for me right after startup mplayer gives fluid picture... may be because "my machine too slow to play this" (i haven't this popular warning on no-sound clip) http://pastebin.ca/1793238
airlied: suokko: have you got PAT support btw?
suokko: airlied: yes. It is configured to kernel
airlied: suokko: no does it show up in dmesg as enabled?
suokko: airlied: yes
AndrewR: suokko, your ddx patch works too ...down to 61.221s but it may be just few background processes during this run
AndrewR: suokko, *fewer
airlied: suokko: does nopat make your VRAM test faster?
suokko: airlied: I try it
AndrewR: prepares to run few videos in parallel
suokko: AndrewR: You could probably get a bit more performance if you changed memmove to memcpy for Xv
airlied: benh: ping
suokko: airlied: (II) RADEON(0): BENCH: memcpy() 3145728 bytes to vram took 119920us, resulting in 26Mbps
suokko: (II) RADEON(0): BENCH: memcpy() 3145728 bytes to gtt took 7135us, resulting in 440Mbps
airlied: suokko: so slower then with nopat
suokko: And system feels like it is running with uncached main memory
suokko: So something went wrong now
suokko: But mtrr is showing that everything is either write-back or write-combine
suokko: Is it possible that only rebooting would cause some pages to stay in WC from pat enabled kernel?
suokko: I'm going to try cold boot anyway
suokko: I learned at least something. nopat is not going to work with my configuration
benh: airlied: pong
airlied: benh: got some wierd stuff reported on a 32-bit ppc kernel yesterday
airlied: like KMS loads but stuff in sysfs is wrong or not there
benh: powerbook ?
airlied: yeah rv100 one
benh: I can give a try, it's current upstream ?
benh: rv100 ?
benh: I -had- one of these years ago :-) but no longer
airlied: actually it was probably a desktop mac
benh: ah ok
benh: well, I'll see what I can test with
airlied: lemme find the dmesg
airlied: benh: for example [Remote host closed the connection]
airlied: should have a drm link in sysfs
airlied: thats an ls from /sys/bus/pci/devices/
benh: I'll try to find out
airlied: my ppc64 kernel seems to have all the bits correct
airlied: unless its some domain related bonghits
cxo: Apple doesnt use any PPC64 cpus anymore right?
airlied: cxo: no
Neo_The_User: cxo: they use Xeons
Neo_The_User: x86 based intel CPUs IIRC
cxo: so the only ati + ppc64 setup on currently purchaseable hardware would be an IBM Cell blade?
airlied: wonders where the radeonhd.org logger is gone
benh: cxo: no ATI on the cell blade
cxo: How come you guys dont work on the currently sold hardware (r700,r800) as much as you do for the old hardware? Logically i'd think you work on whats currently sold, and then work backwards into legacy applications
airlied: ah cbrill one is still here
suokko: cxo: What is odds that we would have such a new hw?
cxo: you tell me? r700 is like two years old
airlied: has lots of hw, but lots of bugs
airlied: benh: http://pastebin.com/m3a57f1fd is the dmesg
Neo_The_User: the odds are very high considering airlied has literally every GPU ever made by ATi pretty much :P lucky guy
suokko: has less hw but enough bugs
airlied: also I've lots of customers using rv100s
airlied: and rn50s
cxo: Anyone who has had to use an ati card in their lives pretty much secures them a place in heaven
Dr_Jakob: send airlied his condolences
suokko: airlied: btw, Can you upload a r100 piglit run from the latest mesa?
airlied: suokko:let me see if I can plug in my laptop somewhere
airlied: needs more sockets
suokko: airlied: no hurry. I just tough it would be handy to check if there are same bugs as with r200
benh: vgaarb: invalid PCI address!
benh: I wonder what that is
airlied: benh: fix is upstream
airlied: I think
airlied: SGI added better domain support
benh: anyways, nothing bad in the log
benh: I'll have to test
airlied: but radeon ignores return codes from vgaarb
airlied: what machine is it btw?
benh: silver G4 desktop
airlied: suokko: btw your rv2xx isn't a laptop is it?
agd5f: airlied: if he ever does get it working it may need a custom connector table as apple has likely wired it up weird
agd5f: it's using the generic default at the moment
suokko: airlied: it is
airlied: agd5f: yeah I need a hack to not read the bios also
airlied: suokko: does it suspend/resume okay with KSM?
airlied: KMS even
agd5f: airlied: I swore we had a check for that already. maybe it was in the ddx
airlied: agd5f: yeah DDX has it
suokko: airlied: after resume I get about 3pixel high area at top of blank gnome screensaer from running gl applications
airlied: suokko: can you get me a dmesg across s/r on it?
suokko: airlied: http://sprunge.us/XSbV
suokko: This time resume had white blank gnome screensaver
suokko: Is that security clearling of framebuffer in s/r?
suokko: Because before I used to sometimes see my desktop before suspend for short moments
airlied: no its just fail
airlied: okay the radeon doesn't bother suspending
agd5f: mcencora: hw doesn't support texturing from Z24_S8
airlied: suokko: could you try http://people.freedesktop.org/~airlied/scratch/pm-hacks.patch
airlied: suokko: it might cleanly apply
airlied: suokko: r100 piglit http://people.freedesktop.org/~airlied/piglit/
cxo: Is there a guide on how to build piglit?
suokko: airlied: I bet you didn't run rc7 kernel ;)
cxo: fukin hates non-GNU make stuff
airlied: suokko: good point
airlied: suokko: will update kernel
airlied: cxo: cmake . ; make
cxo: it gives me some weird errors, What are its dependencies? I dont have much python stuff on my pc
airlied: libtiff, libpng stuff like that I think
cxo: well this is what i get, http://en.pastebin.ca/1793344
airlied: it needs glew
airlied: or libglew or whatever your distro calls it
Neo_The_User: i use glew from mesa
cxo: i build mesa. do i add something to configure to build glew as well?
cxo: (whatever glew is)
Neo_The_User: it builds automatically (least for me)
cxo: but doesnt it need python bindings then for all this stuff?
cxo: (mesa configure says, GLU: yes, GLw, yes (Motif:no) )
Neo_The_User: check and see if glew.o exists in bin in the root of mesa build dir
Neo_The_User: i think thats where glew.o is...
cxo: there are no binaries in mesa/bin
cxo: only scripts
Neo_The_User: ohh.. src/glew
Neo_The_User: sorry about that
airlied: glew comes from outsidem esa
airlied: its should be a separate package
cxo: yes there is a glew.o there
airlied: and what has python got to do with it
cxo: i though piglit was all python?
Neo_The_User: was pwned by airlied once again
airlied: cxo: no the tests are C
shadowmaster: Mesa's configure from git master complains "Requested 'dri2proto >= 2.2' but version of DRI2Proto is 2.1"; in a Debian system, what would I need to upgrade/replace/check to solve this?
cxo: ok, apt-get install libglew1.5-dev seems to have done the trick
shadowmaster: (am I on-topic?)
Neo_The_User: shadowmaster: i think so.
airlied: shadowmaster: the xorg proto package
airlied: not sure what Debian name it or package it in
Neo_The_User: git clone git://anongit.freedesktop.org/xorg/proto/dri2proto && cd dri2proto && ./autogen.sh --prefix=/usr && make && sudo make install && cd ..
cxo: that works too :)
shadowmaster: okay, good
Neo_The_User: you might need glproto from git too
Neo_The_User: and xf86driproto for compiling xf86-video-ati
Neo_The_User: shadowmaster: what card?
Neo_The_User: just curious
shadowmaster: 01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics]
Neo_The_User: shadowmaster: lucky you. http://neo-technical.wikispaces.com/radeonhd-3d
shadowmaster: just trying to build mesa from git master; I've been running with Mesa 7.7 before and with xf86-video-ati from the repository
shadowmaster: no KMS, though
Neo_The_User: oh ok.
cxo: is piglitting
shadowmaster: well, "make: Nothing to be done for `all'" when trying to build dri2proto :/
jcristau: shadowmaster: that's fine
Neo_The_User: sure is :D
shadowmaster: yeah, really, I only see a .h :P
shadowmaster: should've known better
cxo: is there a way to get piglit from continuously creating windows and taking focus away from what i'm doing?
Neo_The_User: IRC isn't helping my ADHD so i g2g. take care all. best wishes to all your problems.
airlied: cxo: no its meant to just do its thing
airlied: running the quick.tests reduces the amount of time it ktae
mattst88: airlied, all 15 unaligned access violations on start up happen at atom_get_src_int, the ATOM_ARG_PS case, at line 215 ("val = le32_to_cpu(ctx->ps[idx]);")
mattst88: &ctx->ps[idx] % 4 is always 2 when it's unaligned.
mattst88: I've added a ton of printks and tried tracing this back up the tree, but this just created an immense amount of data that I can't handle.
airlied: mattst88: yeah I think atom is just unaligned by design
mattst88: if that's the case, we should still be able to let the compiler know about it.
mattst88: I tried "val = le32_to_cpu(get_unaligned(ctx->ps[idx]));" but it caused a kernel panic.
airlied: mattst88: might be useful to try and find what tables its executing
mattst88: yeah, OK. I saw that the top of the atom_* call tree was always atom_execute_table.
mattst88: airlied, uint32_t cmd_table in atom_context?
airlied: mattst88: also if its reentered
airlied: as calling subtables is mostlikely to cause this
airlied: mattst88: its the index passed into atom_execute_table_locked
mekius: anyone know why my server and client glx would be different versions or at least which files coorespond to what?
mekius: using the latest stuff from mesa git for r600
mekius: but still on kernel 2.6.32
BioTube: "server GLX" is probably for the X server while "client GLX" would be what libGL(and/or the driver) supports
mekius: BioTube: thx, I gathered that already :)
mekius: so to update the server glx I would install a newer xorg?
BioTube: unless it's in the ddx, which I doubt
mekius: what's even more strange is the soname for my libGL is 1.2, but glxinfo reports 1.4 :/
airlied: thats not strange at all, since they aren't related
mekius: so where the heck are all these glx libs?
MostAwesomeDude: mekius: For DRI1, GLX is 1.2. For DRI2 on Xserver 1.7+, it'll be GLX 1.4.
MostAwesomeDude: Nothing you can do to change it.
mattst88: airlied, http://pastebin.ca/1793387
mekius: running 1.7.4 and it's using dri2 :/
mekius: yet I get this: http://pastebin.com/m14edf641
mekius: client is 1.4, server is 1.2
mattst88: airlied, tables, 42, 21, 24 yield unaligned accesses.
MostAwesomeDude: mekius: Huh, weird.
mekius: MostAwesomeDude: you're telling me :P
mekius: would Option "DRI" "on" screw it up?
mekius: or loading dri at all
airlied: mattst88: SelectCRTC_Source and DAC_LoadDetection at least then
spstarr: glisse: oh I'll be sure to tell you if it breaks things, if the patch is posted ;-)
spstarr: lots of Dell boxes has RN50/r1xxs cards onboard.
spstarr: airlied: I have an r1xx it has Fedora 12 on it my web server box, i can run piglit but i will need new mesa/kernel/libdrm/ddx.
spstarr: goes to sleep... busy day!
mekius: MostAwesomeDude: Any other ideas?
mekius: going to try updating libdrm again, but don't think that's the problem
mattst88: airlied, thoughts on http://pastebin.ca/1793427 ?
mattst88: it fixes all the start up unaligned access errors
mishehu: ok, so I'm a little bit in dependency hell here. I have to update dri2proto and had to do util-macros as well. since dri2proto is just really header files, do I need to recompile anything other than those components listed on the radeon how-to page? I have to up dri2proto for mesa.
BioTube: mishehu: you don't need to recompile
BioTube: mishehu: they're just macros
mishehu: ah because I do definitely see all sorts of differences in structs in dri2proto
mishehu: compared to what is currently on my system
BioTube: shouldn't be a problem
mishehu: hope so. continuing on :-)
airlied: mattst88: yeah I think we could handle that
mattst88: airlied, alright, cool. I'll see if it also fixes up the unaligned accesses when starting X, and mail you the patch
mattst88: airlied, what is the 'ps' member of atom_exec_context?
airlied: parameter stack I think
mekius: sigh, this is getting annoying :/
mattst88: mishehu, what distro are you using?
mishehu: ah that must be the drm-next guy :-)
mishehu: mattst88: slackware 13.0
mishehu: mattst88: normally I don't end up in dependency hell as I rarely touch things like Xorg
mishehu: but I want newer features for my hd 4890, so I need to use more bleeding edge radeon drivers
mishehu: grr now I need glproto
mekius: should texture_to_pixmap work with the latest of everything?
mekius: on r600 that is
mekius: r700 rather
agd5f: mekius: yes
mekius: k, so seems I just need to figure out why the server glx is 1.2 instead of 1.4 :/
mekius: could it be a permissions problem? I don't see any errors in my xorg.conf or dmesg
MostAwesomeDude: mekius: It should just work. More importantly, why do you need GLX 1.4?
mekius: i want texture_to_pixmap to work :P
mekius: get a bunch of warnings about not having glx 1.3 when something is using it
MostAwesomeDude: They're only warnings, and they're warnings from Mesa, not your app.
agd5f: mekius: you can ignore those
mekius: also getting corruption, but not sure if this is the reason or not, but want to rule it out
mekius: yeah I know they are mesa warnings
MostAwesomeDude: No, it's not the reason.
mekius: but will it work even though it's reporting the wrong version?
agd5f: mekius: yes
mekius: i'm just wondering if I have something screwed up and thus I actually don't have the latest of something installed and thus the problems
agd5f: tfp required glx 1.3, but no one enforced it until recently
mekius: thus i'd like to see it be 1.4 like it's suppose to be so I know it's up to date heh
mekius: yeah I saw the commits and such about the new warnings
mekius: is there anything besides compiz that does a lot of compositing via gl?
airlied: mekius: kwin
mekius: which requires kde eh?
mekius: anything that doesn't involve kde or gnome? :D
lmurray: KWin only depends on kdelibs and kdebase-runtime
lmurray: It doesn't depend on KDE SC
mekius: only :)
airlied: mattst88: isn't therre get_unaligned_le32?
mattst88: airlied, not sure. I'll check.
airlied: I think everyone else uses Xrender
mattst88: airlied, did I _just_ miss the merge? :)
airlied: mattst88: that one ;-)
airlied: we can always push that patch back to stable later if it works
mekius: nice, compositing seems good now :)
mishehu: any idea what XCB is in mesa?
MostAwesomeDude: The same thing as it is everywhere else. Just a different option for talking to the X server.
mishehu: well I never personally encountered XCB before so I had no idea what it does. so the fact that it is elsewhere doesn't help me know it :-)
cxo: knew that would have been the case
cxo: its just a way of talking to the X server. Think of it like a protocol for drawing things on the X server
mishehu: grrr mesa build problems...
mishehu: ffb_xmesa.c:661: error: 'TRUE' undeclared (first use in this function)
ajax: hah, ffb driver.
mishehu: I'm using slackware's build script which builds for multiple chipsets
cxo: honestly TRUE and FALSE should be like NULL by now
ajax: honestly people shouldn't fucking invent new #defines for booleans in a language that has perfectly unambiguous truth values already
mishehu: ajax: agreed
mishehu: but that's in mesa git from earlier on today
mishehu: like how hard is it to understand "0 == false, 1 == true"
MostAwesomeDude: You might be surprised.
MostAwesomeDude: e.g. EXIT_SUCCESS, or the equiv. Success in X.
cxo: yeah but what if you need to read the register from a lie detector and it was like at address 0x8, so you need to #define TRUE 0x8, then what are you gonna do huh??????
cxo: this is what i ran into -> https://bugs.freedesktop.org/show_bug.cgi?id=26525
cxo: (ie. the bug common to fglrx and radeon i mentioned earlier)
ajax: MostAwesomeDude: there are two common conventions for C
ajax: one is foo_has_the_bar_nature(), which is 1 or 0
ajax: the other is do_something_complicated(), where !0 indicates what failure you hit.
ajax: if you have sensible function names, this is utterly straightforward.
MostAwesomeDude: ajax: Right.
ajax: if you don't, put down the compiler and step away from the keyboard
cxo: c++ defines true and false i think, probably C is just rebelling
mishehu: nah c++ is just a little more anal
MostAwesomeDude: ISTR good reasons for no builtin boolean, but I can't recall them.
cxo: couldnt have been that good if you forgot
cxo: is at a cross roads. There is only one slice of cake left in the fridge. its a bit bigger than what i usually slice, but only by a bit. It would be rude to leave just a slither in the fridge. Eat it all and get far, or leave the slither behind. Decisions decisions.
mishehu: cxo: if you're dedicating this much brain power, you need to replenish those carbs for your brain. eat the whole piece and be done with it heh
mattst88: cxo, c99 has stdbool.h, which defines bool, true, and false.