Turjakas: is there documentation on how to get 2D acceleration work on R600 with the newest radeon driver?
yangman: Turjakas: http://wiki.x.org/wiki/radeonhd%3Ar6xx_r7xx_branch
yangman: Turjakas: the parts about compiling drm modules is relevant
Turjakas: yangman: ok, thanks... are there any specific requirements for this to work, like kernel version, xorg-server version, mesa version...?
yangman: Turjakas: any recent xorg-server should be fine. no support in mesa yet, so that's not relevant. any recent kernel should be fine as long as the drm modules compile
Turjakas: yangman: to which directory under /lib/modules/ I should copy over the kernel modules ?
Turjakas: or does it even matter...
yangman: depends on the kernel version and distro, but /lib/modules/
yangman: make sure you run depmod after you've copied it
Turjakas: hmm, ok.. I'm running 2.6.26 on Gentoo
yangman: just make sure there's only one copy of the module installed. the path doesn't matter too much
Turjakas: ok :)
Turjakas: WARNING: Error inserting drm (/lib/modules/2.6.26-gentoo-r2/kernel/drivers/gpu/drm/drm.ko): Cannot allocate memory
Turjakas: great :)
Turjakas: I wonder if there is any more detailed information about the error...
mzz: iirc that's the error message you get if you have fglrx loaded
yangman: right. make sure fglrx isn't loaded, and not loaded automatically
mzz: (well, iirc that's the error message someone else got who had fglrx.ko loaded)
Turjakas: oh, you're right, it is there loaded although I'm not even using it
yangman: you'll need to reboot as well
Turjakas: I just did "rmmod fglrx", and it loaded fine
yangman: you'll run into issues when actually running X
yangman: there's no guarantee fglrx initializes the card into a state that the open drivers can handle. it usually doesn't
Turjakas: ok, still one problem, X can't find libdri.so extension now - it's a symlink pointing to a file that doesn't exist
mzz: gentoo? ran "eselect opengl set xorg-x11" recently?
Turjakas: it's the only option
mzz: I seem to be confused
yangman: where is it pointing to?
mzz: on this system /usr/lib/xorg/modules/extensions/libdri.so is an actual file, not a symlink, owned by xorg-server-1.5.3-r5
yangman: it's pointing at the fglrx provided library
yangman: run eselect opengl set xorg-x11 again
Turjakas: which I uninstalled...
Turjakas: it won't restore the file or link
yangman: the file is gone
yangman: you can manually point it at /usr/lib64/opengl/xorg-x11/lib/libGL.so
mzz: err, what?
mzz: point libdri.so at libGL.so?
yangman: oh, sorry, libdri
yangman: er, hold on
mzz: I'm confused because I don't actually have a libdri* below /usr/lib/opengl. It's not managed by eselect opengl here.
yangman: ati-drivers much have done something funky with it
Turjakas: it seems so
yangman: reinstall xorg-server
yangman: that's the safest bet
Turjakas: wow, acceleration seems to work now, thanks a lot!
raevol: :o Turjakas what card
Turjakas: radeon hd 3650
raevol: ah ok
twoerner: airlied: ping
twoerner: airlied: have you seen - i have had a kernel oops after restarting the Xserver and using it
airlied: twoerner: oh please pastebin it, not sure I've seen it
twoerner: airlied: i only got one line - not more.. machine was dead
twoerner: i think i will use a serial console, now
airlied: netconsole also work quite well
airlied: if its reproducible it should be easy to fix.
twoerner: airlied: the machine was completely dead - no ping possible
AStorm: loves the latest improvements
AStorm: now moving windows around doesn't lock up Xv
nanonyme: chuckles at one being able to get 100% CPU usage with fglrx simply by moving a terminal window *slowly* :)
boghog: fglrx for some reason gets slow when I use window borders that have transparency (i.e. rounded borders)
boghog: when i moved to using square window borders it was suddenly a lot smoother/less cpu intensive :D
nanonyme: boghog: Might be my own fault for using X server 1.4 so I'm not really blaming anyone at this point.
soreau: nanonyme: fglrx with X 1.5.x is even worse in my experiences
soreau: Like if you have svideo out plugged in you can forget about starting X
nanonyme: soreau: I hope it'll be better with 1.6 then. :)
soreau: nanonyme: With the regressions in the driver over the last year or so, somehow I doubt it
nanonyme: soreau: Do keep in mind they have also removed a *lot* of the old code, you never know what happens with the next two versions.
soreau: yea you're right I guess, but I'm not rooting for it..
soreau: or counting on it
soreau: roots for team radeon!
nanonyme: I kinda wonder which happens first: open r6xx/r7xx 3D and power management or fglrx with X server 1.6 compatibility.
AStorm: unless there are docs around, the latter
soreau: Has X 1.6 been officially released yet?
AStorm: (at least partial)
AStorm: soreau, sure
raevol: i'm curious about that too
AStorm: is what I'm using right now
nanonyme: soreau: It has quite a while ago.
nanonyme: 1.6.1 is coming out soon, supposedly.
raevol: i think if they can get the open driver into jaunty first that'd speed adoption a lot
AStorm: X.Org X Server 1.6.0
AStorm: Release Date: 2009-2-25
ajax: oh yeah, i should do 1.6.1 shouldn't i.
soreau: raevol: Say what now?
nanonyme: ajax: You should, yeah. ;)
raevol: if they can get 3d support for r600/r700 in the open driver in the next ubuntu before fglrx i bet a lot of people will stick with the open driver
nanonyme: raevol: They can't.
nanonyme: Maybe for 9.10.
raevol: QQ damn
nanonyme: Ubuntu 9.04 was feature frozen last month.
nanonyme: Might even be it's moved to beta by now.
raevol: alpha 6 was a few days ago
pkt: well, there was a request to pull some r600 code a few days ago so it may be possible
pkt: you should look at the ubuntu git tree to be sure
soreau: pkt: What may be possible?
pkt: that they include r600 support
nanonyme: pkt: Request yes but there's no telling whether that was done or not.
pkt: that 's why I recommended looking at their git repo
pkt: that should settle it
AStorm: that, and it's highly unlikely that 3D will be really useful in that timeframe
pkt: well, anything will be better than nothing as long as it isn't crashing all the time
nanonyme: pkt: I'd have serious doubts against them patching their kernels to get the support.
nanonyme: They'd have to use the drm-next kernel tree git branch.
nanonyme: So no, I don't consider r600 support likely to happen.
raevol: has there been any progress with the 3d? last i heard amd was testing it in-house
nanonyme: Still the same afaik.
DanaG: I've heard that Ubuntu is at least going to have the R600 EXA working -- feature-freeze exception granted for that.
raevol: think my card is r700
nanonyme: DanaG: That's kinda surprising given no released Linux kernel supports that.
DanaG: "Users will be fine with losing their most recent changes to preferences if a machine crashes. They will not be fine with losing the entirity of their preferences." -- damn straight. Seems to happen annoyingly often with Firefox on FAT32... it constantly keeps its grubby little hands all over the preferences file, so a system crash _invariably_ corrupts the end of the file... and then fsck TRUNCATES the file to 0 bytes.
DanaG: ... instead of just letting the end be corrupt.
DanaG: Yeah, I've typically had to keep my firefox profile on FAT32 if I wanted it readable and writable from both Linux and Windows.
mharris: DanaG: Linux can read NTFS
mharris: (and write)
raevol: do you use directx applications in windows?
DanaG: And Wine is not an option -- no surround sound.
raevol: but yea, what mharris said
mharris: DanaG: ntfs-3g
raevol: DanaG: was going to suggest virtualbox, but no direct3d in it yet
DanaG: Once either fglrx gets fixed, or radeon gets power-management and 3D, then I should be able to just run those apps in VBox -- once that gets Direct3D..
mharris: Practically all modern Linux distributions have ntfs-3g available, or as a 3rd party addon
DanaG: Wine isn't really a good option -- no surround sound support at all.
raevol: hey look we're in the same boat :D
DanaG: I also had the profile on an SDHC card, but every time I suspended and resumed, the partition table on that card broke.
raevol: i never use suspend, always seems to cause people trouble
nanonyme: I used it back with an nVidia card but haven't used it anymore.
nanonyme: Worked nice with the proprietary drivers there.
raevol: a long time ago i had a computer suspend itself, and then it never woke up, died while suspended
raevol: was a little too eerie for me, no suspend since
boghog: same here raevol
boghog: I'm too scared to try now :D
DanaG: Hmm, with radeon on my new laptop, suspend itself is actually PERFECTLY reliable.
raevol: i'm getting an eeepc 901 soon, might try it on that, no need for it on my desktop though
nanonyme: DanaG: I guess OpenAL plugin to Wine should enable you to use surround sound with it.
nanonyme: (If hardware supports it)
DanaG: Bonus points if you can make it work through PulseAudio -- because I will want it to route through PA.
DanaG: On my old laptop with nvidia, suspend was only ~30% reliable.'
raevol: Wine isn't really a satisfactory solution though, way too many issues
nanonyme: DanaG: ...
DanaG: With VBox, once it gets D3D, I'll just hand the VM the USB sound card. =þ
nanonyme: DanaG: Yeah sure when PA makes a virtual surround-capable sound card.
DanaG: PA does surround fine for mplayer and such.
nanonyme: (Although maybe this would actually really work with PA just with multichannel support)
nanonyme: But yeah, DirectSound3D can be done over OpenAL.
nanonyme: Dunno how trivial getting it to work with PA would be.
cire: Was there a change in xinerama behaviour? Maximizing windows now maximizes them over both screens. (sidux) Did the radeon driver always use xinerama, or did that change?
adamk: cire: What's the output of 'xdpyinfo | grep -i xinerama'?
adamk: cire: Sounds more like your window manager is not xinerama aware.
cire: is the output
cire: my window manager? KWIN?
adamk: Well your server is using the xinerama extension, which is good.
adamk: How about the output of 'xdpyinfo -ext XINERAMA | grep head' ?
cire: head #0: 1280x1024 @ 1280,0
cire: head #1: 1280x1024 @ 0,0
adamk: And it sees two monitors. Yeah, sounds like kwin is being stupid, frankly.
adamk: Have you tried another window manager?
cire: perhaps it could be configured (or misconfigured)
adamk: Well, assuming you are using two 1280x1024 monitors, your X server and radeon driver are handling things properly.
adamk: I'm not aware of a runtime configurable option for kwin.
adamk: There is undoubtedly a compile time option, though.
chithead: cire: normally there is only a compile-time option to enable or disable xinerama
cire: okay, this is not an option ;)
MrCooper: does restarting kwin help?
cire: perhaps KWIN is stupid, so I have to wait for an update
cire: makes me think of those Windows jokes...
cire: but I'll try ;)
MrCooper: apps using Xinerama tend not to check for updates dynamically but only on startup
chithead: cire: you could try kwin --replace
cire: I also found some options in control center "multiple displays": support for window maximization, support for fullscreen on multiple screens
cire: chithead: I'll do so
cire: both didn't help
cire: seems to be a kwin problem (says #sidux)
jcristau: MrCooper: at least metacity checks for ConfigureNotify on the root window iirc
nanonyme: Heh, someone broke Phoronix. :)
bridgman: might have been me; I was trying to post an inline image that sorta showed how all these newfangled things like Gallium3D and KMS fit into the big picture
bridgman: don't see many inline images on Phoronix
michaellarabel: The server problems are being worked on...
bryce: agd5f: thanks for all your help on the r6xx/r7xx support :-)
agd5f: bryce: no problem :)
agd5f: glisse, airlied: is radeon libdrm in modesetting-gem new enough or do I need bits from rawhide?
glisse: agd5f: i think you don't need libdrm-radeon
agd5f: glisse: don't you need it for radeon_rewite with memory manager?
glisse: agd5f: well iirc there is a copy of it in mesa & in ddx
glisse: but things might have change
glisse: we definilty want to share this in the future
agd5f: i thought they used the common one
glisse: at one point it did
glisse: but i think it diverged at some other point
glisse: not yet back to ddx
glisse: so haven't relook to this
AndrewR: glisse, agd5f - does latest drm kernel modules works for you? (after server shutdown, in VGA mode)
glisse: i am not on rawhide
AndrewR: glisse, i mean upstrem as git master (on freedesktop.org)
agd5f: AndrewR: in what sense? are you using fb console on kms? or just regular drm?
AndrewR: agd5f, just regular drm .. i got kernel panic yesterday
AndrewR: but only after return to VGA (text) mode
agd5f: AndrewR: can you pastebin it? what version?
AndrewR: sorry, nothing in logs (i just rever two commits and now it _seems_ to work)
agd5f: AndrewR: what version?
agd5f: drm-next, kernel, fdo drm tree?
AndrewR: 2e2e8575b1ed4703653a72ac2b60b75316c388d7 fdo drm tree
agd5f: also what chip are you using?
AndrewR: but with reverted "Move vblank_init to driver load time." and one related commit. rv280/agp
AndrewR: may be i just need to recompile X and ddx over new drm buts ...
agd5f: AndrewR: no one is maintaining the kernel bits in drm master anymore AFAIK, at least for radeon
agd5f: AndrewR: the latest and greatest is now in drm-next
agd5f: in airlied's tree
AndrewR: agd5f, thanks, will pull this
AndrewR: agd5f, i hope nw kernel will not eat my (xfs,ext3)
agd5f: glisse: libdrm_radeon in modesetting-gem works for mesa and ddx
agd5f: I get a segfault with direct rendering though
agd5f: indirect works great however
glisse: agd5f: would know for sure what is the today mix :)
ossman: is the frontbuffer ever reallocated? or is it allocated to the maximum size and kept that way?
MrCooper: ossman: the latter, the former will be possible with DRI2
ossman: MrCooper, so this is not a limitation in Xorg core, but in the hardware interface portions?
MrCooper: the intel driver already supports it with DRI2
ossman: I'm not really interested in radeon, but if Xorg can do it at all :)
ossman: I'm trying to get Xvnc to do randr
ossman: but everything I look at allocates the FB in the screen init routine, and that's it
rnoland: agd5f: airlied Since I'm talking nouveau PR, I've committed the r6/7xx drm code to both -CURRENT and -STABLE now... if anyone wants to stick a blurb somewhere
agd5f: rnoland: cool. nice work!
rnoland: we are a week from code freeze for 7.2 release i just realized, so... it will ship...
ossman: MrCooper, are you familiar with the details of how to reallocate the framebuffer?
rnoland: agd5f: any guestimate on 3d code?
agd5f: not off hand
rnoland: ok... just wondering...
osiris__: I have problems understanding this whole radeon CS thing. I allocated a bo in VRAM and now I want to read it. I have to play with OUT_BATCH_RELOC, right?
glisse: osiris__: where do you want to read it ?
glisse: reloc are only when doing cmd buffer submission to read it
glisse: simply map the buffer
glisse: and change domain
osiris__: glisse: so I should use OUT_BATCH_RELOC when trying to write bo address to ZB_ZPASS_ADDR?
glisse: e32(PACKET0(ZB_ZPASS_ADDR, 0),e32(0),OUT_BATCH_RELOC(mybuffer)
glisse: though OUT_BATCH_RELOC might work differently haven't checked how it works but should be that way
osiris__: glisse: what's this e32(0) for?
MostAwesomeDude: osiris__: That's the buffer offset.
glisse: osiris__: basicly you write a normal packet and just set offset to 0
glisse: outbacth reloc will emit a packet3nop with reloc information inside
osiris__: I don't get it :/
agd5f: osiris__: you emit the packet as normal followed by a reloc packet with the buffer handle
agd5f: in the drm we parse the command stream and replace the 0 with the actuall address of the buffer
osiris__: aaa, so there's actually no such a thing as reloc packet. we just made it up, right?
agd5f: osiris__: the command streams gets slightly rewritten before submission to the hw
MostAwesomeDude: osiris__: Yep. Basically, there's a bit of dark magic involved with relocs, so just remember "pkt0, offset, reloc".
MostAwesomeDude: Or, in the Gallium code, "reg seq, reloc".
osiris__: MostAwesomeDude: if offset is always 0 when reloc is done, wouldn't it be easier to just do 'pkt0, reloc' and modify OUT_BATCH_RELOC accordingly?
MostAwesomeDude: osiris__: It's not always 0, though.
MostAwesomeDude: For example, for OQ, you'll probably want to go through and set a different offset for each pipe in SU_REG_DEST.
MostAwesomeDude: It's just usually 0.
nanonyme: MostAwesomeDude: Btw, is there some limitation for what the next valid value after 0 is?
MostAwesomeDude: nanonyme: Since the offset's measured in bytes, you can put just about anything, but some situations have practical limitations.
MostAwesomeDude: For textures, for example, you almost definitely want multiples of 32.
MostAwesomeDude: But for OQ, we probably just want uint32, so multiples of 4.
nanonyme: Hmm, seems currently the only git tree whose progress I'm monitoring that's actually changing fast is the Mesa one. ^^
MostAwesomeDude: That's because I write code with all the speed and accuracy of a ferret on meth. :3
osiris__: what is the meaning of read and write domains params in OUT_BATCH_RELOC?
nanonyme: MostAwesomeDude: Well, you're not the only one there though although you do generate a pretty awesome amount of commits. :)
MostAwesomeDude: nanonyme: Look at the ohloh for Mesa. brianp's got us all beat.
osiris__: and why there is data param if it's unused?
MostAwesomeDude: osiris__: The unused param is for doing stuff like tiling later IIRC.
MostAwesomeDude: And you probably want read and write of RADEON_GEM_DOMAIN_GTT I think.
adamk: airlied, Tried the latest updates from today (kernel, various xorg components) and I do still get the completely system lock up when I run glxgears.
AStorm: nanonyme, drm-next is moving too, but not really too fast
AStorm: MostAwesomeDude, so, when we'll have 3D running? ;) (since you mentioned your speed)
airlied: adamk: wierd, AGP?
airlied: excuse me for asking again, I always forget what hw ppl have :)
AStorm: that reminded me to try latest mesa ;>
airlied: agd5f: radeon-rewrite has a copy of radeon_bo.[ch] in it
agd5f: airlied: ah ok
AStorm: btw, you guys could add my card to the device ID database finally
AStorm: the warning is unnecessary ;>
airlied: I didn't think adding a depend on libdrm-radeon for the people using legacy only was necessary
airlied: osiris__: if the operation reads from a buffer you need to set the read domains to a valid list of domains to read from
airlied: if the operation writes to the buffer you need to set a single write domain to but the buffer in for writing.
osiris__: airlied: so for occlusion queries where the GPU will only be writing data I should set rd = 0 and wd = RADEON_GEM_DOMAIN_VRAM or RADEON_GEM_DOMAIN_GTT?
airlied: osiris__: yes
airlied: I'm guessing _GTT is probably what you wantr
spstarr_work: we really, do, love AGP ;-)
adamk: airlied, PCIe.
adamk: airlied, I tested yesterday with both an x850 and an x1950. Today just the x1950.
glisse: hates fence
osiris__: how can I make GPU write some value to some gart memory so that I know that rendering is finished?
airlied: osiris__: we already have that just wait rendering on the buffer
airlied: if you emitted the buffer already, the fencing takes care of it
airlied: mapping the buffer should block
osiris__: airlied: but I don't want to block, just poll
airlied: osiris__: how can you poll? we have no polling interface in mesa
osiris__: airlied: there is one for occlusion queries
airlied: oh nice, just map the buffer, check the value, unmap
glisse: airlied: doesn't map block if bo active ?
airlied: glisse: I don't think anyone will notice :)
airlied: maybe we need a busy query from bufmgr
glisse: sounds like a good idea
glisse: zzzZZZzzz more ttm debugging tomorrow
osiris__: airlied: if I had allocated new bo in gtt/vram and used it in out_batch_reloc the bo mapping will block until the rendering is finished?
airlied: osiris__: until the cmdbuf referencing it has been processed
airlied: if OQ is async it shouldn't block
airlied: well it will block but only un til the cmdbuf is processed
airlied: not until the OQ result arrives
osiris__: airlied: there're two interfaces sync and async
airlied: so if the CP blocks the map will block
airlied: if the CP doesn't block it should all work.
adamk_: airlied: Not sure if it sheds any light, but here's an Xorg.0.log file from before the lockup: http://pastebin.com/m47fa8b7a
adamk_: And apparently it's an x1900 not an x1950 like I originally said.
airlied: adamk_: wierd I'll try take a look later
adamk_: No problem. Take your time.
osiris__: could anyone check this out http://paste2.org/p/166592
osiris__: this is occlusion query support
osiris__: it doesn't work, I just want to now if the way it is done now is correct
osiris__: airlied: it's complaining about CS section size mismatch. how it should be calculated?
airlied: osiris__: add 2 for each reloc most likely is missin
airlied: so I think try 9 or 11 for that QueryEnd.
airlied: I should document that better.
osiris__: airlied: what about regval?
airlied: you should probably alloc the BO in NewQueryObject
airlied: its in qwords from memory
airlied: so 1 per regval line
osiris__: it's complaining '1 vs 2'
airlied: oh wait I might be confusing with ddx lemmee go check
airlied: oh then regval should be 2
osiris__: airlied: when I try to run an app that outputs some text under gdb the program breaks on SIGTTOU
osiris__: airlied: then I try to disable handling this signal (handle SIGTTOU noprint nostop) and the gdb eats all cpu and nothing happens
osiris__: any idea?
airlied: something is backgrounding it
airlied: not sure why gdb throws up though
DanaG: Oh yeah, I tried the new X server on an X300 SE... and oddly enough, it was slow as all hell with compiz -- until I triggered the 'benchmark' plugin.
DanaG: I mean, I'd expect slow as in, say, 15 fps... but on this thing, opening gnome-terminal dropped it to more like 2 FPS.
osiris__: airlied: now it segfaults on cs->packets[cs->cdw++] = dword; at ../radeon/radeon_cs_drm.h:192
osiris__: so probably I'm calculating batch size wrong still
airlied: osiris__: so 2 for REGSEQ, 2 for RELOC, 2 for REGVAL
airlied: hmm that could be lies, I suck
osiris__: airlied: still the same segfault
airlied: so REGSEQ should be 1
airlied: REGVAL, and RELOC are 2
osiris__: airlied: that's how it was before
airlied: well your qurery begin should be 2
airlied: as its a REFVAL
osiris__: but it's the query end that is segfaulting
airlied: quey end should be 12
osiris__: airlied: it segfaults with 12 (regseq 1) and 14 (regseq 2)
airlied: okay a reloc is 3 I mis counted.
airlied: so 14 is correct
airlied: regseq 1, regval 2, reloc 3
osiris__: airlied: OUT_BATCH_RELOC seems to be the problem, commenting these makes the prog not segfault just complain about incorrect batch size
airlied: osiris__: are you on KMS enabled or not?
airlied: so is cs->cdw gone off the end, which shouldn't happen
osiris__: airlied: yes, but I think the gdb is printing wrong line numbers because of macros and the actual bug is in null ptr deref
osiris__: in query->offset
airlied: that would make more sense
airlied: if query isn't valid
osiris__: yeap, that's the problem
osiris__: airlied: what about the rest of the code, does it look good?
airlied: looks good, you might make the query object radeon generic btw
airlied: I think r100/r200 can support OQ
airlied: at least I see ZPASS addr/data
airlied: on r200 at least
osiris__: airlied: here's corrected one http://paste2.org/p/166611 now it exits with drmRadeonCmdBuffer: -22
osiris__: airlied: never mind. looks like I need to add 0x4f58 to some safe reg list in drm
spstarr: airlied: tackling AGP this week? :)
osiris__: or not
osiris__: or yes :)
spstarr: looks at cgit
spstarr: no changes
spstarr: new ddx
lymeca: All of the next-gen features I keep hearing about such as DRI2, GEM, KMS, and the Gallium3d arch, are all of these pretty much happening at the same time? Are they all intrinsically connected?
spstarr: some are, some not
MostAwesomeDude: lymeca: Yes and no.
MostAwesomeDude: GEM, KMS, DRI2 are roughly linked.
MostAwesomeDude: Gallium code requires all three of the above.
lymeca: MostAwesomeDude: I see, so the wait for the gallium switch is depending on the other three to be properly implemented?
lymeca: Will this be done generation-by-generation?
lymeca: Like, will r300-r500 be gallium before r600 and r700?
lymeca: And will r100 and r200 ever be using gallium?
MostAwesomeDude: One sec, eating. :3
MostAwesomeDude: First: The big switchover will be on a per-distro basis, probably, and depends on whether or not it's "worth it" for them. So, right now, the only reason to switch is to get at nouveau, which is still experimental. When all drivers get more stable, the switch will happen naturally.
MostAwesomeDude: Then: r300 will probably be done before r600 is done, but that's only because it has a head start.
MostAwesomeDude: Finally: r100 and r200 lack shaders, so they can't use most of the Gallium features, but marcheu's got a plan for still supporting them somehow. I don't really know how or why, though.
lymeca: So, mesa OpenGL and gallium cannot coexist with a distro?
MostAwesomeDude: Mm, they probably could. It's more of a distro problem.
lymeca: Well, if they couldn't, wouldn't we have to wait for the nvidia driver and fglrx to move to gallium before they would commit to moving to gallium?
MostAwesomeDude: nvidia doesn't use the DRI structure at all.
MostAwesomeDude: fglrx has its own libGL stack, so it doesn't interact with Mesa/Gallium at all.
airlied: its just a dri driver so you can pick gallium/non-gallium easily
MostAwesomeDude: airlied: Right. In theory we could have the DDX choose between radeon_dri.so and r300_dri.so from xorg.conf configuration.
airlied: MostAwesomeDude: no need
MostAwesomeDude: Is there some kind of autodetect I'm not aware of?
airlied: shipping two drivers is pointless
airlied: you ship one r300_dri.so
MostAwesomeDude: So it becomes a distro problem.
airlied: if that is the gallium one or not the gallium one should be up to the packaging.
airlied: otherwise people won't ever report bugs in one they'll just switch to the other
MostAwesomeDude: airlied: Except for nouveau. :3
MostAwesomeDude: Unless they keep using nvidia.
mjg59: nouveau-by-default makes running nvidia pleasingly awkward
spstarr: MostAwesomeDude: how goes your gallium work
DanaG: heh, tried the new fglrx... but had to go back to radeon. Same issue as always -- I won't bother re-linking.
DanaG: At least the things radeon does do, it does nicely -- and the number of things it does do is generally steadily increasing.
spstarr: patience ;p
DanaG: visitor: what the heck kind of question was that?
DanaG: Yeah, I know said 'visitor' already left.
MostAwesomeDude: spstarr: It's getting there.
MostAwesomeDude: Slowly but surely.
spstarr: you have it using so hardware for some rendering + swraster?
MostAwesomeDude: Well, it works perfectly, except for a few bugs.
spstarr: you finished hw accel?!
DanaG: I ran into some really weird behavior with compiz on an X300SE today.
MostAwesomeDude: spstarr: Yep.
MostAwesomeDude: But there's some bugs.
spstarr: you are MAD ;)
MostAwesomeDude: glxgears doesn't work.
DanaG: Namely, it was laggy as all hell... until I triggered the 'benchmark' plugin.
MostAwesomeDude: Anything that doesn't have at least one color hardlocks the card.
MostAwesomeDude: r300 doesn't draw things right.
MostAwesomeDude: Fragment shader is missing a few instructions.
DanaG: ... and if I opened gnome-terminal, it went back to about 1.5 fps.
MostAwesomeDude: Textures don't always draw.
MostAwesomeDude: surface_copy always falls back.
spstarr: MostAwesomeDude: so you mean, you have the basic accel working but just the baseline framework
mzz: heh, "a few bugs" he says
DanaG: Aah, perhaps that was part of it... the windows were partly empty.
MostAwesomeDude: Yep, just a few bugs. :3
spstarr: MostAwesomeDude: 'bugs'
MostAwesomeDude: Well, I think they're bugs, at least.
MostAwesomeDude: The only true feature missing is HW TCL for the cards that support it.
DanaG: I do find it odd that "benchmark" made it go back to being not laggy. =þ
DanaG: It reminds me of Schröedinger's Cat.
airlied: MostAwesomeDude: those trivial vertex shaders :)
MostAwesomeDude: airlied: Yep.
MostAwesomeDude: In all seriousness, HW TCL is a rather non-trivial piece of code to integrate on top of the SW TCL. :c
airlied: how isthe r300 frag shader treating you?
airlied: figure out the texture indirects yet :)
MostAwesomeDude: Haven't started on r300 yet. Not looking forward to it.