ssieb: soreau: an increase? I see a significant decrease when I turn on kms
soreau: ssieb: yes, as compared to dri1 but Im referring to progressions strictly testing with kms
nanonyme: soreau: As was deducable from your mentioned OpenGL version, yes. :)
simplexe: agd5f: you here?
EruditeHermit: soreau: I don't see any increases in performance, but I see new features
EruditeHermit: if anything I am seeing very slight performance degradation but its so insignificant it might just be my samples are wrong
EruditeHermit: that being said, when compared to dri1, it is between 1/4 to 1/3 performance
EruditeHermit: of dri1
nanonyme: He was not comparing it to DRI1.
nanonyme: He was comparing DRI2 now to what it was some time ago.
soreau: nanonyme: indeed
nanonyme: Everyone's aware it's probably slower than DRI1. :)
soreau: Again, true
airlied: and really if its only gears you are measuring with then no-one cares ;0
nanonyme: Besides, I didn't think you can get OpenGL 1.5 with DRI1.
airlied: FBOs are the main thing you can't get with DRI
airlied: FBOs are the main thing you can't get with DRI1
nanonyme: Loopity. :)
nanonyme: Which version are they required for?
airlied: its not really versions
airlied: more a lot of things want the extension
soreau: airlied: To be real, I am testing with 3D apps such as (but not limited to) mupen64plus N64 emulator
nanonyme: Right...
nanonyme: Probably part of 3.0 though. X)
airlied: soreau: any profiles on what is using the cpu time/
airlied: I think ARB_framebuffer_object is in 3.0
soreau: airlied: Nope. Wondering if therell be a -31.rc9
soreau: still gets black screen when invoking compiz water
MostAwesomeDude: ARB_fbo is in 3.0; EXT_fbo is possible with 1.2+ but optional.
MostAwesomeDude: IIRC EXT_fbo got redefined during 2.1, so it's kind of iffy around the edges.
MostAwesomeDude: And it doesn't actually match ARB_fbo. It's different.
soreau: plants if statements all around MostAwesomeDudes edges
simplexe: hmmm...latest update 3D freeze with kernel drm error
MostAwesomeDude: is glad that FBO magic is handled by upper-layer Mesa.
nanonyme: MostAwesomeDude: Sounds like pain.
nanonyme: That is, when you use it in applications.
MostAwesomeDude: nanonyme: Can't be worse than ARB shader objects vs. GLSL shader objects.
simplexe: airlied: pls, see log http://paste.org.ru/?km4u61
nanonyme: That is, since you have to know there's multiple versions of it and it might not do what you expect unless you check version.
MostAwesomeDude: nanonyme: The ARB and EXT FBO functions are different; you'd have to have two different versions of things.
airlied: simplexe: r600?
airlied: MostAwesomeDude: ARB version merges EXT_framebuffer_blit and makes some other bits sane
MostAwesomeDude: TBH I'd rather do a split-up of that kind of functionality anyway because of other accelerated framebuffer-grabbing things like SGIX_pbuffer.
MostAwesomeDude: airlied: Yep, all kinds of fun things.
airlied: MostAwesomeDude: pbuffers are a GLX extension
nanonyme: MostAwesomeDude: Yeah but can't any pre-2.1 implementation have the old version of FBO's?
MostAwesomeDude: nanonyme: Sure.
airlied: any pre 3.0 can have version of FBOs
MostAwesomeDude: nanonyme: I meant that the idea of "renderbuffers" changed during 2.1. IIRC, of course; I could be off.
nanonyme: Cute.
EruditeHermit: nanonyme: yes I know
simplexe: airlied: yeah
airlied: should finish ARB_fbo
airlied: simplexe: I'm not really aware or non-kms r600
EruditeHermit: airlied: not only gears, but xmot, urban terror, fretsonfire and all GL demos
nanonyme: So yeah, again, sounds like pain when writing OpenGL programs.
airlied: simplexe: looks like a gpu crash
EruditeHermit: nanonyme: my first statements were comparing DRI2 old to DRI2 now, and then I was just comparing DRI2 to dri1
EruditeHermit: sorrry for the confusion
nanonyme: Right.
EruditeHermit: MostAwesomeDude: btw Gallium lists GL_ARB_shading_language_120 but the OpenGL version string is 1.3
EruditeHermit: it seems to have a random smattering of extensions
simplexe: airlied: i know
EruditeHermit: and missing a bunch
zhasha: EruditeHermit: r300-gallium enables GLSL, but not all the other required extensions for 1.4+
MostAwesomeDude: EruditeHermit: It's kind of hodgepodge right now.
nanonyme: MostAwesomeDude: Is r300g core functionality getting pretty sane though already?
MostAwesomeDude: nanonyme: I haven't touched it.
Zajec3: i asked about r300g yesterday, got: http://www.x.org/wiki/GalliumStatus
Zajec3: but don't understand that table
nanonyme: It seems to be split weirdly.
nanonyme: as in, I thought exa would be part of xorg state tracker, for example.
zhasha: Zajec3: it refers to supported state trackers which is utterly unhelpful
EruditeHermit: zhasha: does the GLSL work?
zhasha: EruditeHermit: to my knowledge yes
EruditeHermit: how did it pull that off
EruditeHermit: thats amazing
zhasha: we're using the same compiler as the old radeon driver
zhasha: thanks to nha
EruditeHermit: zhasha: so if I run the tests in the GLSL directory, they should work/
zhasha: nah, other stuff is broken
airlied: there shouldn't be any GLSL yet
airlied: nha's compiler is just ARB_vs/fs
zhasha: I thought he added the last bits for GLSL
airlied: when he gets GLSL going iit'll work in classic and work in gallium
zhasha: but what's the exa column doing in that table?
nanonyme: As said, that's imo dubious, I thought it should be part of the xorg column.
nanonyme: Since it's afaik the xorg state tracker that does exa...
nanonyme: (at least was when I last looked)
EruditeHermit: airlied: so are those extensions in there a mistake?
zhasha: EruditeHermit: we explicitly enable them
zhasha: if our compiler can't handle it though, then it shouldn't work
EruditeHermit: ah
EruditeHermit: zhasha: are you working on r300g?
zhasha: I thought nha had gotten the last bits in place, but I guess we're just short a few flow control instructions
zhasha: EruditeHermit: sometimes
nanonyme: looks forward to migrating from xf86-video-ati to Gallium3D
zhasha: nanonyme: not until the xorg state tracker does exa :P
nanonyme: zhasha: Memory manager's not working properly for my GPU anyway yet. ;)
zhasha: it has loads of bugs here
zhasha: but it works
nanonyme: zhasha: Are they r300g bugs or state tracker bugs though?
nanonyme: (let alone there's no r600g driver anyway)
MostAwesomeDude: That table is intentionally fail.
zhasha: nanonyme: they're ttm related bugs
nanonyme: Would still imply the xorg state tracker is pretty much innocent though. :3
zhasha: MostAwesomeDude: why intentionally?
EruditeHermit: hey nha
nha: bonjour
EruditeHermit: ca va?
zhasha: you're not french. stop speaking french!
EruditeHermit: moi?
EruditeHermit: =p
Zajec3: zhasha: are you american? :)
zhasha: Zajec3: no, I'm danish
MostAwesomeDude: zhasha: Hopefully to embarrass people into documenting things.
Zajec3: stop speaking american ;)
Zajec3: :P
zhasha: I have a personal beef with France and the general population of people refusing to learn anything but french
Zajec3: MostAwesomeDude, nanonyme, zhasha: maybe you could just change that Gallium table to show something serious? :)
zhasha: Zajec3: It's hard to show something meaningful in terms of gallium pipes
Zajec3: thinks http://wiki.x.org/wiki/RadeonFeature should be updated for r600 status
zhasha: and even if we did, frankly it wouldn't be comprehensible to anyone not developing it
zhasha: hell if MAD wrote it I probably wouldn't understand it
MostAwesomeDude: Zajec3: What should I put in there? :3
nanonyme: hopes that didn't mean you think MAD lacks clarity ;(
zhasha: I don't. He just has a way better grasp on the sauce than me
Zajec3: MostAwesomeDude: no idea... anything that could help track status :/
zhasha: and what the hell is XvMC doing under gallium features in the matrix?
Zajec3: currently I have no idea how far is r300g from rendering glxgears/openarena/compiz
nanonyme: zhasha: There's a state tracker for MC.
zhasha: you mean g3dvl?
nanonyme: I might, unsure. :) I just know there's some state tracker in G3D that supports MC. ^^
Zajec3: what does dvl stand for?
zhasha: g3dvl is shader based video decoding
nanonyme: Zajec3: G3D VL
Zajec3: VL? Video L...?
nha: omg, why are you all so active that early in the morning
Zajec3: nha: :D
MostAwesomeDude: nha: I don't sleep. :3
nha: (yes, I know, timezones ;))
zhasha: nha: I'm in the same zone as you
zhasha: also, what is Core Driver in the matrix?
nanonyme: Probably the thing people mean when they talk of Gallium core.
nha: oh great, a bird just flew into my room
nanonyme: nha: Say hello to it from me.
mcgreg: do you guys by chance know if amd mobility cpu's have that virtual cpu stuff in there? (for KVM)
nanonyme: Might or might not, check specs for the CPU.
nha: conclusion: birds are more intelligent than insects (your random wasps would have spent the next half hour flying against a closed window, but this guy found the exit pretty quickly)
nanonyme: Most recent AMD CPU's are said to ship with it.
zhasha: nha: what's missing for GLSL support? flow control? and can that be done on r300 in any way?
nha: zhasha: mostly flow control. On r300, there is no native dynamic IF/ELSE/ENDIF, but we can simulate it by running both branches and then using CMP
nha: also, there is trouble in loops
zhasha: can r300 do loops?
nha: I seem to remember vps can do basic loops
nha: though maybe this was only r400+, I always forget this
zhasha: I didn't think r300 could, in any way, do flow control
zhasha: as in, no branching, no jumping, just linear execution
nha: r300 vp can do fixed length loops, according to the docs
nha: r300 fp can't do anything
MostAwesomeDude: NOISE is another; can't remember if Mesa st has a fallback for it yet.
zhasha: MostAwesomeDude: spec says the average has to be 0
zhasha: so return 0
nha: zhasha: the spec also says something about octaves and so on ;)
MostAwesomeDude: zhasha: Not quite that easy. Anyway, it's completely possible to do with a fallback textures.
MostAwesomeDude: *texture, even.
zhasha: I hate specs
nha: but yeah, we'd have to check how many ALU instructions it would take to implement, and how viable a TEX implementation of NOISE is
zhasha: does noise have a TGSI equivalent?
nha: yes
nha: TGSI is a superset of all shading languages out there
zhasha: then we can't rely on mesa's ability to overcome the lack of a NOISE
MostAwesomeDude: PIPE_CAP_FRAGMENT_NOISE will probably be necessary, and everybody will mark it 0 because nobody actually has RNGs onboard.
zhasha: must be implemented in the pipe
zhasha: if it's in the spec, why aren't vendors putting a RNG onboard?
nha: look, IIRC not even r600+ has a native NOISE instruction
nha: we'll just implement it using either ALU instructions or some TEX lookups, same as the software renderer
zhasha: MostAwesomeDude: http://www.x.org/wiki/CorbinSimpson <- evidently you made an r600g driver :P
airlied: nvidia always used to return 0
zhasha: I thought nvidia used 0.5
MostAwesomeDude: zhasha: Yep. Just gotta type it up.
MostAwesomeDude: points to head
MostAwesomeDude: It's all in here.
airlied: now that r600 kms sorta works, I expect a gallium driver by tomorrow ;-P
zhasha: No problem, let me just get out my robe and wizard hat
airlied: nha: you look at r600 enough to know if compiler is any use or we need another one?
nha: I've not yet come to a full conclusion. I do believe the dataflow analysis from the compiler could/should be used (since using less ALU slots that absolutely necessary is a clear win), the back-end would probably be quite different
nha: I do think there is definitely potential for sharing, but it's not clear just how far it could take us
nanonyme: zhasha: X)
muep_: Fedora 12 snap1 seemed to use KMS on my HD3650, but unfortunately it failed to find the root filesystem
zhasha: lol
zhasha: I see you have a HD3650... wait, where the hell is your harddisk?!
nanonyme: muep_: It doesn't really work properly... At least didn't when I last tried.
nanonyme: Dunno if airlied has pushed more KMS bits since then into it.
muep_: at least text mode seemed to work quite nicely
nanonyme: Well, that has worked since Fedora 11.
muep_: not for R600
nanonyme: X doesn't.
nanonyme: Yes, it has.
muep_: or has it?
muep_: oh, ok
nanonyme: Just have had to do radeon.modeset=1.
nanonyme: The r600 KMS bits that can actually start X are still pretty new though afaik.
airlied: we should have EXA/Xv/DRI2 pushed next week
nanonyme: Neat.
nanonyme: Will be keeping my eyes open on koji then.
Zajec3: airlied: do you mean pushed mainline? or this already available as single patches?
EruditeHermit: nha: can r300 do GL 2.1 and GLSL 1.2 then?
EruditeHermit: nha: the hardware itself claimed only to support 2.0 GLSL 1.1
nha: EruditeHermit: I haven't looked at the fine differences between GLSL 1.1 and 1.2 yet
EruditeHermit: oh ok
EruditeHermit: I thought that was the discussion above
nha: right now, I'm working mostly against r500 anyway
EruditeHermit: about loops
airlied: Zajec3: I meant fedora
Zajec3: airlied: ah :)
airlied: it should be going into drm-next around the same time hopefully
Zajec3: oh, great
Zajec3: would like to just checkout some tree
Zajec3: instead grabbing 5 patches from random places ;)
stikonas: can anybody tell me where can I find patches for 2.6.31-rc9 to get 3D on R700?
stikonas: s/can I/I can/
simplexe: stikonas: kernel.org?
stikonas: they were ment to go to 2.6.32 and merge window is not yet opened
simplexe: stikonas: git?
stikonas: maybe, I found some interesting branches on git.kernel.org drm-2.6
simplexe: take rc9 snapshot here http://repo.or.cz/w/linux-2.6.git?a=commit;h=e07cccf4046978df10f2e13fe2b99b2f9b3a65db
simplexe: this is linus tree
stikonas: I have it installed
simplexe: 2.6.31-rc9?
stikonas: yes
simplexe: and/
simplexe: and?
stikonas: Software Rasterizer
stikonas: this is a new laptop, I've installed OS just yesterday
simplexe: all drm patch commiting in linus tre
simplexe: *tree
simplexe: stikonas: hmm... you have installed latest mesa, libdrm?
stikonas: I think so
stikonas: the problem is that /dev/dri is missing
simplexe: -22?
stikonas: the same
simplexe: chek this
stikonas: I'll probably recompile another kernel
jcristau: simplexe: 3d for r700 is not in linus...
stikonas: there is r600-wip branch in drm-2.6 repository at git.kernel.org
dileX: (jcristau replied faster)
stikonas: that's why I asked for patches
stikonas: because I've heard that they ar going into 2.6.32
dileX: thats very WIP
simplexe: jcristau: hmmm... my mistake
dileX: simplexe: or follow instructions in wiki
nha: oh wow, the Gallium driver is a mess :/
nha: MostAwesomeDude: we need a better debugging facility in r300g
matuu: bye
zhasha: nha: working on it
boghog: hi everyone
nha: zhasha: just committed it :}
nha: sorry
zhasha: comitted better debugging?
nha: well, not really better
nha: just a way to mask off the worst of the debug spam
nha: take a look at it, if what you were working on is better feel free to change it again
zhasha: nha: I'm working on something a little different
nha: k
zhasha: it's an external tool to review cs's
zhasha: when I finally get around to actually coding it, it should be pretty neat
nha: oh, that does sound cool
zhasha: the reason I'm procrastinating that I need to go over a register spec file
zhasha: although I've done most of the work already
zhasha: nha: generating a register spec file from the amd docs, using regexes like this:
zhasha: ([A-Za-z0-9_]{1,4}):([A-Za-z0-9_]+)(\[([0-9]+)-([0-9]+)\]|)([A-Za-z0-9_]*).*[^,] MMReg:0x([0-9A-Fa-f]{1,4})(-0x([0-9A-Fa-f]{1,4})|).*\nDESCRIPTION: (.*(\n.*)*?)\nField Name +.*? +Description.*\n([^ยท]*\n)+
boghog: 's head explodes
nha: fun, fun
zhasha: boghog: I wrote that one you know
boghog: pervert!
zhasha: I have a mostly complete spec file for r300 AND r500, merged into 1 with shared registers merged
gkelly: Is there any way to get opengl 2.0 support on an r300 card right now?
gkelly: Nevermind, just found RadeonFeature.
zhasha: gkelly: there's probably no way to get gl 2.0 support ever on an r300, without significant software emulation
zhasha: i.e. it will be really slow
gkelly: zhasha: How come? The hardware will do 2.0.
zhasha: huh, I thought more advanced flow control was required
zhasha: I'm probably thinking of 2.1 then
nha: MostAwesomeDude: btw, I encourage you to compile r300g with make -s and get rid of all those remaining warnings...
gkelly: zhasha: Sorry, I missed your response (if you responded).
zhasha: nha: seriously, r300g is just a heap of for end users, unusable code as it stands right now. I don't think anyone minds the warnings
boghog:
boghog:
zhasha: as long as they're not errors
nha: zhasha: that is *exactly* the kind of attitude that will guarantee that r300g remains that heap for a long time
nha: seriously.
nha: warnings like "no prototype" or "implicit function decl." are prime candidates for bug hiding
Zajec3: should we expect milestones in r300g to be similar to these for classing mesa driver?
zhasha: nha: those errors show up as linker errors later
Zajec3: mesa tests -> glxgears -> game?
nha: zhasha: no they don't
nha: zhasha: they either show up as *crashes* (when one .o uses a different parameter definition as the other .o) or as people wondering why the heck they're falling back to software rendering or indirect rendering
zhasha: nha: when you try to run any application using the driver, it will tell you "missing symbol"
nha: no, it will fall back
nha: and you only see that error with LIBGL_DEBUG=verbose
nha: there is *no* excuse for this kind of warning to exist in *any* code, no matter how experimental
zhasha: considering I am debugging the driver, does it NOT make sense that I use LIBGL_DEBUG=verbose all the time?
nha: zhasha: not really, because normally it's not libGL you're debugging
nha: but that's completely beside the point
zhasha: nha: laziness is a good excuse
nha: uhh...
nha: somebody was asking this previously, and I just checked: even GLSL 1.10 loops are more than r300 can handle
nha: r500 should be up to it, though
kkuno: how can I set a default screen resolution without xorg.conf?
frej: hmm, are backtraces from wine progs interesting/usefull at all? civ4 finally works with mesa 7.6 but after bo/oq was introduced it crashes somewhat often http://pastebin.com/m13159bec
gkelly: nha: Ah, that was me. Thanks for the heads-up.
bridgman: zajec3; re: Gallium3D progression, I think gears already works; Cooper is going through the mesa tests now and fixing things
bridgman: I think ~25% of redbook tests passed as of yesterday
agd5f: kkuno: http://wiki.debian.org/XStrikeForce/HowToRandR12
Zajec3: bridgman: oh, that's nice, thanks
nha: there's a bug in r300g wrt readpixels from the front buffer
nha: some piglit tests do render to backbuffer; swapbuffers; read from front buffer
nha: that fails
nha: don't have the time to track it down further right now, but I might get to it this week
nha: btw, I've pushed some preliminary compiler work to my repository on fd.o
nha: basically, reworking the nqssadce code into something that is extensible to branches and loops
simplexe: agd5f: you here?
agd5f: simplexe: pong
simplexe: agd5f: hi
agd5f: simplexe: what's up?
simplexe: there are a couple of questions, take the time?
agd5f: sure
simplexe: in first release blit in r600 something game from wine works good. after update (2-3 commits) this game works, but texture broken. like here http://pixs.ru/showimage/Snimokpng_2661418_301734.png
Zajec3: simplexe: did you recompile mesa?
Zajec3: make clean && make
agd5f: simplexe: what packages and what commits?
Zajec3: with clean... really
agd5f: simplexe: also, please try what Zajec3 suggested
simplexe: after latest update (ext srgb), other game, which not run works great. see shot http://pixs.ru/showimage/SnimokFree_2796416_301002.png
simplexe: i know how to recompile mesa
agd5f: simplexe: does reverting the srgb commit fix it?
simplexe: agd5f: no
simplexe: 2-3 commits before first blit release
agd5f: simplexe: see if you can find what broke it using git bisect
agd5f: simplexe: sounds like it might be http://bugs.freedesktop.org/show_bug.cgi?id=23657
simplexe: s/before/after
agd5f: simplexe: what was "first blit release"
agd5f: brb
simplexe: sec
simplexe: agd5f: http://cgit.freedesktop.org/~agd5f/drm/commit/?h=r6xx-r7xx-3d&id=e646400994de1167fc149e5f396deebf71504275 this is start release. yes?
zhasha: static u32 r6xx_default_state[] <- that can so not be good :P
simplexe: this update improve speed http://cgit.freedesktop.org/~agd5f/drm/commit/?h=r6xx-r7xx-3d&id=306d4c97fe64283e81429474a0b707e010d69f2f
simplexe: and after this ^ update i update mesa, oblivion from wine works like as openarena.
simplexe: after 2-3 commits in mesa or drm module, texture from oblivion loading as http://pixs.ru/showimage/Snimokpng_2661418_301734.png
simplexe: i think, after update in latest mesa package fixed this problem. but something game which crash before - works great, with some effects, but without texture. and problem with drawing texture in oblivion not fixed.
bridgman: simplexe, the bug that agd5f linked mentions a commit that broke textures
bridgman: can you take mesa back before that commit and see if oblivion works ?
simplexe: bridgman: hmmm... yes, i can
AStorm: any r6xx power management improvements lately?
nanonyme: bridgman: Btw, might expect quite some diversion in r600 next week with part of the users starting to drool after KMS. ;)
AStorm: r6xx getting KMS?
nanonyme: More like the stuff that's been hacked together is concentrating so it's actually possible to test it with relative ease.
AStorm: heh
AStorm: again, what's the state of power management on r6xx?
nanonyme: No change afaik.
AStorm: hm :(
Zajec3: AStorm: i think we will focus on that soon after pushing r67xx kms
AStorm: it's fairly lacking right now
Zajec3: sure it is :)
AStorm: yeah, that's the spirit
Ampheus: yep, my fan is running on fll speed all the time :)
Zajec3: AStorm: when r67xx will be there ready to some use, it'll be much easier to work on it
Ampheus: is kms for 67xx in master now?
Zajec3: now... don't think anyone wants to really work on KMS in DDX
AStorm: I don't think so.
Zajec3: Ampheus: not yet, should be merged to .32
Ampheus: ok, thanks
simplexe: bridgman: no ((
Zajec3: AStorm: airlied told sth about preparing drm-next on next week
simplexe: bridgman: package has deleted
AStorm: :)
simplexe: but this works, RTT3 works, slow, but works )
simplexe: oblivion crashed after loading new game
bridgman: ok, crashing is probably something different
bridgman: maybe manually back out the commit mentioned in the bugzilla ticket from the tips of mesa
bridgman: or wait until someone figures out how to fix the problem and then maybe oblivion will start to work again
agd5f: simplexe: if nothing else, just try bisecting
bridgman: simplexe, was there a point where oblivion worked without texture problems ?
agd5f: zhasha: that's just the default state needed for the blit. It's not worth dragging the 3d driver into the drm just to set up state that will always be the same
agd5f: isn't oblivion a dx10 game? I suspect there's a lot missing for it to work
simplexe: agd5f: no this worked with dx9
zhasha: agd5f: the XP version is at least DX9
zhasha: AFAIK it only needs fs/vs 2.0
zhasha: according to the DX spec thats version 9.0b and a few below
simplexe: railroad tycoon 3 (rtt3) - works with dx8. this is problem not dx9
simplexe: bridgman: http://cgit.freedesktop.org/mesa/mesa/commit/?id=c2b29b5df506d747e9a53bbcf5a45dc7cfe65643
simplexe: this is start point where oblivion works like as openarena before latest adding ext rgb and etc
zhasha: simplexe: wine isn't the best test app
simplexe: zhasha: i know )
zhasha: an opengl application in wine maybe
zhasha: what we need is a direct9/10/11 state tracker
mekius: warcraft III works with good fps on my 4850 without any hacks :)
zhasha: mekius: try running it with the -opengl parameter
mekius: yes I do :)
zhasha: oh, okay
mekius: with directx it's terribly slow even with nvidia/ati binary stuff
mekius: I couldnt' believe it worked, I saw 0 glitches, was amazed :)
mekius: with the way everyone made it sound, I couldn't believe it could run something so complex already heh
zhasha: because I ran it without it on my rv515 and got 25FPM (frames per millennium), but with -opengl it ran smoothly
nha: MrCooper: ty
mekius: lol, fpm
zhasha: seriously, it was hard exiting the app
Zajec3: bridgman: do you know about plans for r600/r600g?
mekius: yeah, just press esc :)
Zajec3: do we want fully functional driver? how much you want to focus on r600?
Zajec3: or do you plan to switch to r600g and then spend more time on it?
zhasha: Zajec3: whatever they do, it won't be until they finish classic mesa r600, and that will probably take some time
AStorm: agd5f, btw. will that drm-next you're cooking up contain r6xx-r7xx-3d?
Zajec3: AStorm: i don't know it this is agd5f... not airlied?
Zajec3: AStorm: and yes it is going to contain 3D
AStorm: agd5f, definitely.
AStorm: ok, great :)
bridgman: Zajec3; we have a short list of bugs/features to add then we'll probably start looking at a 600g
Zajec3: bridgman: oki
Zajec3: :)
bridgman: basically want to get the classic 600 mesa driver up to roughly the same level as non-kms r300
spstarr: hello bridgman
bridgman: I don't want to be working on 600g until 300g is a bit further along though, don't want to be making the same mistakes in two code bases at the same time
bridgman: hi spstarr
bridgman: if you arranged the sunny weekend, thank you
bridgman: Zajec3; I think the sequence of events will end up something like :
bridgman: do some more work on the shader compiler in classic mesa, eg get it ready for at least basic GLSL and make it shareable with gallium3d like nha did for r300/r300g
bridgman: by that time 6xx/7xx kms/gem/ttm/dri2 should be fetching up in the kernel master and 300g should be far enough along that we know about any obvious things to avoid
bridgman: and somewhere around there seems to be the right time to start building a 600g
bridgman: I don't *think* we learn anything significant by starting 600g any earlier
nha: nods
nha: there are some potential pitfalls, like what I mentioned with ReadPixels reading from the wrong surface earlier
nha: that would be shared between r300g and r600g
bridgman: yep, that's the kind of thing I would like to see fixed in r300g before we start a 600g
bridgman: I'll ask Cooper to add it to his list
nha: also things like texture upload/download, that kind of thing, I guess the difference between r300 and r600 isn't too big in that area
bridgman: Cooper said that the redbook texture tests were working as of yesterday, sounded like that was something recent
rah: what's happening with r6xx/r7xx KMS?
rah: anything?
rah: and also, is there anything noteworthy to be merged into 2.6.32?
Zajec3: bridgman: great explained, tanks
Zajec3: rah: will hit .32 very probably
Zajec3: rah: of course with some bugs on start probbly :)
rah: Zajec3: r6xx/r7xx KMS will hit .32?
nanonyme: Will hit it in staging very probably, that is. ;)
Zajec3: rah: i think agd5f is working on EXA for r67xx KMS
Zajec3: rah: yeah, kms
rah: sweet :)
rah: anything else of interest going in .32?
nanonyme: Very much not far enough to go mainline outside staging yet. ^^
Zajec3: rah: 3D drm for r67xx
rah: ohhh
rah: things are looking up for we r67xx owners :)
Zajec3: quietly hopes sb will port HDMI support from radeonhd to kms
nanonyme: wonders if there'd be any point at all to use radeonhd after that...
Zajec3: nanonyme: of course not... just like using radeon
Zajec3: what part of radeon wil we be using after KMS merger? acceleration? that's all i think
nanonyme: And even that's gonna change when after r600 mm and r690g get done. :3
nanonyme: Erm, r600g even.
rah: what's the "g"? gallium?
nanonyme: Yeah.
bridgman: the thing to remember is that a *lot* of users are on enterprise distros (SLE*, RHEL etc) where the kernel isn't going to change for a year or more
bridgman: there's still a real need for user modesetting drivers
bridgman: but anyone who hangs out on IRC will probably switch to KMS the day it "boots two times out of three" ;)
nanonyme: bridgman: Sounds like a good idea to put a bit of company resources to guarantee userspace modesetting will keep up getting developed then. Might be community attention will shift elsewhere.
bridgman: yep; I think we'll be adding new GPU support to the user modesetting drivers for quite a long time
Zajec3: "boots two times out of three" :D
AStorm: bridgman, 66% is not good enough for me
AStorm: I need at least 95%
nanonyme: :P
AStorm: and hopefully working s2ram
nanonyme: AStorm: How about "for two users out of three"?
bridgman: we're hoping that KMS will make suspend/resume easier to implement reliably
nanonyme: As in, 66% probability it would work for you.
AStorm: if one of those two is me, I'm ok with that ;P
bridgman: ANYWAYS, the point I'm trying to make is that there are a lot of different user communities and some of them will be on user modesetting for quite a long time
bridgman: ;)
nanonyme: bridgman: Point.
bridgman: that's one of the reasons people get crabby about fglrx; most of the target market uses kernels and X servers that we would all call hopelessly obsolete
bridgman: but that's where we have to do a lot of the testing and fixing
bridgman: one of the really nice things about having a separate open source driver is that it can focus much more on the bleeding edge
nanonyme: And it's faster to find out breakages with it since whole kernel compilation would fail if it becomes API-incompatible...
bridgman: yep; there's a lot to be said for continuous integration
bridgman: we do it with fglrx as well but don't always have time to fix breakage when it happens
bridgman: ie breakage resulting from changes in kernel and x server; fixing breakage in our code *is* a top priority
rnoland_: woot, the corruption vdrift is fixed.
MostAwesomeDude: nha: It might placate you to know that my reason for neglecting r300g is guilt over not having a perfectly functioning shatter.
MostAwesomeDude: I'd *really* like to have something to demo at XDC to show that it was worth it to pay me large sums of cash. :3
bridgman: MostAwesomeDude; you're doing the right thing
nha: agreed
MostAwesomeDude: Thanks, guys.
EruditeHermit: MostAwesomeDude: how is shatter coming?
MostAwesomeDude: EruditeHermit: Slowly. I do some stuff, some stupid stuff happens, I get segfaults, then I get headaches.
EruditeHermit: is it the kind of thing that you just sometimes figure out all at once?
MostAwesomeDude: Not really.
MostAwesomeDude: It's the kind of thing where I have this ideal, great algorithm in my head, and X is so full of these little snares and brambles that you can't really do anything elegant.
EruditeHermit: what about writing it the way you want
EruditeHermit: and then fixing X around the edges
EruditeHermit: where it is broken
EruditeHermit: or bugging others to do that for you =p
bridgman: X is big... really big... ;)
MostAwesomeDude: Tried that during the first two months, ended up with a bunch of random things all across the board.
nanonyme: MostAwesomeDude: Where does shatter actually happen in the X server? Is there some discrete components of it that it should go between of?
nanonyme: s/Is/Are/
MostAwesomeDude: nanonyme: Old shatter was its own layer; new shatter is a property of EXA.
nanonyme: MostAwesomeDude: Mmh... Would integrating it into Gallium3D's EXA and redesigning it appropriately to make it fit in make it any easier?
EruditeHermit: bridgman: were you ever able to influence the flash devs?
MostAwesomeDude: nanonyme: No, that's the EXA path.
nanonyme: Meh. :/
MostAwesomeDude: Honestly, having it in its own layer would be fine, if it were possible to have finer-grained control over wrapping.
MostAwesomeDude: But at that point we're back to the "re-write Xserver in Python" discussion.
nanonyme: Redesigning EXA to make it easier is probably out of the question too? ;)
MostAwesomeDude: EXA's not terrible to navigate around in.
MostAwesomeDude: It's just really deep code and I'm really struggling with it for some reason.
nanonyme: Hmm, right.
nanonyme: Well, I guess you know the best.
bridgman: waits for someone to rewrite X as 1100 lines of Perl
bridgman: making it even *harder* to maintain ;)
nanonyme: waits for someone to do a graphics system completely dependent on Gallium3D with Python by tapping into the Gallium3D Python state tracker
bridgman: sounds like a good GSOC project ;)
nanonyme: airlied: Btw, are you gonna push the 3D bits too to Fedora when you push r600 KMS?
nanonyme: (as in, non-KMS 3D DRM)
airlied: nanonyme: thats the plan, not sure about mesa yet
airlied: agd5f: any major objections to cleaning up the r6xx-cs and mergin it to master?
nanonyme: airlied: Imo (not that my opinion probably counts) Mesa isn't that crucial, it's just annoying to continuously jump back and forth between sets of DRM modules.
nanonyme: Mesa is simpler thanks to the separate non-KMS and KMS codepaths you guys wrote...
meoblast001: ok, so i got my radeon drivers to work, but here's the thing
meoblast001: my Xserver Xpoded
meoblast001: Xploded*
meoblast001: is that typical
agd5f: airlied: Should be fine. I was going to ask you the same thing
airlied: agd5f: I'll fix up one or two things in your branch today
airlied: push that to the main repo
airlied: and merge it if it works out
agd5f: airlied: I made sure to keep the non-kms pathes working when I ported it
agd5f: so they still work fine
airlied: cool I think I've got all the kernel code in place, just seeing if I can fix the blit copy path
agd5f: airlied: you see my fix for my old branch? http://cgit.freedesktop.org/~agd5f/drm/commit/?h=r6xx-r7xx-3d&id=9ad1d3deb396b694e00e22019952fd78b0ec45b1
agd5f: I'll port it to kernel tomorrow or the next day
airlied: I pulled that into my tree
meoblast001: has anyone here tried Neverball with an r500?
agd5f: airlied: cool
airlied: just seeing if I can make the kms path work, the benchmark tests hang on a fenec wait
agd5f: airlied: I'm also hitting warnings in mesa about bo idle on kms. ddx may have similar issues
airlied: we should have bo idle support in theory
airlied: ah it needs linus master merged
airlied: so thaty should fix itself
agd5f: perfect
meoblast001: i tested Neverball with my r500 and the xserver went nuts
Kano: hi agd5f
Kano: does anybody know samsung tvs with integrated amd cpu and rs690m chipset?
Kano: there the latest ati git does not work
Kano: samsung 460MXn
airlied: Kano: open a bug with logs is probablty best
Kano: i can not even connect with ssh to it
Kano: it is not my system
airlied: so can you get the log off it at all?
airlied: not really much we can do
Kano: maybe i can get access to it later, just not now
Kano: it is really bad when you see absolutely nothing ;)
airlied: well we need the usual info, logs etc
airlied: they don't ship developers tvs ;-(
Kano: usually it runs with windows xp embedded
airlied: how is the gpu connected to the tv? hdmi?
Kano: was there a script to upload logfiles?
Kano: it is inside the tv ;)
Kano: a script to pastebin files would be good...
Kano: which runs in textmode with easy url
Kano: like for alsa
chithead: wgetpaste
DanaG: pastebinit
Kano: is there a script already prepared?
Kano: best prepare one and put the url in the topic
Kano: please prepare for testing. bye for now
airlied: fedora has nopaste cmdline tool
airlied: not sure what others have
simNIX: hello. I hope this is the right place to ask. I've been puzzling to get dual head configured on a radeon 9600 - I have it almost working correct now; when I move my mouse from the main head to the next I moves to the next. When i try to mouse back to the main head t won't let me. I wonder if this is the corect place to pastebin my xorg.conf in the hope someone here can point me to the error I make in configuring this great driver.
simNIX: *t=it
ssieb: airlied: still around?
airlied: ssieb: yup
airlied: simNIX: what distro/server you using?
airlied: you are probably best just using randr to configure dual-head
airlied: and not multi-screen which it sounds like y ou are eoidng
ssieb: airlied: the latest warzone2100 doesn't work with the radeon driver (at least on my RV515)
ssieb: without kms, it gives me: warzone2100: radeon_common.c:1008: radeon_validate_bo: Assertion `radeon->state.validated_bo_count < 32' failed.
simNIX: ok - thanks for sugestion
ssieb: with kms, there's no 3d view, just the 2d overlays :-)
simNIX: but im already so close so if you don't mind I'll paste wat I have;
simNIX: http://debian.pastebin.com/m232f195c
airlied: simNIX: the mouse going back is a server bug from what I remember
simNIX: asuming Im' close since in essence the had both come online
simNIX: aha
airlied: it not something xorg.conf can fix
simNIX: and one that randr don't havE ?
airlied: most of your xorg.conf is probably not required anymore
simNIX: to try with randr best make empty xorg.conf to start ?
airlied: http://wiki.debian.org/XStrikeForce/HowToRandR12
airlied: you probably need a very minimal xorg.conf with a virtual line in it
simNIX: tnx for info, glad I asked - if a bug can't make it work like I try I could have been puzzling forever - I''l dive into rand
airlied: ssieb: can you file a bug I'll try and reproduce it
ssieb: ok
ssieb: I'll have to install that version again. I reverted it :-)
ssieb: actually, no I don't. I have the information
ssieb: airlied: should I file two bugs or is the bo error just due to not using kms?
ssieb: or just put both cases in the same bug?
airlied: ssieb: I'm hoping we fix one the other works, so one bug for now is fine
ssieb: ok
ssieb: I see there was a kernel 2.6.30 just released. would that make any difference?
ssieb: airlied: have there been any radeon related changes recently?
airlied: ssieb: in mesa yes nothing else sounds like it shuold affect the issue you seen
ssieb: airlied: https://bugzilla.redhat.com/show_bug.cgi?id=521576