Nightwulf|work: hi all
airlied: hmm openarena on an rv100 no-tcl card not the best gameplay
soreau: Isn't rv100 a bit.. old?
airlied: yeah probably more of a q1 card than q3 ;-)
soreau: ;)
hifi: if q1 runs well on r100 and linux, it's a success
MostAwesomeDude: airlied: dberkholz is relenquishing a big box of cards tomorrow; includes r100 and r200.
MostAwesomeDude: I'm thinking of making a big wall of cards. It'll be awesome.
MostAwesomeDude: But then I have to make sure shatter works on all the EXA-capable ones. :C
hifi: didn't the first on-chip 3D accelerators do a poor job with q1
hifi: like ~20-30 fps at 640x480 compared to voodoo
soreau: MostAwesomeDude: Most Awesome :D
MostAwesomeDude: soreau: Fairly awesome. Not sure what I'm going to do with mga though.
MostAwesomeDude: KMS FOR EVERYBODY!
MostAwesomeDude: *** Two Hours Later ***
airlied: mga is probably the only chip left that kms might make some sense on
MostAwesomeDude: LET'S GO TO THE PUB!
MostAwesomeDude: airlied: Maybe r128 too?
airlied: they still sell mga chisp for servers, you can make ajax go insane by asking him about them
MostAwesomeDude: What.
airlied: yeah r128 should be possible by porting radeon
MostAwesomeDude: No. I like ajax. He let me pass GSoC.
MostAwesomeDude: The problem with r128 that I see, is whether it should go in radeon or r128 module.
airlied: radeno
agd5f: MostAwesomeDude: it's 99% the same for most drm stuff
MostAwesomeDude: So you'd need both r128 and radeon insmod'd for DRM, or -- oh.
MostAwesomeDude: Huh. Maybe. When I get really bored during winter "vacation."
airlied: MostAwesomeDude: no no more r128
MostAwesomeDude: airlied: I can live with that. :3
airlied: needs to setup r600 test box at home
airlied: playing with pci r100s isn't as much fun
hifi: I have a Rage128 lying somewhere
airlied: I plugged one in somewhere recently
agd5f: I had the ddx merged and even got textured video working: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r128-support
agd5f: never got around to dri though
airlied: you'd have to port the r128 mesa driver to radeon-rewrite also
airlied: which may or may not be fun
agd5f: although lakc of npot textures sort of makes it not worth it
spstarr: MostAwesomeDude: Moar KMS
airlied: yeah not having tex rects is kinda fail
Lutz_Ifer: http://img1.abload.de/img/bildschirmfoto-2f5cu.png looks like 3d still doesn't work perfectly for me ...
agd5f: Lutz_Ifer: what chip?
Lutz_Ifer: kernel 2.6.30-1-686, debian squeeze/sid, xorg 1.6.3, release 2009-7-31, Mesa DRI R300 (RS400 5955) 20090101 x86/MMX+/3DNow!+/SSE2 NO-TCL, running on a Radeon XPRESS 200M 5955 (PCIE)
Lutz_Ifer: drivers from git, about 3-4 days old
mcgreg: with the latets mesa I am getting now: Xlib: extension "GLX" missing on display ":0.0".
mcgreg: Error: couldn't get an RGB, Double-buffered visual
mcgreg: I believe someone was getting that "error" yesterday already
fpoibaf: agd5f airlied: can you add info about Z pipes in dmesg also on non KMS, as it is with KMS?
agd5f: fpoibaf: unless you are on an rv530 you have 1 z-pipe
fpoibaf: I am on a RV530 and with KMS it tells me 2 pipe
fpoibaf: has anyone be able to run doom3 on a R500?
fpoibaf: it lockups when starting a new game here:
fpoibaf: Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX/SSE2 TCL
taiu: fpoibaf: yes, currently doesn't run probably bugs 22528 22372 22742
fpoibaf: taiu: ok, thanks, I filed two of that bugs indeed
taiu: fpoibaf: didn't realize it was you :)
spstarr: hmm
spstarr: oh new
spstarr: oh neat
spstarr: DDX is now exposing DisplayPort
spstarr: DisplayPort-0
spstarr: DisplayPort-0 disconnected (normal left inverted right x axis y axis)
spstarr: well the new RandR/Xserver
airlied: nothing to do with randr or xserver
airlied: should've been exposed for a while
vehemens: hmm, still see the compiz corruption with the vertex fetch shader fix.
vehemens: with compiz, if i reposition the engine window, i can cause the text corruption to change. similar to the compiz font/menu corruption problem.
vehemens: i found that the engine demo has text corruption independent of compiz, so i wrote a bug report to document the test case.
airlied: glisse: btw what was last status of page alloc? was there any objections?
glisse: airlied: i don't remember :)
glisse: i think it worked for everyone who tested it
airlied: glisse: I'll put it into drm-nexst
Lutz_Ifer: okay, that crash is reproducable
Lutz_Ifer: memo to myself: do not move opengl-windows out of your screen
suokko: MostAwesomeDude: CPPFLAGS=-m64
airlied: glisse: you fixed rs690 shouldn't rs600 be the same?
glisse: airlied: yup :)
glisse: i was looking at rs600
glisse: and was saying that to myself too :)
airlied: just have to make it use rs690_init or will I rename it to rs600?
MostAwesomeDude: suokko: Hm?
suokko: Just so you can test 64 bit builds without 64 bit machine ;)
MostAwesomeDude: suokko: But if I can't execute it, then there's no point.
suokko: MostAwesomeDude: Jsut put -Wall and -Wextra and fix everything ;)
MostAwesomeDude: suokko: If only that were all that were needed. :3
suokko: It is not but at least it would keep the problems at minimum level
MrCooper: -Wall would be good enough for now
MrCooper: we're probably lucky if none of those cause any real problems anywhere
suokko: I wonder how legacy bo system causes problems with ref counts :/
MrCooper: e.g. implicit function declarations can result in the parameters being passed incorrectly in some cases
glisse: airlied: well i have a patch underway in which i can change that
glisse: will switch to generated file too
airlied: glisse: cool I might send the quick hack to Linus tree, and do it properly in drm-next
legume: agd5f: R600: code cleanup has caused a memory leak, gears eats about 3 meg/sec. Also seen by someone on phoronix.
nanonyme: Bo's not getting freed/recycled properly?
suokko: legume: commit id would be nice for fast look up :)
legume: suokko: 8dd151b947c36100f38cf83eca674bd427b23e47
nanonyme: Probably faster to search log than wait for answer
nanonyme: Lol
nanonyme: Apparently roughly as fast. (searching log on the bed is slow though, haven't yet managed to get up)
suokko: problem is that I can't match which commit is that ;)
legume: nanonyme: :-) distracted, BTW does gloss (or reflection/lighting on curves generally) look wrong for you?
nanonyme: Just starting up my computer.
legume: nanonyme: wow, you can do IRC telepathically :-)
nanonyme: No, I can IRC with my cell phone from the bottom of my bed. Faster than kicking oneself out of the bed and starting up a computer.
marvin24: Hi, Qt apps are still crashing here with graphicssystem opengl (rs690, all trunks uptodate)
nanonyme: Hmm, had dreams of KMS. :3
marvin24: backtrace at http://pastebin.com/m72d7ee4b
marvin24: does it deserve a bug report?
nanonyme: vaguely recalls that would be a chip that should alredy have a stable 3D
nanonyme: So hmm, maybe.
marvin24: nanonyme: could this also be a Qt bug?
nanonyme: I honestly don't know.
AndrewR: hi all .. i have question about open Arena ... i tried it with current mesa and rv280, and intro was gust grey ... may be related to http://pastebin.com/m7bb12bee (Using 4/4/4 Color bits, 24 depth, 0 stencil display.)
AndrewR: *just grey
nanonyme: legume: You seem to be correct, pretty definite memory leak. Also performance loss.
airlied: AndrewR: you running in 16-bit?
suokko: AndrewR: gery and not black?
suokko: grey*
suokko: wonders if nanonyme could send a patch to fix the leak
marvin24: it seems that Qt triggers an assert(bo->space_accounted) in cs_gem_write_reloc.c, which is in the drm tree
nanonyme: suokko: Probably not. I see the likely location but I don't understand why that could leak.
marvin24: is there a way to debug this further?
nanonyme: suokko: There's a new condition before memory unmapping.
suokko: marvin24: Looks like flush in wrong place
suokko: marvin24: Can you get a backtrace with debug symbols?
suokko: Debug symbols for mesa is only part that I would need. No need for qt
nanonyme: Ah, well. I'll comment out the line, see if it gets rid of the memory leak.
marvin24: it is here: http://pastebin.com/m72d7ee4b
AndrewR: suokko, 24 bit. Grey .. or may be because i boost monitor settings, too dark image
nanonyme: (actually now I'm not that sure anymore)
suokko: There is probably bug in 16 bit mode so if you can make open arena use 32 bit mode it would help knowing where bug might be
suokko: for AndrewR
suokko: marvin24: Looks like bug in swtcl path
nanonyme: What does pbo being mapped actually imply? Should pbo->ptr always return a non-zero value when tested against then?
suokko: marvin24: Can you run the application with RADEON_DEBUG=fall. I'm interested why it is using swtcl :)
nanonyme: (apparently the problem is bigger than just that :P)
suokko: Even tough that is not bug fix but just missing feature probably
airlied: suokko: rs690 is a swtcl gpu
airlied: suokko: it doesn't do hwtcl
suokko: aha :)
airlied: R300_NO_TCL=1 emulates it
airlied: on tcl cards
nanonyme: Hmm.
AndrewR: suokko, http://pastebin.com/m41173df (openArena config ... looks like everything set to 32/24 ? textures, colors ...)
marvin24: here's the result of a RADEON_DEBUG=all run: http://pastebin.com/m5efff839
Zajec3: how did u make RADEON_DEBUG=all work?
Zajec3: should I define something somewhere before compilation?
Lutz_Ifer: can i somehow change, which monitor will be primary and which one secondary?
marvin24: Zajec3: no, but you need some r400 or lower I think
suokko: AndrewR: I don't know how it is selecting the 4/4/4 bit mode
AndrewR: suokko, chromium an xmoto both starts norma ll. may be bug in OA (i have 0.7.0 binary version) or SDL
AndrewR: *and
Zajec3: ah, i compiler r600 only
Zajec3: *compiled
nanonyme: suokko: Hum, do you think RADEON_BO_TRACK could provide additional information on the fates of the pbo's?
suokko: nanonyme: sure. But that will generate a lot of data ;)
suokko: and you have to recompile libdrm_radeon and mesa with it or you will have problems with different structure format
nanonyme: Blah, right.
nanonyme: I could speculate that it's to do with unreffing bo's that carry a load still but but. It wasn't that additional condition anyway, taking it off mostly made things worse. ;) Smells like some stuff for which you actually need to understand the program flow and state of data structures pretty well. ;(
nanonyme: Wait a minute, I've been looking at a different commit as what legume gave... Maybe I have too much memory to ever have noticed the memory leak before. *headdesk*
nanonyme: legume: So you meant http://cgit.freedesktop.org/mesa/mesa/commit/?id=8dd151b947c36100f38cf83eca674bd427b23e47 which is pretty much an ancient commit. I thought the problem was http://cgit.freedesktop.org/mesa/mesa/commit/?id=dadf138ddbaecd7fff239df7961aac25e74f14f6 which was the only one I didn't yet have
nanonyme: Explains a lot anyway.
Zajec3: which DRI driver I need to compile to have debugging in r600 dri driver?
airlied: r600
Zajec3: er, it is not enought
Zajec3: RADEON_DEBUG=all doesn't give anything
airlied: I'm not sure the RADEON_ flags to anything for r600 yer
Zajec3: ah... ok :(
Zajec3: marvin24: i thought you mean i need to compile dri driver lower that r600 to have debugging in r600 :)
Zajec3: marvin24: misunderstood you :)
nanonyme: Well, that wouldn't have made much sense...
legume: nanonyme: reverting dadf138ddbaecd7fff239df7961aac25e74f14f6 alone does not fix, though you need to revert in order to revert 8dd151b947c36100f38cf83eca674bd427b23e47
nanonyme: Right.
legume: nanonyme: I also didn't notice yesterday because I didn't run the tests long enough.
nanonyme: I mostly didn't notice because I have 3 gigs of RAM and 4 gigs of swap so having 2-3MB/s memory leak isn't likely to become visible very soon.
nanonyme: Little over 16 minutes before it starts swapping if I calculated corectly.
nanonyme: (with assumed zero memory consumption)
nanonyme: legume: But yeah, I suspect I actually *did* run into it. Just didn't realize it. Played Scorched 3D at a point and hard disk started making a noise just before the game crashed. Probably ran out of RAM.
nanonyme: (despite attempts to push non-critical stuff into swap)
suokko: airlied: another evil optimization idea from me is http://cgit.freedesktop.org/~suokko/drm/commit/?id=a641399754a4e8814b3a1d68a22a44115b69bec5
suokko: I could get rid of one of state variables for section but I didn't think about it early enough so current version has one too many variable
suokko: But now to debug the r300 crash :)
airlied: suokko: I'll look at it tomorrow, man fpsgain
airlied: many fps gain even?
airlied: or just drop cpu use more
suokko: airlied: I didn't test it. But it shoudl drop cpu usage for state emit
suokko: Also it allows parallel state emit in future if someone wants to write it
suokko: With minimal change that cs->cdw is handled with atomic operations
suokko: No locking ;)
airlied: btw the main issue with doing lots of inlines in a library header is it becomes a useless shared lib since you have to rebuild everything if you upgrade it
_kopsu_: Hi. I've got an question about new r600 drivers/mesa git.... i've installed everything from git (drm from agd5f's git) and mesa master etc. but can't get 3d to work...
airlied: so its a tradeoff
airlied: bed &
_kopsu_: testing it gives out: Error: couldn't get an RGB, Double-buffered visual
suokko: airlied: It can be made also non-inline :) gn
nanonyme: _kopsu_: Sounds like you might not have latest Mesa git.
_kopsu_: glxinfo says: OpenGL renderer string: Mesa DRI R600 (RV770 9442) 20090101 TCL
nanonyme: Oh.
nanonyme: Nevermind, separate thing.
_kopsu_: mesa is from git (using gentoo x11 overlay)
_kopsu_: and drm is patched to fetch agd5f's stuff
_kopsu_: 2d stuff works fine... exa and texturedvideo etc
nanonyme: suokko: Btw, ironically in the last week or so r600 fps in glxgears has dropped with roughly a thousand during the development. ^^
_kopsu_: no mentionable warning or errors in xorg log... dri is enabled
mcgreg: _kopsu_: getitng the same as you
suokko: nanonyme: Ironically all my optimization is for cpu side and glxgears is not limited by cpu speed ;) But real world 3D is limited by cpu so I get extra fps by doing optimizations
mcgreg: 3d with mesa was fine all the time , until I instaleld updatred mesa master tpoday and it broke
nanonyme: suokko: I doubt it's your changes. Mostly probably some attempts to get the driver to render right have slowed it down.
suokko: And probably memory leak is slowing down too
nanonyme: Yeah.
nanonyme: Not being able to recycle bo's is a pretty much guaranteed slowdown.
mcgreg: ahh just updated mesa from git again and now mit is fine again
suokko: But I have lost 80 fps (10%) in gears but gained 20 fps (40%) in xmoto ;)
mcgreg: _kopsu_: update it now again - seems to be fixed now
nanonyme: :p
_kopsu_: yeah mcgreg
nanonyme: suokko: Yeah, these regressions are across the scale. :)
nanonyme: wonders if valgrind would help
suokko: nanonyme: no. There is forced free for bos inend
nanonyme: Hrm.
suokko: of course you could remove that code and then use valgrind ;)
nanonyme: Sounds intriguing.
algol: what do MPLL and SPLL stand for? I guess Memory and...?
suokko: bo manager dtor has that in radeon_bo_legacy
nanonyme: Intentionally break a program to allow debugging.
mcgreg: hmm openarena freeued again during the loading screen
nanonyme: mcgreg: Indirect?
mcgreg: no
mcgreg: normal
nanonyme: Werd.
mcgreg: it worked before thre last update - well, from yesterdax or so
nanonyme: Works for me.
mcgreg: i'll tets it again
nanonyme: Or "works".
nanonyme: mcgreg: You might want to restart X server if you have had failures. I've noticed it sometimes help to avoid future ones.
mcgreg: yeah it crashes/freeeus right in the moment before it should start .. aftewr loading the map+gfx
nanonyme: As in, eg some OpenGL programs wouldn't go fullscreen until I had restarted X server.
mcgreg: bz, does anyone have any idea why the corruptions are happeing in openarena? quake2/alien arena seems to be fine - as well as billiard-gl, google earth
suokko: mcgreg: Probably vertex format problems
mcgreg: nanonyme: hmm but if restating X server fixes it .. it is a mesa problem o rather some X problem?
nanonyme: God only knows.
nanonyme: I suspect Xorg stack isn't really all that fault-tolerant.
suokko: Some state gets broken and you won't be able to do anything so restarting application with broken state helps
_kopsu_: mcgreg, do you have AIGLX enabled in xorg.conf?
suokko: Sometimes it is even GPU that is in broken state ;)
nanonyme: suokko: Which is why KMS has GPU reset?
mcgreg: no => (**) Option "AIGLX" "Off"
suokko: yes
suokko: Too bad reset doesn't work for me :/
_kopsu_: mcgreg, ok. i'dont have it neither... just pulled newest mesa from git but it still says; Error: couldn't get an RGB, Double-buffered visual
nanonyme: does have AIGLX *shrug*
nanonyme: I doubt it matters though.
_kopsu_: ok, what about EXANoComposite?
nanonyme: I'd assume that's irrelated but why do you have that? :)
_kopsu_: it's commented out
suokko: _kopsu_: glxinfo | curl -F file=@- http://noapste.org/a
_kopsu_: url..?
_kopsu_: yea
Lutz_Ifer: if i switch on the external monitor via xrandr it becomes the primary monitor, how do i change that?
_kopsu_: there's nothing unusual i think in my glxinfo, it should work. only complaint is about: IRQ's not enabled, falling back to busy waits: 2 18
_kopsu_: but it's normal at this point of development?
_kopsu_: or is at least known
nanonyme: _kopsu_: You forgot to paste the result url.
_kopsu_: aa sorry
_kopsu_: http://nopaste.com/p/ahFbLxgDH
nanonyme: You're missing all GLX Visuals in your glxinfo...
_kopsu_: and xorg log: http://nopaste.com/p/aAPVXiA1N
_kopsu_: hmmh.. why it is so.. :(
nanonyme: No wonder it can't draw anything.
legume: nanonyme: old glxinfo will look loke that, running the one in mesa tree would likely show them.
nanonyme: Oh?
nanonyme: legume: But doesn't that mean he failed to install a newer Mesa?
nanonyme: Since he iirc tried to install it from git.
_kopsu_: it's compiles fine (gentoo x11 overlay media-libs/mesa-9999)
legume: nanonyme: I don't think xdemos get installed with just make install
nanonyme: Good point.
nanonyme: So yeah, could rather pastebin the output of progs/xdemos/glxinfo
nanonyme: _kopsu_: I'd update the radeon driver too.
legume: _kopsu_: maybe try with AIGLX enabled, you shouldn't need to disable it.
_kopsu_: hmmh.. i thought that i did emerge xf86-video-ati-9999 and it's newest. today.
nanonyme: legume: Note that there's no occurrance of r600_dri.so in his xorg log.
_kopsu_: hmmh
nanonyme: It loads swrast intead.
_kopsu_: maybe modules-update or something like that
nanonyme: _kopsu_: Are you sure your r600_dri.so is in /usr/lib64/dri?
_kopsu_: i'll check it immediately
nanonyme: (though that doesn't even seem to be checking for it and I don't immediately understand why)
_kopsu_: -rwxr-xr-x 1 root root 2.5M 26.8. 15:03 r600_dri.so
_kopsu_: yeah it is
nanonyme: Then what the heck is preventing X server from trying to load it...
_kopsu_: real mystery to me
nanonyme: I'd migrate to a newer X.org stack though.
_kopsu_: hmmh. /etc/env.d/03opengl/ : LDPATH="//usr/lib32/opengl/xorg-x11/lib://usr/lib64/opengl/xorg-x11/lib"
nanonyme: You have Gentoo which means you actually have a choice there.
_kopsu_: yeah, it's 1.5.3-
nanonyme: Well, not just that but other parts of the stack too. :)
nanonyme: That's just the X server version.
_kopsu_: yeah, it's while when i have upgraded parts of it. just focused lately to xf86-video-ati x11-drm and libdrm
nanonyme: Oh, hmm. Actually seems X server 1.6 isn't in any major realeases. Never mind.
_kopsu_: ok
nanonyme: That doesn't mean you couldn't update to it though. :)
_kopsu_: yeah
nanonyme: It's apparently an AGP card? Don't have much experience with those myself, just heard they might be problematic.
_kopsu_: nope, 4850 with pci-e
_kopsu_: and with proprietary drivers 3d works (tried with sabayon)
nanonyme: Oh.
nanonyme: Yeah, I didn't notice before other cards talk of MC_AGP_LOCATION too... *sigh*
nanonyme: _kopsu_: You probably have tried restarting the X server, right?
_kopsu_: yeah
nanonyme: I dunno then. Afaik it should be at least making an attempt to load r600_dri.so, not just going straight for swrast_dri.so.
_kopsu_: should /usr/lib64/dri/r600_dri.so be mentioned in some env variable?
_kopsu_: or path to that file
nanonyme: No, the display driver should know the name and the path is hardcoded.
_kopsu_: ok
_kopsu_: and it's apparently there and latest
_kopsu_: i'll try to compile display driver again. xf86-video-ati
nanonyme: You could pastebin your xorg.conf too.
legume: nanonyme: you can tell an agp card (as long as Option BusType PCIE isn't used) by grepping lowercase agp. It will look like http://www.pastebin.ca/1543140
_kopsu_: http://nopaste.com/p/aAPVXiA1N
nanonyme: _kopsu_: I meant conf, not log.
_kopsu_: aa.. sorry, my mistake ;)
nanonyme: legume: Right.
_kopsu_: http://nopaste.com/p/ahN8MozsN
nanonyme: _kopsu_: Try commenting everything except identifier and driver in device section?
_kopsu_: yea
nanonyme: IgnoreABI doesn't sound like a very healthy option. :P
legume: _kopsu_: and connent AIGLX false
_kopsu_: i was thinking that too when i looked that a moment ago
_kopsu_: ok
_kopsu_: i'm going to boot this thing up... changed those options and compiled display driver again...
_kopsu_: see you later :)
_kopsu_: and thanks.,.
suokko: /* FIXME: what are these numbers? */
tsamolotoff: Greetings to all ) Hi, nanonyme!
tsamolotoff: A question about VBO and other stuff - does it work without KMS?
nanonyme: Hey.
nanonyme: I'm not the right person to ask there. ;)
suokko: tsamolotoff: yes it works
_kopsu_: yeah, it works now : (II) AIGLX: Loaded and initialized /usr/lib64/dri/r600_dri.so
nanonyme: suokko: Hilarious. It really says that in the code? :3
suokko: I could copy that to many others places too ;)
nanonyme: Like microcode? ;)
suokko: nanonyme: You don't even have to look micro code to get more than 100 place where there is magic numbers that are making understanding code harder
tsamolotoff: suokko: Thanks) Maybe you can also enlighten me on texture tiling... - is it the real way to make s3tc working?
suokko: texture tiling is different. It changes the order of pixels so that gpu can render with less cache misses
suokko: For s3tc you need to google for illegal patent work around library.
suokko: illegal in way that you would need license from via to use it
nanonyme: Wonder how much the license is.
suokko: Een tough you have payed for that license with the graphics card :/ But because of legal complexity it is impossible to extend for mesa
nanonyme: Has it ever been tried in court though?
suokko: I would guess none has time or money to test patents in court
suokko: That why patents re so bad for small companies and open source.
tsamolotoff: suokko: You mean libtxc_dxtn ? It brings serious graphic artefacts into UT2004...
suokko: Current patent system is just way for large companies to protect their monopolies
suokko: tsamolotoff: That is because none has put enough work for compression so it has quality problems
suokko: It is hard job to implement s3tc with high quality output
tsamolotoff: and I've seen mesa patches related to s3tc that are related to texture compression (on bugs.freedesktop.org)
nanonyme: suokko: Btw, is it a hardware or a software patent?
suokko: tsamolotoff: MEsa is allowed to enable hw s3tc support but many programs don't have precompressed textures so they need to do compression in runtime
suokko: nanonyme: technology.
suokko: So you can't implement the compression algorithm without license
nanonyme: suokko: There's no technology patents. :) If it's software, it's not valid in Europe.
nanonyme: So you can use it legally.
tsamolotoff: wonders why somebody doesn't patent patenting in the US
suokko: tsamolotoff: prior art
nanonyme: I wonder if you could manage to patent the mechanism of breathing.
tsamolotoff: suokko: So, it's completely impossible to play UT2kX on FOSS drivers?
suokko: nanonyme: If you have innovative method to do breathing ;)
nanonyme: You could sue people for royalties on every born child.
tsamolotoff: or use Google Earth and the others)
suokko: tsamolotoff: You can use them without texture compression
suokko: texture compression is not magic for better performance
MrCooper: airlied: btw, we should probably hide the innards of struct radeon_bo et al from libdrm_radeon users and add setter/getter API?
nanonyme: It's magic for better vram utilization though, right?
tsamolotoff: suokko: It doesn't work without it (at least UT and Q4)
suokko: You could even hack it so that all textures for them is downscaled to 4th in size to save bandwidth and vram
suokko: Idea would be instead of compression s3tc functions would just scale height and width to half leaving you with 4th in memory usage.
suokko: Another option is to improve s3tc compression so it doesn't cause the quality problems
tsamolotoff: Huh, maybe the last question - any performance improvements in KMS/DRI2?
suokko: tsamolotoff: some for r200, very little for r300
tsamolotoff: suokko: A pity... I can't use it on my rv530, the dropage is too heavy
suokko: 2D or 3D?
tsamolotoff: suokko: What do you mean by 2D? As for 3D, it's nearly impossible to play ioquake3, openarena, nexuiz (on low graphics)
suokko: I was thinking something like 2D window operations would be problem for you
tsamolotoff: suokko: And if any 3D window is created, there's a short lock-up
tsamolotoff: suokko: No, KWin without compositing is quite normal, however if compositing is enabled, there's the same lock-ups, not descent performance
suokko: Is there any difference in ogl or xrender composite?
[Enrico]: suokko: a great difference
[Enrico]: suokko: opengl is the fastest
suokko: but still too slow I guess
tsamolotoff: suokko: I wonder what r6xx+ users experience... If ol'-good r500 is so sluggish
[Enrico]: suokko: here it is fast enought to run composite on kde 4.2 on a r200 card
[Enrico]: suokko: so it is fast
tsamolotoff: [Enrico]: With KMS and DRI2?
suokko: r200? :) how long has ti worked with r200? Last I tested in this week it was horrible slow
[Enrico]: tsamolotoff: no, with the standard DDX driver for now
suokko: But I had over a week a old mesa loaded to AIGLX ...
[Enrico]: suokko: well the standard DDX driver works very well. i can even play nexuiz!
suokko: [Enrico]: ddx doesn't provide 3D it is mesa that provides all opengl and 3D
[Enrico]: suokko: with DDX i mean no kms and mm and standard mesa 7.4
suokko: But r200 in current mesa master beats r500 cards ;)
suokko: and mesa 7.5 is even faster for 200 than mesa 7.6
suokko: I haven't benchmarked mesa 7.4 but it should be pretty similar to 7.5
tsamolotoff: suokko: I'm running mesa git, and VBO's doesn't work in nexuiz... only semi-transparent contour of both player or his gun
suokko: tsamolotoff: That is bug in nexuiz and mesa doesn't have workaround it
tsamolotoff: suokko: maybe you can advice some other app to check it?
tsamolotoff: e.g. maybe wine does support it?
rnoland: performance has dropped off again... or rather, cpu usage has increased more likely.
rnoland: i've lost like 200fps with current master
suokko: tsamolotoff: sauerbraten would be my guess
suokko: rnoland: There is huge memory leak too
suokko: 3M/s in gears
tsamolotoff: suokko: Thanks, when I return to Moscow from my near-Siberia town, I'll check it)_
tsamolotoff: bb
rnoland: hrm, the 2f fix didn't fix vdrift....
suokko: marvin24: You found a hard bug to fix :/ It looks like quite a lot in swtcl has to be changed.
marvin24: suokko: is this good or bad ?
suokko: good tht you found it. Bad news is that it takes a lot time to fix
suokko: marvin24: Can you help me to get a bit more data what is going on? I would need RADEON_DEBUG=all log with http://nopaste.com/p/ag8fsmVS1 patch applied.
nanonyme: rnoland: Only 200fps? I've gone from 1800 to 1000 during the past week or so... :p (if you mean gears)
[Enrico]: well with debug enabled i think it is normal to have slow performance
nanonyme: [Enrico]: I'd rather suspect the memory leak.
[Enrico]: surely possible :D
nanonyme: To me it sounds a bit odd that it was noticed only a little while ago though. Maybe someone smarter than me should try to design a memory leak detection utility in Mesa? :3
Lutz_Ifer: "radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed."
nanonyme: Lutz_Ifer: Running what?
Lutz_Ifer: "teeworlds"; still producing glitches etc.
Lutz_Ifer: looks like that: http://img1.abload.de/img/bildschirmfoto-2f5cu.png
kdekorte: Running todays mesa, I'm getting some "drmRadeonCmdBuffer: -22" errors from apps that I was not getting before. ie neverputt after the first hole
nanonyme: Are you sure you have the right DRM?
kdekorte: pretty sure since apps like glxgears work
nanonyme: Yeah, I get it after the second.
kdekorte: Ah, so I am not dreaming it...
nanonyme: Nope.
legume: when you get an error like drmRadeonCmdBuffer: -22, there are usually more messages in dmesg aswell.
nanonyme: Ah.
nanonyme: [drm:r600_nomm_relocate] *ERROR* bad offset! 0x2
nanonyme: [drm:r600_cs_packet3] *ERROR* bad SURFACE_SYNC
nanonyme: Sounds familiar.
nanonyme: I actually iirc looked up the first and it means that the offset doesn't point to framebuffer or GART.
nanonyme: Didn't the second one.
nanonyme: (mostly because there's no parameter info anyway)
nanonyme: The SURFACE_SYNC originates in r700_render.c function r700SyncSurf.
nanonyme: Well, there's a comment '???' at the end of one line in the batch...
marvin24: returns from the lab
marvin24: suokko: the log is a little bit large
nanonyme: Perhaps can assume the author wasn't entirely sure how that works either.
suokko: marvin24: Can you gzip it and upload somewhere?
marvin24: suokko: I put a compressed version to: http://www.uni-giessen.de/~gd1369/kcalc_debug.gz
suokko: thanks
marvin24: suokko: in fact, kcalc does not crash immediately, but after some cursor movement over the window
marvin24: suokko: also the contents are garbage
suokko: I did change the flush happen a bit later thn before but I didn't fix it
marvin24: yeah, it just moved the crash to some point later in time
nanonyme: Eh, I think I now understand the '???'. :P The documentation doesn't say that it's needed...
nanonyme: Not least not that I can see.
marvin24: suokko: also it crashes later in qt now: http://pastebin.com/m5fdc3c48
agd5f: nanonyme: *ERROR* bad SURFACE_SYNC is a symptom of another bug. running out of reloc space
nanonyme: Right.
suokko: agd5f: Running out of reloc space? How?
nanonyme: agd5f: Are those two errors unrelated to each other, btw?
agd5f: the reloc array in r600_cmdbuf.c is static
suokko: Aha. libdrm has dynamic one
agd5f: it needs to be dyamically resized
agd5f: just haven't gotten to that yet
nanonyme: agd5f: So... What is the '// ???' actually doing on the line then? ;)
agd5f: nanonyme: what // ???
agd5f: oh, in r700_render?
nanonyme: r700_render.c function r700SyncSurf, line 146.
nanonyme: Yeah.
suokko: nanonyme: // <- comment start
nanonyme: suokko: I know. ??? is just an interesting comment.
suokko: :)
agd5f: I just put that there since I wasn't sure I liked passing the read/write domains into r700SyncSurf like that, but in retrospect, it's fine
nanonyme: Right.
suokko: AndrewR: Are you reporting the screen corruption problem? :) If yes can you add dmesg to there too
suokko: And one another helpful log would be if you load radeon with test parameter set to 1
nanonyme: agd5f: Right, I'll ignore it from now on then. Comments like that just catch attention pretty well when searching for a problem leads close to the line. :)
nanonyme: suokko: What kind of a data structure do they use in libdrm for it, btw?
suokko: For what?
suokko: aaa- relocations
nanonyme: Yeah.
agd5f: suokko: realloc
nanonyme: Ew. :(
suokko: It is just simple array that is extended with realloc
AndrewR: suokko, ok, will reboot this machine first
suokko: hates swtcl
nanonyme: Hmm.
nanonyme: MALLOC_CHECK_ sounds neat.
glisse: valgrind is the easiest tool to find memory leak
nanonyme: glisse: Except suokko said doesn't work with Mesa.
suokko: glisse: except when bo manager releases all leaked bos in end
glisse: it did last time
agd5f: the r600 memory leak is fixed
suokko: But I agree that valgrind is the best tool to find memory leaks
nanonyme: But yeah, apparently it's possible to have the software immediately abort on heap corruption and print to stderr using MALLOC_CHECK_.
legume: agd5f: Thanks, just tested and is OK.
nanonyme: Wow.
nanonyme: And agd5f saves the day again with a oneliner. ;)
legume: agd5f: I notice that while engine + b now works, I still don't see the framerate text, though if i press "i" to toggle it off the actual framerate as printed on stdout almose doubles.
agd5f: legume: the text may be hitting some sw path
nanonyme: agd5f: Would imply the software path is buggy?
agd5f: nanonyme: hard to say
agd5f: nanonyme: not likely since swrast works
legume: agd5f: OK, It's not a regression - I've never seen it with h/w and only recently found it should be there using swrast.
kdekorte: legume, up until today (when the block was fixed) you could see the upper or lower half of the text
kdekorte: I think it is texture related personally.. since quake3 has problems with the menus
nanonyme: legume: Sheesh, you're right. It's at best a matter of several dozen fps. ^^
kdekorte: Was the latest patch supposed to fix the -22 error? If so, it is still not fixed
nanonyme: Nope.
legume: kdekorte: Hmm, I can'r recall ever seeing it, but then I don't always run engine after every change.
nanonyme: 18:12 < agd5f> the reloc array in r600_cmdbuf.c is static
nanonyme: 18:12 < agd5f> it needs to be dyamically resized
kdekorte: nanonyme, yes I recall that...
kdekorte: but since the git commit fixed a memory leak, I thought it might affect it
suokko: agd5f: One option to fix the relocation problem is to have limiti in begin of rendering so you always have at leas t X free lots for relocs in begin of rendering
kdekorte: if you run gamma today all the squares are placed right, except they are too high in the window and a little to left
legume: Is going to test if openarena regresses because of mem leak or dadf138ddbaecd7fff239df7961aac25e74f14f6
nanonyme: Heh, OpenArena actually seems to be pretty verbose in what it's doing to setup graphics.
agd5f: i think is likely vertex related still
agd5f: like missing indices or something like that
marvin24: suokko: just another side note: during the last crash, kernel throughs out [drm:r300_cs_track_check] *ERROR* [drm] No buffer for z buffer ! and [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
nanonyme: http://pastebin.ca/1543422 namely this much
nanonyme: What's a compiled vertex array? :)
agd5f: suokko: I'll probably just do what the kernel does
legume: agd5f: adf138ddbaecd7fff239df7961aac25e74f14f6 causes direct openarena to soft lockup at the start of a timedemo (no errors I can find)
legume: agd5f: dadf138ddbaecd7fff239df7961aac25e74f14f6 even
agd5f: legume: ok
suokko: marvin24: sounds bad. I guess I have to forward this problem to someone who knows more about r300 or swtcl :/
marvin24: suokko: ok - thanks for your efforts!
nanonyme: Yay, finally at least some remotely vertices-related demo that doesn't work. :p
nanonyme: progs/trivial/quad-clip-all-vertices renders wrong on r600. ^^
nanonyme: progs/tests/zdrawpix isn't even remotely like what it should be. :(
nanonyme: Same as zcomp.
nanonyme: And zreaddraw.
nanonyme: stencil_twoside also renders wrong and stencilwrap outputs Failed GL_DECR_WRAP test on iteration #264 (got 68, expected 247) and the 263 failures before that. :/
nanonyme: So yeah, maybe it's kinda expected games might render a bit wrong. ^^
agd5f: nanonyme: anything that reads the z/stencil buffer won't work since those buffers are tiled
bridgman: with the latest mesa code (as of say 30 minutes ago) I'm seeing openarena hang just before drawing the playing area, last message something like "obtaining snapshot"
bridgman: is anyone else seeing that ? rv620
bridgman: I'll pull agd5f's latest change and try again
bridgman_: nope, still hangs... last message is "awaiting snapshot"
bridgman_: I was mucking around with screen shots last thing yesterday, don't suppose there's a connection ?
agd5f: bridgman_: direct or indirect?
bridgman_: hmm, looks like hanging at "awaiting snapshot" is a known problem apparently unrelated to drivers...
bridgman_: indirect
agd5f: ah
bridgman_: direct is still pretty corrupted
bridgman_: demos etc all work, compiz works, so not sure what to think here
nanonyme: still thinks indirect is the source of all evil :3
bridgman_: some evil, not all; the dilemma is when you have to choose between evils
bridgman_: ppracer works pretty nice indirect
nanonyme: bridgman_: Well, the only bad thing about indirect imo is that it goes through the X server. ;)
kdekorte: etracer in indirect mode crashes X.... grrrr
bridgman_: yeah, etracer and ppracer seem to behave a bit differently
kdekorte: etracer in direct mode still crashes with etracer: radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed.
suokko: kdekorte: Do you know which GL call causes that assertion?
suokko: (from backtrace)
agd5f: suokko: I think it's a byproduct of a realloc failure
kdekorte: let me see if I can get it
suokko: agd5f: ok
nanonyme: realloc failure shouldn't be that bad, should it?
nanonyme: That is, the original pointer is still valid.
suokko: kdekorte: http://nopaste.org/
agd5f: last time I traced that problem it was somewhere in glibc
kdekorte: suokko, pm'd you a backtrace
nanonyme: Ah, right...
suokko: kdekorte: I saw that :/
kdekorte: http://nopaste.org/p/amPetmOsk
suokko: It is easier to read from browser
kdekorte: anything you want me to print out why I am in gdb?
suokko: That doesn't look like radeon_lock.c :/
kdekorte: I went up 1
kdekorte: #1 0x00007ffff20c92db in radeon_cs_check_space_internal (cs=0xeae850,
kdekorte: tmp_bo=0x7fffffffdc20) at radeon_cs_space_drm.c:189
kdekorte: 189 (*cs->space_flush_fn)(cs->space_flush_data);
kdekorte: sorry for the spamming... but here is *cs
kdekorte: print *cs
kdekorte: $1 = {csm = 0xc5e100, relocs = 0x5adb150, packets = 0xeaebc0, crelocs = 17,
kdekorte: relocs_total_size = 28049408, cdw = 2701, ndw = 16384, section = 0,
kdekorte: section_ndw = 7, section_cdw = 7,
kdekorte: section_file = 0x7ffff225a416 "r700_render.c",
kdekorte: section_func = 0x7ffff225a5c2 "r700SyncSurf", section_line = 137, bos = {{
kdekorte: bo = 0xaf9a00, read_domains = 0, write_domain = 4, new_accounted = 4}, {
kdekorte: bo = 0xaf9a90, read_domains = 0, write_domain = 4, new_accounted = 4}, {
kdekorte: bo = 0x21e3c20, read_domains = 6, write_domain = 0,
kdekorte: new_accounted = 393216}, {bo = 0x0, read_domains = 0, write_domain = 0,
kdekorte: new_accounted = 0}
kdekorte: space_flush_fn = 0, space_flush_data = 0x0}
suokko: crelocs looks very low number for overflowing reloc space
agd5f: suokko: I just fixed that
suokko: ok :)
suokko: So it is calling null pointer
kdekorte: agd5f, I'm running mesa git master head...
Zajec3: bridgman_: did you read my docs question from archive?
Zajec3: HDMI/audio docs for Christian
bridgman_: Zajec3; already on the list
kdekorte: agd5f, is it possible that realloc is not clearing the data and that is why drawable != 0 is failing?
bridgman_: the question is what we should stop doing in order to have time for the audio docs ;)
bridgman_: I would like to see 3D get a bit further before we shift focus
Zajec3: bridgman_: ok, great, thanks :) just wanted to know if you noticed that
bridgman_: I see all ;)
Zajec3: easy to miss sth in so traffic last days ;)
Zajec3: hehe :P
suokko: agd5f: Seems like r600 is missing call to radeon_cs_space_set_flush
agd5f: suokko: could be
kdekorte: suokko, where should that call go?
kdekorte: I would be willing to try it here
suokko: agd5f: Maybe r600InitCmdBuf should jsut call rcommonInitCmdBuf
suokko: kdekorte: r600InitCmdBuf and example is in raceon_common.c how to call it
agd5f: that won't work. r600 has differnet cs funcs
suokko: ok
nanonyme: At least not without bloody icky macro hacks? :)
agd5f: just need to pull that function call into r600initcmdbuf
suokko: nanonyme: another option is to make cs functions match ;)
agd5f: suokko: not really possible. r600 and other chips use differnet ioctls
suokko: Will that change in KMS so that ioctls are shared?
agd5f: suokko: yeah, kms is the same for both
suokko: good
kdekorte: ok, that fixed the crash
agd5f: cool
suokko: One bug down X to go ;)
kdekorte: now lots of texture/geometry errors
kdekorte: I would reaaalllllly like to see the texture issue looked at in quake3 with the fonts on the menus...
kdekorte: agd5f, did you commit it? I pulled and it is not there
agd5f: kdekorte: I had to rebase. some more commits since I last pulled
nanonyme: suokko: As long as amount of bugs fixed vs amount of new bugs introduced by fixes yields a decreasing amount of bugs, can probably rejoice... :)
agd5f: should be there now
manio_: hi guys - i remember that i found a page from one guy who is trying to figure out radeon's video acceleration features by his own...
manio_: but i can't google him now
manio_: maybe you can help? :)
kdekorte: agd5f, my -22 error is gone now with my clutter app.. so that regression is gone now. still the 1/2 texture issue
nanonyme: Hmm.
nanonyme: I seem to be stupid. Took me this far to figure out *how* etracer is corrupted.
nanonyme: It's obviously z corruption.
nanonyme: The driver sometimes draws the mountains behind the closer mountains on top of the closer mountains.
kdekorte: nanonyme, if that is true then we can delay checking it again until tiling is partially working
kdekorte: I wonder if that is the issue with my clutter app?
nanonyme: Might be in OpenArena too.
nanonyme: It just has so many walls behind each other that the end effect is just mishmash.
Luzipher: hm, does anybody else have build problems for mesa-git on x64 since at least yesterday ? Error for me is: radeon_screen.c:270: error: 'RADEON_PARAM_NUM_Z_PIPES' undeclared
kdekorte: Luzipher, working here... might try a make clean
Luzipher: tried already, but good to know that it's working for others :)
nanonyme: Luzipher: Got too old a version of libdrm_radeon?
nanonyme: It seems to be defined in radeon_bocs_wrapper.h which hints towards that direction.
kdekorte: Hum.. I don't think my clutter app is a zorder issue cause if I run it in indirect mode the actors show up whole, indirect mode I get them bisected on the diagonal with the upper right missing
Luzipher: hmm, looking in that direction, thanks nanonyme
kdekorte: should be "in direct" on "indirect" for the second one... so direct mode has the corruption, indirect does not
nanonyme: Well, including z corruption, r600 also suffers from stencil corruption.
nanonyme: This can be seen with Mesa tests.
Luzipher: yup, updating libdrm solved it, thanks
nanonyme: So it's not like there's just one issue that's causing problems in OpenGL programs.
suokko: nanonyme: Z and stencil are in same memory location
nanonyme: Ah.
suokko: 4 bytes shared so that 3 for Z and one for stencil
nanonyme: suokko: So better fix stencil first and see if it fixes Z too?
kdekorte: suokko, so then are stencils pending on tiling?
suokko: kdekorte: So Alex said ;)
nanonyme: Heh.
nanonyme: suokko: Are you saying pretty much most of the corruption might be pending on tiling? :p
kdekorte: So my next question.... (drum roll)... how much work is tiling support?
nanonyme: sets up a camp and waits
agd5f: I fixed two sided stencils
agd5f: the tiling only matter for things apps that need sw access to the depth or stencil buffer which is pretty rare
nanonyme: agd5f: Should it be possible to have the z tests not fail without it then?
W0rmDr1nk: Hi
W0rmDr1nk: I am a bit of a git noob
nanonyme: W0rmDr1nk: On with the question? ;)
W0rmDr1nk: no - i am too shy :)
agd5f: nanonyme: the Z tests likely work, but when the apps reads back the value to verify it fails due to the tiling even though what rendered is correct
W0rmDr1nk: no just kidding - if my xorg log shows this when loading radeon module : compiled for 1.5.3, module version = 6.12.99
nanonyme: agd5f: Well, actually all z tests I did with Mesa rendered wrong.
W0rmDr1nk: does that mean im on branch or trunk ?
W0rmDr1nk: or is it not difinitive ?
agd5f: nanonyme: probably just bugs in the Z setup. I doubt it's tiling in most cases
W0rmDr1nk: anyway - i think im on trunk - and i get no more crashes with dual screen or pointer corruption
W0rmDr1nk: so yeah :)
nanonyme: agd5f: Right. Just wondering if the same bugs could be affecting openarena etc too.
nanonyme: Since what I've been seeing would pretty much be explainable with z failures.
agd5f: nanonyme: should be pretty easy to debug. run app, change some Z setup, run app, change some Z setup, repeat
kdekorte: agd5f, can you recommend a place to dork with those settings
agd5f: kdekorte: pretty much all state is setup in r700_state.c
agd5f: the names of the functions correspond to state they relate to
agd5f: so the Depth function affect Z
agd5f: r700SetDepthState, etc.
agd5f: alpha test may also have bugs
nanonyme: Yeah, all stencil tests work now. :) Nice.
kdekorte: Messing with the Depth state stuff really gives some odd results... but interesting
nanonyme: kdekorte: Are you testing it with progs/tests/z*?
nanonyme: zcomp seems to be using GL_ALWAYS so might as well start there.
legume: agd5f: openarena is OK now.
nanonyme: legume: In indirect?
agd5f: legume: in what sense?
Zajec3: legume: you shocked everybody ;)
legume: agd5f: i mean it doesn't hang - still corrupt.
nanonyme: Oh, right. Yeah, that improvement came for me too.
nanonyme: Wonder if we'd temporarily have r700SetDepthState print out all the interesting data. :)
bridgman_: openarena is also working for me again
bridgman_: ie it's not hanging at the "awaiting snapshot" message
nanonyme: is being puzzled
nanonyme: I'm probably doing something wrong here. Expecting Depth.Func values 0 to 7, getting 201.
legume: it was 490f640cd58d215281076ae6e0e70649db6b0ed5 that fixed it.
legume: Wonders how to get libc stderr to redirect or log
nanonyme: legume: 2> log.txt
nanonyme: Oh, read wrong.
nanonyme: Sorry.
nanonyme: gets back to trying to figure this out
kdekorte: nanonyme, for etracer I see it just using GL_LESS, GL_LEQUAL and GL_ALWAYS
nanonyme: Or claims to be.
kdekorte: I fliped some of the SETFields around and made even a bigger mess
marvin24_: is there still the memleak? just asking because 2 min of openarea (INDIRECT)= 1.2GB of Xorg mem
nanonyme: I'm yet to gain evidence that it doesn't just fallback to default every time.
kdekorte: so thinking that DepthState might be ok
Zajec3: maybe openarena doesny crash... but still corrupted
kdekorte: I put a printf in the default state and it never shows up
kdekorte: I put printfs in each case block to find out what was being used
papo: hello
nanonyme: Yups, you're right.
nanonyme: I'd still rather get the actual numeric value out of this though.
_Groo_: hi/2 all
_Groo_: ppl with latest mesa (master), opengl stopped working with a very nice kms drm message
nanonyme: marvin24_: Should be fixed.
marvin24_: maybe need to restart X ...
_Groo_: [ 142.936043] Forbidden register 0x4EA0 in cs at 200
_Groo_: [ 142.936055] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
_Groo_: [ 143.539727] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
_Groo_: [ 143.549718] [drm] LVDS-7: set mode 1280x800 11
_Groo_: [ 234.737252] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
_Groo_: i pasted here cause its very small
papo: I'm currently using the fglrx driver on a r600 but I want to switch asap. Last time I asked and checked (6 months ago or something), the open source driver was reliable, but some power management features were missing and AMD was about to release some specs on that. I'd like to know whether any progress has been made on that issue and if I can help you out with something
_Groo_: please help, no kwin3d, compiz goodness, no opengl, nothing :P
nanonyme: kdekorte: The values should be fine, they seem to be exactly what the registry manual says.
kdekorte: nanonyme, expect they are
_Groo_: i can revert with yesterday head and it works, yesterday and today git commits break opengl
kdekorte: I tried always setting write enable and the screen looks a little better, but still has issues
suokko: _Groo_: CAn you do bisect?
nanonyme: kdekorte: Try to get the z tests to work first?
nanonyme: Games only after they work.
taiu1: suokko: _Groo_ pretty sure it's 18e0fea55bbc41ce81397f22aa2c91e4feefee55
_Groo_: suokko: unfortunatelly no :( i dont have the time or the knowledge, i can tell where to start looking (code that starts working in git) and i can git revert and test patches, but i dont have the machne or the time to go one by one
nanonyme: There's three tests in progs/tests/ about z.
_Groo_: taiu1: gonna revert it, just a sec
suokko: _Groo_: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
kdekorte: nanonyme, wanna see something funny.. in Depthstate make it so that Z_WRITE_ENABLE_bit is never set and then play etracer.. the penguin looks back at you
suokko: That is the fast way to check what broke it
_Groo_: suokko: its not lazyness, i dont have the time, each test and compile takes some time..
suokko: _Groo_: And fixing bug takes a lot more if you don't have time to find the broken commit :/
_Groo_: suokko: like i said, pointed patches and reverts i can fix.. like the one taiu1 told here, im compiling now, but dont have the time to do much more then patch testing and bug reporting
suokko: _Groo_: git bisect in this case would be avout 5 recompiles and tests
_Groo_: suokko: i know... bug reporting is the first step, git bisect would be the second, unfortunatelly my time is limited per day to test mesa/drm/ddx/kernel
suokko: and with cc cache recompile should be fast ;)
_Groo_: suokko: for you that knows where to look, i would have to go commit by commit, since 2 days ago.. which are a LOT of commits
nanonyme: suokko: Recompile is even faster once one notices one doesn't have to recompile all directories for most changes. :/
nanonyme: (which I did only now)
suokko: _Groo_: That why there is git bisect THAT does search for you
nanonyme: Oh, bisect.
nanonyme: Right.
suokko: So you don't have to test all commit
suokko: It selects the one that makes you test as little as possible
_Groo_: suokko: it searches and then he asks me.. good, bad.. since i dont know which one is which i assume all are bad, compile, test, mark good, compile, test , etc etc
suokko: _Groo_: If oyu don't know is it good or bad then you have to tell skip
suokko: agd5f: Are you sure that "r4xx and rs4xx also have lte discard regs" has kernel support for all cards?
_Groo_: suokko: btw this cars is a evil rs485
_Groo_: card
suokko: _Groo_: What kernel you have? KMS or not?
_Groo_: suokko: kms, linux git from today, today mesa, today ddx, today drm
_Groo_: suokko: xorg master from 2008
_Groo_: from 20 08 2009
agd5f: suokko: legacy drm does. I assumed kms did too, but perhaps not
kdekorte: agd5f, in the zdarpix test when show the depth buffer it looks like it being populated incorrectly...
agd5f: kdekorte: when sw reads the depth buffer it will be wrong due to tiling
taiu1: that's a bit of a problem now as mesa updates will start requiring kernel upgrades
kdekorte: yeah that is exactly what the depth buffer looks like, a set of tiles
groo_: ok with the revert glxgears works BUT if i enable compiz, x segfaults with this nice error: http://pastebin.ca/1543655
groo_: this wasnt happening 2 days ago before someone asks, everything was working just fine
nha: maan, those shader compiler bugs can be subtle...
nha: particularly when one has to chase them in a nested fashion
nha: I was hunting down a problem in Sauerbraten, and on the way I noticed a (probably) entirely different bug
groo_: suokko: can you take a look at the error?
suokko: groo_: http://nopaste.com/p/aQRGbToZq
suokko: That might fix the compiz problem
suokko: But I haven't ha time to check if it really works
groo_: suokko: ok let me check
kdekorte: zdrawpix is definately hitting some slow path in the r6xx driver as software runs a lot faster and uses much less CPU
osiris_: yay! nha is back :)
osiris_: nha: what's up?
nanonyme: Hmm.
nanonyme: Seems the things in z tests *might* be irrelated after all. :/ They don't start working with LIBGL_ALWAYS_INDIRECT whereas games with possible z problems do...
kdekorte: nanonyme, yeah I was noticing that eariler
groo_: suokko: doesnt compile http://pastebin.ca/1543671
nanonyme: Btw, Compiz fonts are now fixed.
nanonyme: Oh, wait a minutes...
kdekorte: nanonyme, for the most part, I still get black squares
nanonyme: This pulled me half a Compiz?
nanonyme: I deeply protest. :)
groo_: suokko: interestingly kwin3d works but still with the slow scroll it started suffering some weeks ago
nanonyme: Yeah, the problems are still there.
suokko: groo_: You need to change there rmesa->swtcl to rmesa->radeon.swtcl
suokko: My computer is a bit slow because I'm installing updates
nanonyme: kdekorte: It apparently half-initialized as in it broke UI but didn't still go on. :P
nha: osiris_: indeed, back in warmer regions now; Iceland was a lot of fun, crossing rivers in a jeep and all that :)
nha: osiris_: before I left, I promised to myself that I would track down a particular visual corruption in Sauerbraten, and that's what I'm doing now
groo_: suokko: done, continuing compiling
MostAwesomeDude: nha: WB
nha: the bug is *very* odd, but it does seem to be related only to vertex program compiling
nha: in particular, a MAD with a relative addressing operand is giving weird results, while when I move the loading into a MOV, everything works fine
nha: but the bug isn't really consistent, so, rather odd
osiris_: nha: it's always nice to have some free time away from the computers :)
kdekorte: nha, Alex fixed a bug related to vetex shaders the other day
nha: in the process, I found an NQSSADCE bug for which I've just written a Piglit test case
nha: kdekorte: on r600, I presume; I'm talking about the r300 driver right now
kdekorte: I think he decided that if the shader was expecting one format and the vertex's were in another the shader needed to be compiled
osiris_: suokko: I get "Rendering was 24 commands larger than predicted size. We might overflow command buffer" warning with sauerbraten
kdekorte: so he just ended up recompiling everytime I think
nha: osiris_: yup.. two internet-less weeks, yay :)
nha: kdekorte: I think I saw the commit, but again, that was about r600+, while I'm talking about r500-
kdekorte: right... they just sounded similar
nha: ty anyway :)
suokko: osiris_: Maybe index buffers are missing from prediction?
suokko: or some vbo stuff?
dileX: wb nha
osiris_: nha: anyway, as you may have already noticed, I have pushed OQ and VBOs recently
osiris_: I'm trying now to make some newer games work
osiris_: (on wine mostly)
mcgreg: osiris_, lookig forwrdm to see wow working :)
mcgreg: *foward
mcgreg: +r
_Groo_: suokko: ok, you patch fixed the issue
suokko: What about performance?
suokko: Did I kill it? (I did it for r200)
osiris_: mcgreg: can't really test it, I don't have an account
nha: osiris_: I saw, very, very cool!
_Groo_: suokko: performance without tests is very subjective but it feels the same
nha: osiris_: what are you working on now?
mcgreg: osiris_, actually, you can create as many accoutn as you wish , for free - with limitations thats shouls care to you at all
mcgreg: *shouldnt
suokko: _Groo_: good. For me it halfes the speed so you would notice it
nanonyme: There's also illegal free servers you can try it on.
nanonyme: (Blizzard isn't too happy about them)
mcgreg: nom, you dont need any illegal stuff, really. a "demo" account - 10 days only, you can almost do anything
mcgreg: the game's works totally normal in that time - with a few limitations
nanonyme: mcgreg: Yeah.. The funny bit of it is that people download those demo editions, then go play on free servers. ;)
nanonyme: End result: full WoW.
_Groo_: suokko: no, definitely normal.. slow.. but was always slow lol, not slower then without kms thats for sure
mcgreg: nanonyme, it isn't a demo edition. the downlpoaded version IS the full verison. just the accountis limited
_Groo_: nanonyme: full WoW with kms??? where where? does it work with rs485 (aka lich king one)
nanonyme: mcgreg: That's exactly what I meant.
nanonyme: That's why it works and Blizzard isn't too happy about it.
mcgreg: oh wel.. seriously, arent they kaming enough money with wow? ...
mcgreg: *making
nha: How do these free servers work? Did people reverse engineer the network protocol and re-implement their own server, or what?
nha: that seems like a shitload of work
nanonyme: Then again, free servers are dead boring anyway. Too high xp rate, too high gold rate, non-interesting other players.
osiris_: nha: trying to narrow down and fix rendering errors (looks like Z buffer problems) in Tomb Raider Legend
MostAwesomeDude: nha: Some people really hate Blizzard; see bnetd for another example.
nanonyme: It's not really that fun when you get your epic flying mount during the first day of playing.
osiris_: nha: but I should probably implement hardware accelerated glCopyTex(Sub)Image, as it seems to be the bottleneck in most of the games
mcgreg: nanonyme, lol
nanonyme: mcgreg: Not exaggerating. :P
_Groo_: ah you are talking about private servers.. i play in one of the best
mcgreg: laaame. I don have one even thouigh I am playing a long time now
nha: I see
nanonyme: mcgreg: Private servers are mostly useful for determining whether the game works or not. You run out of things to achieve too fast on them.
nha: osiris_: cool stuff; I'll have my hands full with stuff that is pretty much entirely confined to the compiler; been thinking about GLSL and related fun stuff :)
_Groo_: nanonyme: i play i private blizzlike with only a little better xp rating... twice as fun, same playability
_Groo_: mcgreg: not true if you play in a blizzlike realm..
mcgreg: _Groo_, sry.. what is not true?
_Groo_: mcgreg: ops its was meant for nanonyme
osiris_: nha: great. you may want to take a look at glsl branch in my private repo.
mcgreg: _Groo_, no problem :)
nanonyme: osiris_: You're working on GLSL already? *drool*
nha: osiris_: you worked on something to transform branches into ALU-only, right?
_Groo_: btw is wow working with kms/dri2? I cant make it to work.. i believe is the lack of texture compression
_Groo_: not even googlearth runs without crashing
nha: osiris_: that's very useful, we'll need it for R300; my plan is to work on real flow control for R500 fragment programs first, then flow control for vertex programs (both R300 and R500)
nha: then I guess your work already covers pretty much everything we can do for R300 fps
osiris_: nha: IIRC I've implemented branching for r300 on FPs
osiris_: nanonyme: I used to
nha: osiris_: yeah, the fc_stage.c, we'll be able to use that :)
nanonyme: Uh, oh. Something seems to be trying to use interrupts on r600. :o do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
nha: I think we'll be able to claim GLSL support for all r300-r500
nanonyme: (the fact that IRQ's don't work wasn't the surprising part, it was that something tried to use them)
nha: after all, even R300 already has VS flow control
nha: R300 doesn't have FP flow control, but we can use your code to fake branches, and unroll constant-iteration loops
MostAwesomeDude: nha: That was da plan, yes.
osiris_: nha: IIRC r300 VS doesn't support flow control or branching
nha: osiris_: according to the docs it does
nha: nobody ever reverse engineered it, but according to the documentation, basic flow control is possible
nha: the way VP flow control works is completely crazy, as if the designers were totally on drugs, but ostensibly it's there
nanonyme: nha: Maybe it was just that they had no idea how to do it and it was the first try? :P
nha: I refuse to believe that
nha: this kind of design can only be created on purpose
nanonyme: Never underestimate the power of human stupidity. :3
MostAwesomeDude: Or the power of shrooms.
MostAwesomeDude: Mmm, shrooms.
nanonyme: MostAwesomeDude: Gotten back to Gallium already, btw?
ajax: tsk tsk
MostAwesomeDude: nanonyme: Nope, I want to be able to demo shatter in a month.
nanonyme: Aww. :(
MostAwesomeDude: And for that, I'd kind of like, y'know, working code.
nanonyme: has no idea when GSoC ends
MostAwesomeDude: dberkholz gave me a big box of cards; now I can test xgi + shatter. Yay?
nha: well, my best guess is that they wanted to introduce flow control in a way that is mostly compatible with R200, or something
nanonyme: That's why the stupid question.
ajax: oh god, xgi?
MostAwesomeDude: nanonyme: Oh, it's ended, technically. But my work is never done here.
ajax: you poor soul.
nanonyme: Awww.
MostAwesomeDude: ajax: He gave me an xgi, an mga, an r200, an r300, and a few nv cards. nv10 and nv20, I think?
nanonyme: Btw, is there already a radeon open driver that can run gnome-shell? :p
ajax: i bet r300 can, but i've not tried.
nha: "But my work is never done here." <-- that's kind of our motto
ajax: r500 is currently exploding all over my face when i try to launch mutter
MostAwesomeDude: gnome-shell? Wazzat?
nanonyme: r600 pretty much choked and died in my arms when I tried.
ajax: can i just mention, by the way, that i completely hate all of you for calling exit() from within the DRI driver
nanonyme: MostAwesomeDude: I think it's supposed to be the next-generation Gnome user interface.
nha: ajax: oops. :(
nanonyme: ajax: Had fun with threading?
ajax: this in particular is awesome:
nha: ajax: we were young, on drugs, and needed the money, or something
ajax: if (ret) {
ajax: fprintf(stderr, "drmRadeonCmdBuffer: %d\n", ret);
ajax: _mesa_exit(ret);
ajax: }
ajax: return ret;
ajax: like, why did you even bother making that return a value.
nanonyme: X)
MostAwesomeDude: ajax: What should we do instead? Is there a graceful way to say, "Sorry, kid, but your kernel and I, we just can't talk to each other these days?"
mcgreg: haha niiice :)
nha: is there an INTERNAL_ERROR error state in OpenGL?
ajax: throwing the error back up until the X server can BadAlloc the client would be nice, at least.
ajax: it'll still be client-fatal but at least the server would survive
nha: ajax: how would you propose to do that? Is there something like internal errors?
spstarr: mai triangles r broken error ;p
ajax: not really. you pretty much have to just be diligent about actually writing an error path.
nha: this kind of error is usually due to a driver bug (and of course, the fact that we don't handle it gracefully is yet another bug, but setting an error like out of memory doesn't usually make sense in those situation...)
nha: ajax: but how will the X server (who is apparently the caller in your situation) notice the error? Via glGetError()? Via something else?
nha: if via glGetError(), what should the error code be?
MostAwesomeDude: For me, the only place I die on ioctl is when setting up the initial screen; I do a few ioctls to assert MM and DRI2.
ajax: X tends to throw BadAlloc when things fail for bizarro reasons, GL_OUT_OF_MEMORY would be kind of okay.
ajax: something out of band in the dri loader api might be nicer though
MostAwesomeDude: Should I just gripe to stderr and create a softpipe?
ajax: i suppose i could also do some atexit() tricks to catch driver exit() calls.
ajax: i'm already playing filthy games with symbol resolution ordering and fault handling, what's one more.
nha: what symbol resolution ordering tricks? Is this something we could avoid by improving the way linking is done in Mesa?
ajax: not really
ajax: oh, right, and i'm not actually doing ordering tricks, because they don't work well enough. i was trying to play a game to catch the _exit() call in ld.so when symbol resolution fails, but it doesn't work because that relocation is already relaxed so it skips the ELF lookup tree.
kdekorte: The shadowtex demo is giving an interesting message now: Mesa 7.6-devel implementation error: unexpected texture format in setup_hardware_state
nanonyme: Which texture format is it? ;)
nha: wow, reading the docs (R5xx Acceleration) can be enlightening, and also scary
nha: the R300 VP design is wicked crazy
nha: writing a compiler to seriously use optimization opportunities is hard
MostAwesomeDude: nha: Yeah, no kidding. There's a reason I didn't add flow control to the driver before. :3
nha: I finally understand the PVS_MACRO business
nha: the VP is incapable of handling three unique temporary register sources, *but* one could use the ATRM to work around this
nha: right now, we don't use the ATRM or the dual math pairing capability of VPs at all
MostAwesomeDude: Yeah, it's kind of complex.
MostAwesomeDude: Well, I mean, not when you know how to re-order insts. :3
kdekorte: ok, I think I found a problem in r6xx, not sure it is in drm or in mesa..
nanonyme: Shoot.
kdekorte: the gamma demo is drawing in GLUT_SINGLE mode and the first drawing is starts out of the window (basically where the window manager is drawing the border)
kdekorte: if I switch this to GLUT_DOUBLE and replace the glFlush with glutSwapBuffers it stays in the window bounds
kdekorte: but looks a little more correct
kdekorte: is that DRM related or mesa related?
nanonyme: So you think single-buffering is broken?
kdekorte: not broken specifically, but its 0,0 is in the wrong spot
nanonyme: Well, that would mean it's broken..
kdekorte: it is just off by the window manager decoration
kdekorte: it kinda does it in double mode too, but at least in that mode does not over draw the window decoreation
kdekorte: in single mode if I move the window around the image in the window says right, but corrupts the desktop
nanonyme: So yes, it is broken. :P
nanonyme: I can't see how it's so hard to reach that conclusion.
kdekorte: in double mode the moving around does not corrupt the desktop, but the contents of the window eventually get messed up (usually showing previous 3d drawn data)
kdekorte: Can really see it mess up if you move the window partially of screen
nanonyme: Nope.
nanonyme: Then again, I'm watching a moview using Xv, might affect it.
kdekorte: mplayer with -vo xv and gamma (from git) I can make a mess of the screen in a hurry
kdekorte: might be my kernel + drm combination however...
bridgman: nha; just a caution for the r5xx 3d guide... we had a tough time figuring out which was 3xx-5xx shader info and which was left over from r200, so there's definitely some r200 info mixed in there
bridgman: things probably aren't *quite* as wierd as the docs indicate
nha: hehe, okay
bridgman: unfortunately the only way to be sure is to write drivers ;(
nha: I guess we'll have to experiment at some point with some things
nha: for example, we're always using the MULTIPLY_ADD macro at the moment, while we could often use VE_MULTIPLY_ADD directly
nha: but I think the three temps limitation is still there, because I remember seeing fglrx using those macros
legume: kdekorte: gamma behavior seems to depend on mesa, testing over recent changes I've seen different numbers of squares out of place.
kdekorte: legume, yeah I have been using it as one of my 'does mesa work tests' and pretty much this positioning bug has been around for awhile..
kdekorte: gamma got worse and is now in decent shape except for positioning
kdekorte: the singlebuffer demo has the same problem
kdekorte: drag it around the screen and it leaves stuff all over (and I'm not running compiz)
legume: kdekorte: yea, see the same here.
nanonyme: suokko: Oh, ffs. Is there not a single easy level in xmoto? :)
suokko: nanonyme: Try tutorial ;)
suokko: Also Challenge cup and Classic begin have some easy levels
nanonyme: suokko: Well, iirc I could pass four tutorial levels, yes.
geo27: Hello ! I've installed x11 layman's overlay, so as to have latest radeon drivers on my machine, but since I did that, I have the feeling that my local copy of the overlay is never updated (I've never been prompter for an update comming from this overlay). Is that normal ?
chithead: geo27: discussing the gentoo x11 overlay is probably best done in #gentoo-desktop
geo27: chithead : oh, forgive me. I didn't know I couldn't be on the wrong channel. I'll do as you suggest !
DanaG: tried xmoto and gave up on it -- the physics are bass-ackwards.
nanonyme: suokko: No, actually two tutorials until it started going insane to me. :p
suokko: nanonyme: There is also "Easiest levels" category in web votes
nanonyme: suokko: Many of which are ridiculously hard.
nanonyme: xmoto all in all isn't apparently a very nice game to begin.
nanonyme: Hmm, lightning. Might be time to turn off the computer.
nanonyme: Night.
suokko: Nice. airlied has made partial wall hack to sauerbraten ;)
suokko: for r200
suokko: That means OQ doesn't work
airlied: suokko: does demos/arbocclude work?
airlied: suokko: and if !kms maybe I messed up turning it off
suokko: I'm using kms
airlied: ah cool, play with demos/arbocclude to see if it works
suokko: airlied: fragment count is static
airlied: static at 0?
suokko: no. Seems like text rendering is buggy
airlied: got color tilign enabled?
suokko: no
suokko: unless tiling is default
suokko: -14277082 Fragments Visible
suokko: Or maybe some uninitialized value?
airlied: wierd I set it up like radeon does
airlied: turn on DDEBUG in radeon_queryobj.c
suokko: airlied: It is every time random value but stays same for whole run time
suokko: I checked that text rendering is not buggy ;)
airlied: maybe r200 is crap at OQ
suokko: Why would r100 work then? :)
airlied: its hw regressions happen.
airlied: I'll try it later if I get a chance
airlied: hopefully we are just doing something dumb though
nha: MostAwesomeDude: btw, since I always lose my Wiki passwords, I noticed that on the Gallium support matrix page thingy you misspelled "Piglit" ;)
suokko: airlied: query result is always 0
nha: I'm a lazy bastard right now and deep in bugfixing mode, so if you happen to change it I would be most grateful
MostAwesomeDude: nha: So I did. At least I didn't do pyglet instead. :3
suokko: airlied: But still sometimes demo reports nonzero results
suokko: hmmm. aha it is in there the same value as is shown in demo
agd5f: kdekorte: stuff drawing outside of it's window is a clipping problem
kdekorte: agd5f, even when the stuff drawn outside is correct? looks to me like an x/y origin issue rather than clipping
agd5f: kdekorte: yes
suokko: airlied: queryobj[1]: 0x3290 = 00000000
suokko: either skip or that in state emit
kdekorte: agd5f, looked at radeonSetCliprects and it is called 3 times by gamma with the first two being incorrect and the last 1 being correct
kdekorte: so how can we move it
agd5f: kdekorte: don't know. mesa clipping is not something I claim to understand :)
kdekorte: ok... let me look and see if anything comes up
nha: Quoth the AMD docs (about TXWIDTH/TXHEIGHT): "When mipmapping, must be a power of 2 or padded to a power of 2 in memory"
nha: interesting
MostAwesomeDude: nha: Yeah, I really am not sure on that one.
kdekorte: agd5f, ok, I think I see the issue... when the cliprect is updated the code calls UpdatePageFlipping... but how does that work in single buffer mode?
MostAwesomeDude: nha: If you do recover your wiki password, you should fill in the r300textures page.
nha: MostAwesomeDude: we'll just have to try
suokko: airlied: Do you have the r200 guide? Just in case that register addresses would have changed
nha: osiris_: does OQ require a particular kernel version?
agd5f: kdekorte: might be a general bug. does gamma render correctly on other radeons?
MostAwesomeDude: nha: http://dri.freedesktop.org/wiki/R300Textures
agd5f: suokko: 0x3290 and 0x3294 according to the reg db
agd5f: data and addr
kdekorte: agd5f, it does not on my r500
agd5f: kdekorte: probably a general bug then
suokko: But still for some reason it doesn't write anything to requested memory location ... unless query end never gets emited :/
nha: MostAwesomeDude: aren't level base offsets always 32-byte aligned by virtue of the minimum stride? I admit that I don't recall that too well, and with tiled textures things are probably different again
kdekorte: agd5f, in fact on r500 it is much worse... as the image is always drawn from 0,0, singlebuffer is like that too
agd5f: kdekorte: using kms?
nha: hooray, updating to master causes crashes; let the funny game of guess-which-dependent-package-needs-make-clean begin
kdekorte: on the r500 yes it is kms
agd5f: front buffer rendering is busted in some older xservers with dri2
MostAwesomeDude: nha: I have *zero* idea. That page started from the Gallium code, and osiris and agd5f pointed out a bunch of stupid things.
MostAwesomeDude: All I know is that textures aren't 100% yet on either driver.
kdekorte: agd5f, Stock Fedora 11 on the r500 machine.. so probably a few out of date things
agd5f: kdekorte: yeah, I thik front buffer rendering is broken with that xserver
kdekorte: and that is the same xserver I am using on r600, but without kms obviously
agd5f: dri1 should be fine
kdekorte: agd5f, how about projtex, on r500 the image in the back is scaled correctly, on r600 original size
agd5f: kdekorte: sounds like a bug
kdekorte: actually both images are wrong, the front one is two big and not moved to the right spot
nha: MostAwesomeDude: I do have the password for the DRI wiki, so I filled in at list the info about cubemaps
airlied: suokko: I pulled them from the guide
MostAwesomeDude: nha: Woot!
suokko: Somehow my card doesn't write the query value out. I checked first 50 entries in bo and used memset to set all values to known value (0xdeadbeaf). Is there some register which could be read for that value directly?
airlied: suokko: the DATA reg should have it
kdekorte: agd5f, projtex - looks like unimplemented functionality in radeonReadBuffer
nha: [30918.778064] Forbidden register 0x4BE8 in cs at 970
nha: r300 driver
nha: I suppose OQ needs a DRM version check?
nha: or wait, maybe this is only necessary for KMS
suokko1: looks like radeontool is not safe with r200 :/
suokko1: Or is problem with kms?
osiris_: nha: for non kms the 2.6.30 is needed
nha: and for kms?
spstarr: hmmm
osiris_: the newer the better :)
osiris_: nha: what gpu do you have?
airlied: nha: the -rc7 kernel should be what you want
nha: okay, I'll just build linus/master
agd5f: suokko1: you'll probably have to add the OQ regs to radeontool
suokko2: agd5f: Problem is that It is immediate hard lock if I use radeontool
suokko_: and now I booted to wrong kernel :/
benh: agd5f: so I got that X1900 "PPC Mac" :-)
benh: agd5f: first I need to find out why offb doesn't work ! once that's done, I'll have a look at what it would take to get radeon going without ATOM on these
agd5f: benh: sounds like fun. heh
benh: agd5f: I'm biased toward KMS... because KMS can have easy access to the device-tree
benh: agd5f: I can do what the MacOS drivers do, which is to base the hard-wired settings on the "name" of the card
agd5f: benh: i'm fine with kms only :)
benh: agd5f: ie, ATI publishes a unique name for each model, which is what the macos driver matches against
benh: agd5f: also, the device-tree gives me MCLK and SCLK in addition to the RAM init sequence
agd5f: benh: should probably pull that in for the older cards as well
benh: yes
benh: we could have connector tabls etc...
benh: agd5f: it would be -very- useful in fact if you could get your hand on those tapes :-)
agd5f: oh, wow. all that in the device tree?
benh: agd5f: to extract the list of models and the connector tables
benh: no
agd5f: heh, yeah
benh: agd5f: device-tree has RefClk on all ATIs
benh: agd5f: generally MCLK/SCLK too
airlied: benh: we could just flash it with an x86 bios on bootup ;-)
benh: agd5f: and on recent ones, the memory init
benh: agd5f: but that's about it
airlied: because I'm not sure how we are going to resume on it without a lot of owkr
benh: agd5f: there's some properties with "flags" in them, maybe your guys know what they mean
benh: agd5f: everything else is hard coded in the driver
benh: airlied: well, we aren't
benh: airlied: I don't support suspend on quad g5's ... yet :-)
benh: airlied: I can probably reverse engineer the procedure using the MacOS driver inside "ndrver" like I did for rv350's tho :-)
agd5f: benh: forward me whatever properties and flags might be useful and I'll ask
benh: agd5f: I think you already did and afaik, they said the flag bits are quite model/drier dependent
agd5f: ah, ok
benh: agd5f: and sharing the source for the MacOS drivers would be hard because I'm sure it's still based on the Apple sample code :-)
benh: agd5f: which is under NDA
benh: agd5f: though I did have access to it too in a former life :-)
benh: also wrote MacOS gfx drivers
airlied: benh: you pretty much have two choices, (a) add the required atom tables from an x86 equiv, (b) port all the native modesetting code from radeonhd
benh: airlied: I could 'make up' ATOM tables
benh: however
airlied: benh: well I'm sure they are a lot the same as the x86 card
benh: agd5f: would you be able to find an "equivalent" card ATOM table ?
airlied: the data tables could be forged, the command tables are probablyt the same
benh: yes
benh: good idea actually
benh: if device-tree says "blah", then uise that cooked table
benh: and for clocks I can just use the values in the DT
airlied: there alos values like tmds pll etc
benh: device-id is 7240
benh: airlied: can't we read some of those values from the HW ?
benh: airlied: at worst, if one value is really missing, we may be able to ask the ATI Mac guys for it
agd5f: I'll ask the bios guys
airlied: benh: not usually, esp if the card doesn't post the tmds
benh: device-tree gives me the RefClk
benh: ATY,Rom# "113-A52070-109"
benh: not sure if that's relevant
benh: airlied: the card POSTs both TMDS at boot
benh: airlied: ie, OF does
benh: ATY,RefCLK 00006978 (27000)
benh: ATY,Rom# "113-A52070-109"
airlied: so the OF rom is all hardcoded?
benh: ATY,SCLK 0007a120 (500000)
benh: airlied: I don't know,
benh: airlied: there's an f-code driver in ROM that sets some properties and POST the card
benh: airlied: oh and sets modes etc...
benh: airlied: and that's taken over by the MacOS driver which usually barely uses what the OF driver says :-)
benh: ATY,MRT is the memory init table
benh: at least I have that
airlied: but the OF driver can do a quite a lot it seems
benh: yes
benh: ATY,Card# "109-A52031-00"
mjg59: Yeah, we've seen a lot of hardcoding in the Intel Mac case as we
benh: ATY,Flags 00000180 (384)
benh: agd5f: that one would possibly be interesting
mjg59: I don't think Apple changed their design philosophy
benh: VRAM,totalsize 10000000 (268435456)
benh: mjg59: you mean : gross hack and ship it ?
mjg59: Pretty much
benh: airlied: on laptops, OF often gives me the panel EDID too
mjg59: The egacy BIOS emulation actualy contains more usefu data than the native EFI code
mjg59: Because they need to get Windows booting...
nanonyme: Couldn't they just have gone with UEFI? :)
benh: mjg59: I have a long experience dealing with Apple, nothing surprises me :-)
nanonyme: New Windows' should be able to boot that too.
benh: mjg59: some of the bugs Paulus found in their ACPI and EFI stuff are fun
benh: mjg59: like the missing delay in the PCI reboot sequence
benh: mjg59: so it works if your CPU is slow but not if your CPU is fast :-)
benh: mjg59: becaues MacOS doesn't use it
agd5f: bootcamp provides and atom image
suokko_: Does anyone have any guess why radeontool is causing hard lock for me? Does it write something to somewhere?
agd5f: suokko_: what version?
airlied: suokko_: it shouldn't unless the card is locked up already
suokko_: airlied's
suokko_: That was the first repository whihc I found
mjg59: nanonyme: Yeah, that'l be a glrious future. A glorious future ful of an entirely new set of bugs.
agd5f: suokko_: ok. that's the right one
suokko_: I guess I need ssh+stderr output every where
agd5f: benh: can you read what kind of memory is on the board and the mclk?
benh: agd5f: ATY,MCLK 000927c0 (600000)
benh: so that's 600Mhz
benh: let me see the chips
benh: memory's hidden
benh: maybe they advertize it in the tech spec or the macos GUI
benh: I'll let you know if/when I find out
benh: however
benh: it's not OEM
benh: it's an ATI made card afaik
benh: so you should be able to find out too :-)
benh: X1900 GTO PCI-E 256M "Mac"
benh: (so 256M of VRAM)
benh: dunno the type yet
agd5f: oh, good
suokko_: But that has to wait tommorrow
agd5f: benh: subsytem ids?
benh: agd5f: not that I can see in the DT
benh: agd5f: might see some on PCI later when I plug it in a machine :-)
benh: agd5f: Apple stuf generally doesn't tho
agd5f: :)
benh: agd5f: however DT hsa
benh: ATY,Rom# "113-A52070-109"
benh: ATY,Card# "109-A52031-00"
benh: in case that's of any use
agd5f: thanks
benh: thinks ATI gets 27Mhz crystals for real cheap :-)
benh: have you had a different RefClk any time during the last 5 to 8 years ? :-)
airlied: benh: IGPs
benh: ah yes
airlied: 27Mhz goes back to original VGA I think
benh: some mach64 has different refclk's
benh: iirc
agd5f: pretty much every discrete card has a 27 mhz ref clock
agd5f: the igps are all 14 mhz
agd5f: I think the last one that was different was r128 which had a few 29 mhz cards IIRC
benh: ok
agd5f: benh: dual dvi I assume?
agd5f: DIN connector for tv?
benh: agd5f: yes
benh: agd5f: yes
benh: 9 PIN DIN
benh: didn't come with a cable (its a bulk card)
benh: but I think it's the same as my PC X1650
agd5f: I've got boxes of them if you need one :)
benh: haha
benh: no it's ok :-)
benh: I can see half of a chip near one of the DVIs
airlied: those 9pin din are a pain
benh: underneath the fan
airlied: normal tv-out s-video doesn't fit in them
benh: are they the same as the old Mac serial ports ? :-)
benh: XXXXneater
airlied: I only have a 9-pin din to composite connector here I can find
benh: XXXZUA43G
agd5f: there's 7 and 9 pin dins
airlied: the 7-pin arre compat with s-video
benh: XXXM1GS
agd5f: one works with s-video the other requires an adapter
airlied: the 9-pin are fail
benh: XXX604AA
benh: that's all I can read
airlied: also I got my x1950 with no cables ;)
benh: oh and "Taiwan" :-)
benh: could be a TMDS xmitter
benh: those radeons don't have two on-chip ?
airlied: but I found the composite converter with another card
airlied: benh: yes
benh: not a huge deal if we don't get secondary TMDS working right away
benh: one thing at a time
benh: can probably poke it on i2c anyway
agd5f: benh: secondary tmds is onboard on r5xx+
agd5f: just the old ones that have the external transmitter
agd5f: support for those still needs to be ported to kms
benh: ok so that isn't a TMDS chip
agd5f: nope
benh: could be analog crap
benh: second DAC ? TV ?
benh: composite encoder ?
benh: doesn't matter much I suppose
agd5f: probably a theatre chip for video in
benh: if necessary, you can probably get the details from the Mac guys
benh: ah yes, maybe
agd5f: I think the 9-pin DINs support video in
benh: ok, definitely not a priority
benh: XXXneater could actually be threater :-)
benh: yeah, that n could be an "h:
benh: can't see well
benh: that's the most likely indeed, theater
benh: so we don't care about it for now
agd5f: benh: there's code for it in the ddx. could write a v4l driver for it :)
airlied: started adding mm i2c code to my r200
airlied: but got lazy
airlied: was hoping I could make v4l drivers see something interesting
nha: osiris_: you rock!
nha: osiris_: Sauerbraten is *fast* for the first time ever :)
papillon81: nha: any news?
papillon81: sounds like i should do a git update :-)
nha: papillon81: well, osiris_' work on VBO and OQ was finally merged to master a while ago, and I've now been able to test it :)
nha: a while ago = a week or so
airlied: nha: suokko_ mentioned we could probably do a lot better on reemitting the shaders
airlied: nha: we seem to kick them out on each primitive
nha: it's possible that we do it on each draw call, I'm not sure; as far as I can see, there are two aspects:
suokko_: Now I notice how good the pool allocator is when I booted kernel without one :/ 2D is painfully slow
airlied: suokko_: I'm going to merge that into drm-next today
nha: 1. Over the years, some of the state reemit logic may have grown too conservative, i.e. it might be that shaders are marked dirty even though that's not necessary
suokko_: nha: shader state is rewriten for every TryDrawPrims call
nha: 2. One can treat both vertex program and fragment program memory as a ring buffer, which allows one to avoid certain synchronizations in the command stream
nha: suokko_: okay, that's definitely too conservative
airlied: we need to notice if the inputs/outputs change
nha: if you want to look into it, I'd be glad
suokko_: Also a lot other state data is per TryDrawprims instead of per command buffer in begin
nha: airlied: I suspect that one can often keep the shader and only upload new shader constants, and things like that
nha: suokko_: in theory, there's the whole logic of tracking which state is dirty, and only reemitting that dirty state
suokko_: nha: only in r200
suokko_: r300 doesn't do much of tracking if it realy changes the state
nha: suokko_: in theory, it also exists in r300, but it's been covered by so much dust that it's probably entirely ineffective by now
nha: somebody should go over this and produce tiny commits cleaning this stuff, being extremely careful to do a lot of regression testing
airlied: nha: yeah if only the attrib width changes also we can probably keep most of the shader
airlied: and just change the input stuff
nha: wow, Pulseaudio sucks... my Sauerbraten game profile has 54% CPU time in the pulseaudio daemon
airlied: nha: r300 just dirties the state too often
nha: exactl
nha: y
nha: trouble is, each of these dirtiness things was probably added in response to some bug once, and they've never been removed again :/
nha: and maybe, some of them were only added as a conservative measure, I don't know
agd5f: nha, osiris_: I finally dug up the info for extended instructions and temps on r4xx/rs6xx
agd5f: gives 512 instructions and 64 temps
nha: is that for fragment programs, or for vertex programs?
agd5f: nha: fragment
nha: okay cool, thank you
suokko_: bridgman: http://xorg.freedesktop.org/wiki/radeonBuildHowTo
bridgman: is building shelves right now
suokko_: It still need some work to have good quality info but it should have most of basic info
suokko_: gn
bridgman: looks good
bridgman: is it worth mentioning drm up near the front somewhere so people don't get confused if 6xx/7xx accel doesn't work ?
spstarr: feels the AMD GPU warm
spstarr: hullo bridgman
spstarr: agd5f: I hope all PM is moved to the drm driver and out of X's control
spstarr: one stop sysfs interface
mjg59: I've got this revolutionary idea
mjg59: Why don't we make PM just work?
airlied: mjg59: thats crazy talk
mekius: so how's r600 3D support these days? :D
raevol: mekius: in case no one else replies, a few weeks ago it was reported as 25% done, and that was after months and months of work
spstarr: mjg59: well, wouldn't it make sense to have the plumbing done first?
raevol: so don't expect anything soon
spstarr: mjg59: I dont mean writing the PM code in X driver then moving it to drm after that's just more work
mekius: raevol: well that all depends on how they measured 25% )
mekius: :)
mekius: Also, what does 100% imply heh
raevol: phoronix reported that someone working on it said it was passing 25% of the tests they wanted it to
raevol: that's as much as i know
kdekorte: mekius, it is getting there.. most of the demos are working and neverputt is ok, quake3 runs in indirect mode... but there is still more to be done...I have it running here
mekius: kdekorte: What do you mean by quake3 running in indirect mode?
embraceunity: Hey guys, I tried to run Morrowind through Wine on my R500 using the latest version from git. It plays at 5fps on the lowest settings, but on KMS it has the following errors http://pastebin.com/m30319613
bridgman: mekius, to run openarena I type "LIBGL_ALWAYS_INDIRECT=1 openarena"
bridgman: which runs openarena in indirect mode (so LibGL uses the GLX protocol to send OpenGL commands to the X server and then the X server calls the Mesa driver)
mekius: I see
bridgman: original thinking was that going through GLX worked around the problem with mixed vertex formats (eg mixing GLVertex2f and GLVertex3f) but that problem has been fixed and the corruption in Quake games is still there unless running indirect
bridgman: at least we think the problem with mixed vertex formats has been fixed ;)
EruditeHermit: bridgman: hi
EruditeHermit: bridgman: is there a difference between shader model 4.1 cards and SM 4.0 cards for Linux?
bridgman: I don't *think* any of the differences affect OpenGL but not 100% sure
bridgman: hold on...
EruditeHermit: bridgman: are they important differences for the future maybe?
EruditeHermit: bridgman: do you happen to know anything about replacing mobile GPUs?
EruditeHermit: is there a standard for them these days or is it totally vendor specific
bridgman: I only have the vaguest of ideas about replacing mobile GPUs
bridgman: it generally seems like a bad idea to me ;)
EruditeHermit: lol
EruditeHermit: problem is, you can't pick vendors then
EruditeHermit: you are stuck with whatever card is in there
mekius: they make laptops that make it fairly easy to do
mekius: but they are really expensive heh
EruditeHermit: mekius: like?
mekius: don't know off the top of my head, but there are some which have swapable pci-e cards afaik
EruditeHermit: people keep saying this
EruditeHermit: but I haven't seen that
EruditeHermit: the laptop I am getting has an nvidia card =(
EruditeHermit: I didn't think i would be unhappy about that ever
EruditeHermit: how times have changed
mekius: which nvidia card?
mekius: I just bought an 4850 in hopes that the open source drivers would come along soon :)
mekius: Not quite as soon as I had thought, but I'm in no hurry
mekius: I don't need to play that many games anyway :P
ayarter: hey folks. I'm having a prolem with the ati driver for xorg. Was wondering if anyone could point me in the right direction.
EruditeHermit: mekius: 9500M G
ayarter: I'm using debian sparc, and using the fbdev driver on my Sun Blade 2500, but I'd like to use the ati driver.
EruditeHermit: ayarter: what is the problem?
ayarter: The card is a radeon 7000 (Sun xvr-100, radeon v100),
ayarter: But I just can't get it to go; I just 'upgraded' from Solaris, and this is the last kink to work out.
EruditeHermit: what is wrong?
ayarter: So, I suppose, how can I make the radeon 7000 driver work for a Sun xvr-100 (same chipset)
EruditeHermit: does it not boot?
EruditeHermit: does it not show X?
ayarter: when I specify ati, it responds "do dirver found"
ayarter: *driver, rather
ayarter: Does not show X.
ayarter: when I use the linux fbdev, its fine; just really slow.
EruditeHermit: ayarter: when using ati, can you paste the /var/log/Xorg.0.log
ayarter: where would you like me to paste it to?
EruditeHermit: pastebin.com
EruditeHermit: or any online paste tools
EruditeHermit: whatever you prefer
ayarter: Erudite:http://pastebin.com/d57289d1f
EruditeHermit: ayarter: do you have xserver-xorg-video-ati xserver-xorg-video-radeon installed?
EruditeHermit: ayarter: you may want firmware-linux insalled too
ayarter: yes, I do have it installed
ayarter: I'm not sure what firmware-linux is. I just migrated from Solaris.
EruditeHermit: its a debian package
ayarter: okay, let me look it up and install it
ayarter: I can't seem to find firmware-linux for the sparc playform.
ayarter: So, I don't hink that I can install it.
EruditeHermit: hmm
EruditeHermit: well hang around here
EruditeHermit: maybe someone else will have some better suggestions
EruditeHermit: I'm not an expert
EruditeHermit: ayarter: also paste your /etc/X11/xorg.conf
EruditeHermit: to a pastebin
EruditeHermit: I have to step out for a bit, bbl
bridgman: EruditeHermit; not finding much consistency re: whether DX10.1/SM4.1 features were beneficial in OpenGL, but on average I would say the answers lean towards "yes"
bridgman: so assume "yes" unless you hear otherwise
bridgman: on the other hand I found an alarming lack of specific examples ;)
ayarter: lol, okay. Thanks.
ayarter: lol, last hurdle in my solaris / debian migration, what a pain.
ayarter: Its just been so long since I've worked with xorg.
bridgman: ayarter, I'm wondering if you might need a modified driver - is that an fcode-based system ?
ayarter: I don't think so.
ayarter: Its a Sunblade2500
ayarter: So sparc processors, openboot, etc
ayarter: I understand that the video card has its own video bios, and is flashable to the apple version
bridgman: here's the closest I found to a useful link, maybe it has a clue or 2
bridgman: http://forums.debian.net/viewtopic.php?f=5&t=39573
bridgman: hopefully that wasn't you posting ;)
ayarter: I wonder, if I specify a chipset in xorg, will it use that chipset?
bridgman: you specify a driver and the driver has to understand the rest... chipset, bios etc
bridgman: what I don't remember is seeing code in the driver to pick up system info from the fcode rom
bridgman: but it's not like I've looked in every corner of the driver
ayarter: i haven't added my busid yet, but I don't think that'd make a difference
ayarter: when I try to run X -configure, it tells me that no driver has been found
bridgman: let me try again to get your xorg log open
ayarter: okay.
ayarter: Its odd, I mean the card says "radeon 7000" on it, and I understand that its supposed to work.
ayarter: Just sucks, This particular Sun only accepted three video cards. And needless to say. none are cheap.
ayarter: were you able to open it?
bridgman: if it's supposed to work (by which I mean the specific case of a Sun XVR-100 card, not a PC-targeted radeon 7000 card with a PC VBIOS) then we should be able to figure it out
bridgman: worst case you'll need someone familiar with debian/sparc
bridgman: yep; I'm on dial-up so nothing happens quickly ;)
ayarter: Mater of fact
ayarter: when I
bridgman: have you pasted your xorg.conf ?
ayarter: lspci, I get
ayarter: 0003:00:02.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
ayarter: Well, the xorg I have right now is usinf fbdev.
ayarter: would you like me to post that?
bridgman: how much are you changing to run with the -ati driver ?
ayarter: I'm just changing Driver "ati"
ayarter: But I'm sure I'm doing something wrong.
bridgman: maybe I'm getting confused but I thought fbdev was a kernel driver not an xorg driver
airlied: bridgman: its both
bridgman: ok, if you're just changing one line then please pastebin your xorg conf
ayarter: I havent' set up X in years and years, and it wouldn't autogen, so I was stuck
ayarter: okay, one second
bridgman: airlied; that explains my confusion ;)
ayarter: http://pastebin.com/m5c49bf3f
ayarter: like I said, even lspci shows the card, I'm just doing something obviously wrong
ayarter: and I appreciate you taking the time out to help.
bridgman: airlied, can the radeon driver coexist with fbdev or do you need to disable fbdev ?
airlied: bridgman: it should co-exist in the not kill eveything sense
airlied: since on space you need a console
airlied: sparc even
bridgman: ok tx
airlied: but a log with ati or radeon set would be handy
bridgman: ayarter, just to confirm, was the xorg log you posted using "ati" for driver ?
ayarter: it was.
bridgman: airlied; here's the log : http://pastebin.com/d57289d1f
ayarter: Did you get my lspci output?
bridgman: no "RADEON" messages but not sure if that's normal with 6.9.0
airlied: did we get an lspci -vv?
airlied: guesses domain support probably
bridgman: watches attentively to learn what "domain support" means
bridgman: ok, PCI domain support... ?
airlied: yeah PCI domains from hell
bridgman: ayarter, the link I posted mentioned upgrading to a debian version with 2.6.29 kernel
ayarter: http://pastebin.com/mc9fe092
ayarter: I'm using whatever the latest stable is. I just migrated, two days ago?
airlied: I'm guessing you'll need X from unstable
ayarter: that's my lspci -vv
ayarter: The answer's in there, i'm sure.
airlied: since its not finding the pci domain
bridgman: http://bugs.gentoo.org/116666
ayarter: okay. I could try that. Funny, installing 'unstable' on a Sun.
airlied: you could try adding BusID "PCI:0@3:2:0"
airlied: to the device section of the xorg.conf
airlied: it might find it then but I doubt it
ayarter: i thought about that, I just read that we weren't supposed to do that unless we had 2 adapters installed
ayarter: is PCI0@3:2:0 from my lspci, of do I need to find my machine's bus number?
airlied: from your lspci
airlied: yeah domain support isn't top of anyones testing list most day
airlied: machines with domains usually cost money
bridgman: airlied, the lspci -vv indicated that radeonfb was in use, would that be a prob ?
airlied: bridgman: nope that should be fine, its the only reason fbdev works
ayarter: I just know that I can't start X unless I use the 'fbdev' driver
airlied: I suspect the X server has no domain support
ayarter: if its using the radeonfb driver, then maybe it is working right, and I dn't need the ati driver?
bridgman: would a newer X server be more likely to have it ?
airlied: it was always a hack until pciaccess days, and even then its not great
airlied: ayarter: thats the kernel not the userspace
bridgman: if so then upgrading to a newer debian keeps sounding better
ayarter: than latest stable?
airlied: stable is about 2 years old
mekius_: Has anyone put together a decent list of things necessary to build r600 3D support? Just want to track the dev
airlied: 1.4 server is 6 Sep 2007
bridgman: dead things are very stable
bridgman: mekius; are you talking about dependencies or build instructions ?
ayarter: allright. Can I do that trough the update manager, should I compile the kernel, or should I just re-install ?
EruditeHermit: bridgman: thanks for looking it up. So you mean to say they aren't currently used in any OpenGL spec, but there is a possibility that they will be?
mekius_: bridgman: Well instructions would be nice, but I'm just not sure exactly where all the pieces of the puzzle are :)
mekius_: bridgman: I assume I need a git version of mesa and other things
bridgman: ok hold on
airlied: ayarter: http://wooledge.org/~greg/sidfaq.html
bridgman: http://jbridgman.livejournal.com/945.html
bridgman: scroll down to the end
airlied: has some info I don't speak enough Debian
bridgman: wonders what distro they do speak in 'Oz
mekius_: bridgman: thx, I'll take a look
airlied: bridgman: the one that pays the wages ;-P
bridgman: ah yes, that one ;)
mekius_: haha
ayarter: so I really just need to update xorg to uinstable thenm, before I do anything else?
airlied: ayarter: yup
bridgman: not sure if you need kernel too; I would be tempted to update everything but that's just me
bridgman: btw that's risk aversion not expertise talking ;)
ayarter: lol, awesome. I'm a Solaris user, so its just the little things that are driving me nuts.
ayarter: I really appreciate your help guys.
mekius_: bridgman: Is 2.6.30 new enough for all of this to work or should I snag a newer kernel?
bridgman: you need to build a new drm anyways so 2.6.30 should be fine
bridgman: hopefully all this will get into 2.6.32
bridgman: closes eyes and wishes real hard
mekius_: k
mekius_: haha
mekius_: sigh...git just kills my connection :/
bridgman: firewall or something ?
mekius_: not sure, my connection just seems to start to lag heh
mekius_: but doesn't seem to be the issue atm
ayarter: Well, debian has weekly 'testing' ISOs. I'm just going to do that
ayarter: dated august 24th, 09.
bridgman: mekius; if you have a fast link and don't mind wasting a download you could just pull the source snapshots from the latest changelist
ayarter: since this a fresh install, I'll just download and install that
bridgman: it's a pain for updates though because you have to re-pull everything
bridgman: ayarter; sounds good, wish I could give better advice here
mekius_: bridgman: nah, i'll do the clone, just need to kick my cable modem
mekius_: comcast is horrid
ayarter: oh, its fine. I'm just finding debian a lot more "fun" than Solaris
ayarter: It just gets so "solarisy" sometimes.
bridgman: I don't remember ever seeing "fun" on the list of Solaris requirements ;)
bridgman: although I bet I could have fun with that timeshifter thingy
EruditeHermit: bridgman: is that the revision control filesystem thing?
bridgman: yep
bridgman: it's probably useful for something other than messing with your co-workers heads, but what more reason do you need ?
mekius_: haha
ayarter: so, just out of curiosity, what are pci domains?
mekius_: doh! http://pastebin.com/m98458e1
mekius_: gah pastebin doesn't like utf8 much apparently
airlied: agd5f: r600_cp.c:gb_tiling_config |= R600_BANK_TILING((ramcfg >> R600_NOOFBANK_SHIFT) & R600_NOOFBANK_MASK)
airlied: seems wrong mask then shift ;-)
mekius_: http://nopaste.com/p/a30Eum3ie
mekius_: that's a bit better
bridgman: ayarter; all that Google returns are a list of people asking what PCI domains are ;)
airlied: ayarter: for some hw people buses weren't separate enough so they made domains
bridgman: they seem to be separate address spaces
airlied: most uses of them I've seen are generally hw wankery
bridgman: in theory they are documented as part of the pci host bridge spec
bridgman: but even that is hotly challenged
ayarter: figures. I knwo I have 33 mhz and 66 mhz pci slots in here
mekius_: anyone know what I'm missing?
mekius_: or did I just grab at a bad time heh
ayarter: I'm upgrading to unstable now.
bridgman: mekius; looking now
mekius_: bridgman: thx, sry to bug :)
mekius_: google didn't give me much but a bunch of patches when I went looking :P
bridgman: did you build in the order in my blog; drm first ?
bridgman: just guessing, but it looks like you built mesa before building & installing drm
mekius_: hmm, shoudl have, i'll double check
mekius_: hmm, same errors after verifying drm is installed
yangman: IIRC, you need to have mesa include the correct drm kernel headers
mekius_: ah
yangman: I'm also "stuck" on that step, mostly because I don't see a clean way to do that while keeping my installed kernel sources untouched
mekius_: well the headers install somewhere else do they not?
mekius_: can't I just point configure to use those wherever they are?
yangman: none that I could see
mekius_: I wish I could legally choke out the heads at comcast...
bridgman: there's probably an online service that will do it for you
airlied: agd5f: ah ignore that, glisse changed things a bit, just confirming they aren't what broke it
mekius_: haha
mekius_: ok I installed the regular drm git and it seems to build now, could the one you have listed in those instructions be out of date or something?
mekius_: git://git.freedesktop.org/git/mesa/drm is what I grabbed
mekius_: well installed that is
bridgman: no, that one won't work AFAIK
bridgman: but maybe you can pull down the drm from agd5f's branch, build it, and then mesa will still work ;)
bridgman: that's what I would try next anyways
bridgman: so drm from ~agd5f/drm r6xx-r7xx-3d branch (build and install) followed by trying to build mesa again
mekius_: :)
mekius_: i'll give it a shot heh
mekius_: nope same error
mekius_: so that's definitely what's breaking the mesa build
mekius_: I can't imagine things will play nice if I build mesa against one libdrm and then install another :D
bridgman: it seems unlikely
mekius_: unlikely to work?
bridgman: yeah
mekius_: well then :/
bridgman: I'm kinda between systems here or I would try building myself, but just downloading the source would take about two-and-a-half million years on dial-up
mekius_: is it possible to merge stuff from the drm head into the clone of his repo?
mekius_: lol
bridgman: it's faster to drive 65km to work, load up a USB key, and drive home
bridgman: probably, but this was building fine earlier today
mekius_: hmm
mekius_: strange given the amount of errors
bridgman: nah, compilers are wonderful error-multipliers
bridgman: I've seen one typo cough out 200 pages of errors
mekius_: Oh I know :)
bridgman: looks at all the lurkers and figures *one* of them must have tried building recently
yangman: mesa master for r600 depends on some newer values in the drm headers
mekius_: I code for a living, I know how that goes hehe
mekius_: wonder if it's just a missing header, hmm
bridgman: how new ?
yangman: no idea. I tried building it last week, had the same problem, found out why, and kinda moved on to other stuff :p
bridgman: I built it a few times today with no problems
mekius_: yeah, in the latest head the RADEON_GEM_DOMAIN_VRAM define exists in radeon_drm.h, but not in the version from his repor
mekius_: repo*
bridgman: did you use the same configure string I had - disabling gallium, only building r600 and swrast ?
bridgman: not sure if I included swrast actually
mekius_: in fact it seems all the missing defines are in there
mekius_: could probably hack this together :)
mekius_: yeah, same config string
mekius_: it's definitely trying to build r600 support, that's what it's dying on because of missing defines :/
mekius_: let me do some magic :)
bridgman: yeah, I was just wondering if you were also trying to build something that needed GEM/TTM stuff
bridgman: only a bit of that should be needed for current r600 mesa
mekius_: yeah
mekius_: it's fun time :)
bridgman: I can't handle any more fun today, time for zzz
bridgman: bbl
EruditeHermit: later bridgman
mekius_: nice, copied radeon_drm.h from the head and it built heh
mekius_: gah, now xf86-video-ati won't build...
mekius_: sigh...
mekius_: seems it builds against current libdrm :/
mekius_: brb
mekius_: I has dri :D
DanaG: hmm, how's the font stuff on r600+compiz nowadays
DanaG: ?
mekius_: glxgears rockin out at 3k fps, xvmc working good :)
mekius_: wow, I can fire up warcraft III even and it seems to run at a decent framerate in the menu, unfortunately it's a flicker fest heh
mekius_: nice, good work :)
mekius_: oh nice! it was xcompmgr causing the flickering, without it it works great
mekius_: fonts look ok in war3, don't have anything else installed to test atm :)
mekius_: oh compiz, don't use that :)
mekius_: I use enlightenment ;)
mekius_: man, 25% done my ass, this driver works amazingly well heh
mekius_: it's pretty fast and I haven't seen an artifact yet in war3, even though it's an old game I had no idea it was this far along :P