Nightwulf|work: hi all
shadow98: hey guys i have a old radeon x350 xt that i tried to get to work on ubuntu with no luck
shadow98: r there plans to have driver support in X.org in the next release
shadow98: i also have dual monitors..
shadow98: tried install with envyng, from latest download at ati
shadow98: no luck
taiu: shadow98: EnvyNG: Interface for the installation of ATI/NVIDIA proprietary drivers - see channel the topic
shadow98: well i tried ever solution
shadow98: fglrx as well
shadow98: this is on ubuntu 9.04
shadow98: something to do with the new X
simplexe: shadow98: for fglrx use #ati
MostAwesomeDude: shadow98: Your card is no longer supported with fglrx. You should just use the open drivers.
vehemens: agd5f: putting a udelay(1000) after r700WaitForIdleClean in r700RunRender gets rid of my engine rendering problems
glisse: vehemens: this is not a fix but a hack
vehemens: better a hack then nothing :>
vehemens: glisse: how about a wait for idle test?
glisse: vehemens: i didn't follow what your problem was
glisse: just that adding udelay is clearly a hack
glisse: and WaitForIdleClean should do the wait and return once it's safe
benh: glisse: maybe it's a red herring
vehemens: well i think as least one of the issues is that it's returning before it's safe
benh: glisse: ie, missing a cache flush and the delay helps here ?
benh: glisse: ie, it's idle ... but you need also some flushing somewhere that isn't done ?
glisse: benh: maybe, on r6xx you need to explicitly flush and engine can't report idle without a flush iirc
benh: heh, I don't know, just an idea :-)
glisse: vehemens: what is the problem ? i think opening bug is better so you don't have to repeat yourself
vehemens: some of the 3d demos render corrupted images. also compiz corrupts pull done menus among other issues. my understanding is that everybody is having these problems.
glisse: yeah got them too
adamk: rnoland, vehemens: Do either of you remember if r500 support was in the freebsd kernel for the 7.2 release?
vehemens: adamk: don't remember. suggest comparing the drm code from release with stable. also the ports bits may of been a bit stale at release time.
adamk: Yeah. I remember that r500 drm was added to -STABLE shortly after some release, but can't remember if it was 7.1 or 7.2. Not that it really matters now. Just trying to remember :-)
rnoland: adamk: yes 7.2 has r600
rnoland: 7.2 ports were also fresh
rnoland: 8.0 is most likely going to ship with what we have now...
rnoland: i don't have time to update and test at the moment....
vehemens: benh: the r700WaitForIdleClean has a flush. i also expected a check that the flush/idle had completed, but i haven't seen one yet.
rnoland: vehemens: i have all of alexs changes in my current tree if you want a new patch...
rnoland: getting 2100fps in gears on hd4650
vehemens: what's the path?
suokko: Is it known bug that dri1 r300 mesa 7.6 can cause system hang in swapbuffers? Now it was first time that I could get backtrace http://nopaste.com/p/ay19o50Sl
suokko: drm modules are from Ubuntu 2.6.28 kernel so there might be bug
nanonyme: Could try with stock 2.6.31 with KMS disabled?
nanonyme: suokko: Do you expect similar to be possible with r600?
suokko: I don't know if they are using same bufferswap path
nanonyme: It varies in kernelspace anyway.
suokko: But I will try new kernel if I get permission to compile it
nanonyme: Whose computer is it? ^^
nanonyme: But yeah, I was under the impression the bufferswap path in userspace should be pretty much the same.
adamk: rnoland_: Though I won't be able to try it till Monday, I did grab your latest patch that you mentioned above so that I could get the kernel compiled today, but the kernel build is dying: http://pastebin.com/m23115da7
rnoland_: hrm, wtf...
rnoland_: i'm running it now...
adamk: All I did was csup to the latest -CURRENT, apply your patch from /usr/src with -p1 , and make buildkernel with my config.
adamk: Running the kernel now?
adamk: Let me try again.
rnoland_: adamk: did you remove any previous patches?
adamk_: I did the csup... Shouldn't that overwrite the previously patched files?
airlied: suokko: thats just a gpu crash
airlied: it probably crased earlier
rnoland_: it will overwrite existing files... but new files will get screwed
rnoland_: you need to delete r600_blit.c at least
rnoland_: probably radeon_cs.c as well
adamk: Ahhh. Cool. I'll kill the dev/drm directory and csup again.
rnoland_: looks like those are the 2 new files, so those should do it.
suokko: airlied: Do you think register dump might help? Or some debug output or patch?
osiris_: this vertex splitting problem is getting on my nerves
osiris_: I'm trying to push few packet3 draw commands in one CS, but it keeps locking the GPU
g-zu: I'm afraid you won't have much luck with that
g-zu: at least not on r500
airlied: suokko: with kms we have more debugging in the kernel for tracking that storta thing down
airlied: with non-kms its a bit of a pain
airlied: you havee to dump the cmdfifo/ring/ib
airlied: avivotool has cmdfifo dumper in it
airlied: osiris_: vertex fetcher is always a bit fragile
airlied: if you are using dri2 debugfs has some lockup debugging stuff if the machine doesn't die
osiris_: airlied: fortunately GPU reset is working
suokko: r300 shader compiler has debug output that is not going to stderr
g-zu: wow, this dri2 and kms really brings a lot of new stuff to help developers
g-zu: I really wish you the best of luck with making that work osiris
osiris_: g-zu: thanks, I've already spent too much time on this, and if I won't finish it today, I'll probably give up
g-zu: please don't
g-zu: I tried something like that for a week without results
g-zu: at least prove to me that I'm incapable of doing such as seemingly easy task
osiris_: g-zu: what were you trying to do?
glisse: osiris_: do you have an ib dump of such stream ?
osiris_: glisse: nope
glisse: with /sys/ debugfs it's easy to get ib dump
g-zu: merge multiple packet 3 commands in a cs, as you said you are trying
glisse: osiris_: i could take a look and see if i spot anythings needed
glisse: strangely i think i still remember enought what fglrx does to spot things that might be missing...
osiris_: glisse: take a look at this patch http://pastebin.com/m704b1f44
osiris_: glisse: if I won't add the offset in line 128 it will work
osiris_: (but rendering will be broken)
osiris_: g-zu: I'm not trying to merge packets, I want to put few draw packets to be able to workaround hw limits (max 65535 vertices/elements in one draw operation)
g-zu: oh, well, good luck anyway
glisse: index buffer has restriction on offset
glisse: alignment needs
glisse: could be that
osiris_: glisse: hmm, but that is just source pointer, destination ptr is always R300_VAP_PORT_IDX0
glisse: it's the cp which as the restriction
glisse: indxbuf packet let the cp fetch from memory and write it to the proper register
glisse: but cp fetcher as restriction on memory address
glisse: we might not check all of them in the kernel
osiris_: glisse: do you remember the alignment value?
glisse: so first 2 bits must be 0
glisse: dwords alignment
osiris_: glisse: 31:2??
osiris_: aah, ok
glisse: osiris_: with ib dump i can spot other things
osiris_: glisse: how do I get an ib dump?
suokko: osiris_: cat /sys/kernel/debug/dri/0/radeon_ib*
suokko: assuming that debugfs is mounted to /sys/kernel/debug
osiris_: but how will I know that the ib is the one that caused the hang?
glisse: osiris_: there is other sysfs files which can tell you what was the lastest ib scheduled
glisse: but it's not necesarily the faulty ib
suokko: r100_cp_csq_fifo is giving current fifo state I think
osiris_: glisse: so it is kinda useless for my case
glisse: suokko: this one is dump of the cp fifo
glisse: osiris_: not useless really looking at ib could be usefull to see if the kernel properly rewrote the packet
suokko: There is indirect1 and indirect2 too. What they are then?
glisse: indirect1 is for ib, indirect2 is for ib2
glisse: csq is the ring
suokko: ouh. I forgot that might be alredy new ib attached there
osiris_: glisse: how do I do that since radeon_ib will contain another ib (most probably from EXA)?
glisse: osiris_: it will likely be the bigger i usualy dump all ib and then look for somethings that exa don't do
glisse: so i know if an ib is an X ib or a mesa ib
glisse: for instance X don't do INDX_BUFFER
osiris_: glisse: I'm giving up on vertex splitting. I'd like to push VBOs finally and the splitting is stopping me
glisse: i will take a look next week
glisse: i am myself fighting with r6xx accel
nanonyme: Probably am to assume you imply in KMS-land? ^^
glisse: yup kms
osiris_: glisse: there's just one problem with VBO. when we have more then 65535 verts to render we won't emit the draw packets (skip this render operation)
osiris_: it works fine unless indices are not in named buffer object
osiris_: I've no idea why, if I always copy indices to bo got from radeonAllocDmaRegion it works ok, but when I use the bo from gl named buf_obj it hangs the GPU
osiris_: any ideas what could be the problem?
glisse: osiris_: the gl buffer is a valid bo ?
glisse: the gl buffer is in vram ?
glisse: i think it's better to not have vbo/indx in vram
osiris_: glisse: vertex data are always in GART
glisse: well it depends how the vbo call which allocate the bo picks
glisse: the AllocDmaRegion ask for gtt
mcgreg: weeee just installerd my new asus mainboard with a new phenom2 x4 955 :D and it works greats :)
osiris_: glisse: no, currently all bo's that are used for named buffer objects have hard coded domain - GTT
glisse: osiris_: anyway first thing i can think of is bo in vram, invalid bo supplied by mesa
mcgreg: hmm cool. with the old drm code I got ~670fps. bnow I get 3200fps with glxgears :)
mcgreg: lets test google earth - whoch works just great btw :)
nanonyme: Which chipset family was this again?
osiris_: glisse: and the GPU hangs only when I want to skip the rendering operation (because of 65535 limit)
osiris_: so the indices in named buf obj work in general
glisse: osiris_: everythings is in the branch ?
mcgreg: nanonyme: latest. AM3. it is 4x 3.2ghz :D 2mb L2 cache 6MB L3 cache :)
nanonyme: mcgreg: I meant GPU.
mcgreg: compiling drm modules is a matter of seconds :)
mcgreg: nanonyme: sry :) RV730 / radeon 4670
nanonyme: That's fast then.
glisse: osiris_: when you split you also change the size right ?
osiris_: glisse: yes, plus this patch to skip too big rendering operations http://pastebin.com/m58c787c5
glisse: ie each splited chunk has a valid size which is a multiples of numvertperprimitive
osiris_: glisse: no, I don't split anymore
osiris_: glisse: I just skip the rendering operation
glisse: what you mean by skip ?
mcgreg: nanonyme: unfortunately quake3 is not yet really working fine. neither is alien arena or nexuis. but it's coming :D
osiris_: glisse: return at the beginning of r300RunRenderPrimitive so no draw packets are send
nanonyme: mcgreg: Geometric corruption issues, right?
osiris_: that's how it has worked before we were using vbo_split_prims
glisse: osiris_: so this patch http://pastebin.com/m704b1f44 is too split rendering into multiple drawpacket right ?
nanonyme: mcgreg: Google Earth doesn't appear to work for me. :/
nanonyme: Hope it's not r600 vs r700 differences again.
osiris_: glisse: yes, but I gave up splitting for now. I just want to push VBOs for now
glisse: the splitting looks wrong
glisse: what is incr supposed to be ?
glisse: nr needs to be a multiple of numvertexperprimitive
glisse: otherwise it will hang
osiris_: glisse: forget the splitting
osiris_: I'm removing this code for now
glisse: osiris_: we can't accept to drop rendering if vbo is too big :)
osiris_: I will skip the rendering operation that are too big too handle without splitting
osiris_: glisse: it isn't too big vbo, it's too big vertices/elements in one render operation
glisse: osiris_: i think we are confusing each others words here
osiris_: glisse: ok, lets start from the beginning
glisse: if gl prog ask to render more than 65536 vertex with a vbo you drop the rendering ?
glisse: ie you don't do it
boghog: not sure if anyone here knows this, but I built a server with AMD 780G igp, does radeonfb support this gpu?
osiris_: yes (and that's what we used to do for few years until I added the vbo_split_prims call - which proved to be bogus in some cases)
osiris_: glisse: and it doesn't matter it we render from vbos or not
glisse: yeah mesa convert everythings to vbo
osiris_: glisse: not everything
osiris_: glisse: anyway, when index buffer is in vbo and I want to skip rendering because of 65535 limit I get GPU hang
glisse: osiris_: this is because your nr computation http://pastebin.com/m704b1f44 line 162 is wrong
osiris_: glisse: I can work around this by copying indices from vbo to memory allocated by radeonAllocDmaRegion
nanonyme: boghog: Do you need X? :3
glisse: as i said nr must obey: nr = n * numvertexperprimitive
boghog: no, just a server, i want to give it a higher res if I ever need to use the console
osiris_: glisse: you still don't get me.
glisse: where n is an integer
nanonyme: boghog: I'd go for radeondrmfb instead then.
nanonyme: No radeonfb.
osiris_: glisse: I'm done with vertex splitting, forget the http://pastebin.com/m704b1f44 patch, look at http://pastebin.com/m58c787c5
boghog: oh, is that in stock kernel? because I haven't seen it
boghog: ah, running .30
boghog: guess I could run latest 31 rc
nanonyme: And in staging even there.
nanonyme: Or wait.
glisse: osiris_: what's wrong with that patch ? http://pastebin.com/m58c787c5
boghog: hrm, I guess I can do with vesafb for now though, if it can do 1024x768 i will be happy
kkk: I don't remember wheter radeon supports s-video or vga port
nanonyme: glisse: Is it only in Rawhide or is it already merged into main tree? (as in basic KMS)
nanonyme: boghog: Yeah, maybe.
glisse: nanonyme: what ?
glisse: r6xx kms ?
glisse: it's only on my computer
nanonyme: For console, no X support.
glisse: for console it's at people.freedesktop.org/~glisse/kms
nanonyme: boghog: Would want a high-resolution server console, asking whether it works.
boghog: oh sweet, i just got 1400x1050 with vesafb :p
nanonyme: And my subconsciousness is weird, it automatically put in a capital letter there because there was ": " before it.
boghog: ah I'll check that out
boghog: since vesafb is slow, dmesg takes 25 seconds :P
glisse: osiris_: got to go bbl, i still don't get why you want to drop splitting big rendering into smaller chunk, it should work, i will look into that next week or latter today if i get bore of r6xx
osiris_: glisse: there's nothing wrong with that patch, except that skipping rendering operation when indices are in VBO results in GPU hang
osiris_: glisse: because I want to VBOs as soon as possible, and vertex splitting is holding it back
osiris_: glisse: and there are cases where we would have to rewrite index buffer (or create it) (e.g. for triangle fans)
glisse: for hang when you skip reason is likely that some drawpacket get emited in one the path and so gpu wait for index or vertex and never see them coming
glisse: and thus hang
osiris_: glisse: no, that's not it, because when I will copy data from ind buf VBO to bo allocated by radeonAllocDmaRegion and used this bo for rendering it doesn't hand
netbie: where report my problem in bugs.freedesktop.org?
netbie: What section?
netbie: Dri problem with radeon new driver
netbie: Xorg or Dri?
suokko: grrr, Your mailing list, mesa3d-dev, appears to be either not archived yet, or has had no e-mails sent to it. If it is a new list, please wait 2-4 hours after the first message is sent for the archive to show up.
nanonyme: What kind of a problem is it?
suokko: dri enabled freezes his computer
nanonyme: suokko: No, I meant netbie.
suokko: I think that was his problem ;)
nanonyme: Right. :3
osiris_: netbie: Mesa/drivers/dri/r300
suokko: netbie: I think xorg, xf86-videot-ati component shoudl work
suokko: osiris_: hang happens without any ogl running if I understood correctly
osiris_: netbie: assuming it's the problem with 3d
nanonyme: suokko: Hmm, that "turn dri on and X doesn't start" issue?
osiris_: suokko: no, ut2004 is trying to render from index buffer of about ~90k elements (among others) and when I try to skip those big render operations the GPU hangs
suokko: I'm not able to write what I try to say :/
taiu: osiris_: maybe r300RunRenderPrimitive is a bit too late it emits all kind of state before that and maybe smth does'nt like to be emitted twice
taiu: osiris_: maybe try returning earlier
osiris_: taiu: no it's not too late, because it hangs only if index buffer is using VBO
suokko: I'm suspecting one of my mails did not ever arrive to mesa list :/
nanonyme: suokko: Maybe some spam assassin attacked you?
suokko: sf mail archive is broken so can't check from there
suokko: Found it from marc.info. Gmane didn't list my mail for some reason
taiu: osiris_: bo_offset is in bytes or dwords?
osiris_: taiu: bytes
taiu: osiris_: you don't have to offset index buffer by index size?
netbie: Radeon 9200 use r300 chipset?
otaylor: netbie: no, it's a r200
glisse: osiris_: where is the vbo branch ?
glisse: osiris_: so it lockups as soon as you try to render from vbo index no matter the 65536 limit ?
netbie: problem reported
osiris_: glisse: nope, in general rendering from indices in VBO works.
osiris_: it's the case when I want to skip rendering operation because of 65535 limit while the indices are in the VBO causes the GPU hang
glisse: so when you return in r300RunRenderPrimitive
glisse: osiris_: any of the mesa demo use more then 65536 ?
osiris_: glisse: nope
glisse: osiris_: anythings needed to active vbo in your branch ?
osiris_: glisse: nope
agd5f: vehemens: r700WaitForIdleClean doesn't actually wait for the GPU to be idle, it just queues a cache flush and wait for idle int he command buffer. it doesn't get executed until the CP actually consumes the packet
glisse: oddly it's failing allocating 3M buffer in gtt
osiris_: glisse: 3M buffer for vertex attributes or indices?
glisse: for indices
osiris_: glisse: how did you check it out?
glisse: kernel log throw faillure
glisse: but you don't check in the code if bo alloc succeed or not
glisse: what puzzle me is the i got 512M of gtt
glisse: and nothings is running
osiris_: glisse: I've pushed cleaned up vbo branch with disabled vertex splitting, and no VBOs for index buffer (ut2004 is working now). will do some more testing and probably push in the evening
mesa_booger: hi again guys. i did drm, macros & xf86-video-ati from git master. how do i get dri2 going ? r500 chipset, xorg 1.6.3
glisse: mesa_booger: need kernel with kms enabled
glisse: osiris_: that sucks to not have vbo for indices
osiris_: glisse: actually I didn't see any performance difference in 3 games I've tested
osiris_: sauerbraten, ut2004 and painkiller
g-zu: osiris_: still on your branch?
osiris_: glisse: anyway, adding VBOs for indices is trivial now - the problem is resolving this GPU hang with indices in VBO
mesa_booger: glisse: ok. i did the drm kernel modules too, but on 2.6.30 debian unstable. do i need to upgrade kernel to 2.6.31 rc6 or whatever, or have i already got the right bits with radeon & drm modules ?
osiris_: g-zu: yes
osiris_: g-zu: I hope to push to mesa/master today evening
g-zu: is this for dri2?
glisse: osiris_: you don't hit the checker ?
osiris_: glisse: nope
glisse: here i got invalid cs with a big vbo
glisse: for indices
osiris_: glisse: at least not on my vbo + http://pastebin.com/m58c787c5 patch, or my vbo_clean branch
g-zu: osiris_: radeon_common.c:973: error: too many arguments to function 'radeon_cs_space_check'
g-zu: what do I need?
g-zu: updated I mean
osiris_: last time I asked for my vbo branch testing, few volunteers came up, but I don't remember you (testers) giving me any reports. could you retest it with vbo_clean branch?
osiris_: g-zu: hmm, maybe it's the libdrm_radeon vs no libdrm_radeon case
osiris_: one moment
g-zu: I couldn't test it, people were here and the pc which has an r300 in it was busy all the time
nanonyme: libdrm_radeon too old
g-zu: ok, so I finally got my answer about dri2
glisse: osiris_: i think you should try the following setup small vertexbuffer and big index buffer
glisse: keep being rejected with this test case
osiris_: glisse: what app gives you such testcase?
glisse: i hacked trivial/vbo-drawelements
g-zu: do I need --enable-gallium-radeon?
osiris_: g-zu: nope
osiris_: g-zu: just compile libdrm with --enable-radeon-experimental-api
nanonyme: Damn slow cell phone.
osiris_: glisse: could you pastebin me the patch?
g-zu: I was asking about gallium in mesa but yeah, ok, I'll do that
g-zu: drm from master right?
osiris_: g-zu: yes
g-zu: not any branches
glisse: osiris_: http://people.freedesktop.org/~glisse/drawbigindex.patch
g-zu: 80000, wow, that's some test :D
osiris_: glisse: on what branch you've tested it?
glisse: your old branch
osiris_: glisse: works for me
osiris_: glisse: aah, sorry. looks like I've pushed my latest vbo branch
glisse: vbo_clean doesn't work neither
osiris_: glisse: I've just checked the my vbo branch from upstream before the update (latest patch "fix for stride = 0) and it still works
osiris_: glisse: maybe we have different radeon drm modules
osiris_: mine is from 2.6.31-rc5
glisse: shouldn't matter no change want in the checker lately
glisse: commit 7124598a7034011da1c04ca64624d31867381fa3
glisse: Author: Maciej Cencora
glisse: Date: Mon Aug 10 22:10:47 2009 +0200
glisse: r300: use ADD_POINTERS macro where possible
glisse: this is my lastest patch on your branch and still doesn't work with my modified vbo-drawelements
osiris_: glisse: it works for me
glisse: what gpu ?
osiris_: libdrm maybe?
osiris_: mine libdrm head is "libdrm_radeon: add tiling support"
g-zu: osiris_: do I need kms to test your code?
osiris_: g-zu: no
osiris_: g-zu: should work with and without kms
g-zu: I see, I guess I have to update the video driver or something
glisse: osiris_: did you rebuild the demo i don't see why it wouldn;t work for me i just double checked that it used proper everythings
osiris_: glisse: I'm just doing clean mesa build to double check
glisse: osiris_: you are with kms enabled right ?
g-zu: what do I need to update if I get this? http://pastebin.ca/1529593
osiris_: glisse: still works
glisse: non dri2 doesn't work with this modified demo
osiris_: g-zu: what app are you trying to run?
osiris_: glisse: will try non kms now
g-zu: pretty much everything that tries to run fullscree
g-zu: warsow, openarena
g-zu: the mode is diferent but the error looks the same
g-zu: btw the mode does actually get set
glisse: osiris_: make from mesa root directory doesn't rebuild demos
g-zu: it just returns failure
glisse: also i think that this demo likely won't work on current master anyway
g-zu: on openarena (I ran it windowed) I can't see the menu
g-zu: console works though, I'll rebuild xorg-server see if it helps my issues
g-zu: the in-game console I meant
glisse: g-zu: won't help
glisse: likely mesa issue
g-zu: maybe, but what about the resolution setting?
g-zu: I like stuff fullscreen
osiris_: glisse: aah, right
osiris_: glisse: then it doesn't work for me neither
glisse: osiris_: i think you can still merge just check that it doesn't work on master
glisse: so that you don't regress
papillon81_: hey. i just tested glxgears with mesa git, drm r600-700 branch and it looks like in the past days there have been enormous improvements made
glisse: got to go off for the weekend
papillon81_: only thing i'm seeing are distortions in some programs (opengl)
g-zu: papillon81_: how is only seeing distorsions an improvement?
papillon81: g-zu: that was already there before
papillon81: just had a crash :-(
g-zu: that's sad
g-zu: I'm also waiting for r600 to be in a working state
g-zu: someone said here a few days ago it's like going to be in less than a week
papillon81: g-zu: r700 actually
g-zu: same here, rv740
g-zu: sorry, rv730 too, I somehow remembered wrong ATI RV730XT [Radeon HD 4670]
g-zu: btw checking Xorg.log I get the following line: (II) RADEON(0): Detected total video RAM=524288K, accessible=262144K (PCI BAR=262144K)
g-zu: how come it's not all accessible
adamk_: g-zu, The driver limits it. A memory manager is really needed to allow access to all vram.
g-zu: I see
g-zu: so it will all be available with kms and ttm
adamk_: Theoretically. One of the developers would have to comment on whether the driver will need changes even after ttm and kms to allow for accessing all the vram but, as I understand it, it certainly can't happen till those are done.
g-zu: thanks for the clarifications adamk_
adamk_: And, as I understand it, they are pretty close to being available for users on r600/r700 hardware.
agd5f: it's a PCI limit. max BAR size is 256 MB. that's the most the CPU can map. the GPU can access all of it
adamk_: Oh... My mistake then.
adamk_: So it has nothing to do with ttm?
agd5f: the fix will come with ttm
agd5f: the part of vram that isn't visible to the CPU can't have sw access since it can't get to it
agd5f: so if software needs to access something there, it needs to be migrated
agd5f: to somewhere it can be accessed, either CPU visiable vram or gart
MNZ: I always thought gart was just a way to get to vram :S so what is gart actually?
agd5f: MNZ: system ram mapped into the gpu's address space
g-zu: wow, finally a simple explication for that term
MNZ: All this time I thought it was the other way round, vram mapped to virtual address space
g-zu: osiris_: so far no luck, couldn't start warsow, in openarena I can't see the in-game menu so I can get to the playing part
g-zu: I'm now building nexuiz
g-zu: osiris_: nexuiz works
g-zu: osiris_: anything in particular I have to look if it's enabled or disabled in the game to know if it uses vbos?
g-zu: wait, stupid question
g-zu: the game has vertex buffer objects in the video menu
g-zu: they are enabled in (compatible) mode whatever that means
MNZ: g-zu, rv730 right? Nexuiz works? I can
MNZ: I can't even see the startup screen*
g-zu: MNZ, I have 2 machines
g-zu: the other one is rv380
g-zu: I'm testing on the other one
MNZ: ah ok
g-zu: osiris_: in nexuiz I can't see the players, but I can see their weapons
g-zu: at least some of them
chlue: thanks. reading the room topic allready solved my problem. Apparently I run a 'OMG free distro' :-)
mcgreg: nexuiz for me :
mcgreg: Invalid source texcoord for TEX instructionvalidated 0x5177940 [0xF030A000, 0xF030A000]
mcgreg: above end: 0x5177940 0x00000000 0xF030A000
g-zu: mcgreg: what card
mcgreg: rv730xt , radeon 4670
g-zu: mcgreg: not supported yet, I was testing on a rv380
chlue: adamk_: yes Debian
g-zu: with the vbo_clean branch from osiris_
g-zu: what does omg stand for
g-zu: I'm pretty sure it's not oh my god
boghog: i get that error mcgreg as well if im tryign to draw really large vbos
adamk_: is pretty sure it is.
boghog: on my rv770
boghog: erm, s/that error/the same error that mcgreg got/
g-zu: where do you get the firmware from, in case you don't have it?
agd5f: g-zu: it's included in the drm, uless you are debian which removes it
agd5f: and packages it separately
g-zu: oh, I see
g-zu: that nexuiz is really hard to play, it's hard to try to estimate a players trajectory by only seeing the weapon
g-zu: I'm trying more games soon, but I'm on gentoo and compiling takes time, especially on a single-core machine
g-zu: what happened to osiris
g-zu: osiris_: it's definitely a vbo issue with players not being rendered in nexuiz, when I switch vbo's to off completely they are rendered (although they look like crap)
g-zu: brb, kernel update on the router
yangman: agd5f: has the number of AtomBIOS scratch registers changed from generation to generation?
agd5f: yangman: nope 0-7 on all of them. even combios
agd5f: the location changes on r6xx and newer, but that's it
yangman: ok. I figure I might as well actually finish that save/restore patch
DanaG: hmm, anyone ever heard of the HP Visualize FX6 video card?
mcgreg: hmm I made a few screenshots of the emulator Mupen64 (n64 emulation) while plaxying Mario Kart 64 - would anyone be interested in seeing those - IF it could be of any help or interest...
mcgreg: the speed was totally fine even - the gfx were just - more or less broken. but kind of playble
MostAwesomeDude: mcgreg: You're going to have to confirm that it's our fault; mupen's got graphical glitches of its own. :3
mcgreg: well... a few perhaps :)
mcgreg: but it's ( from my humble point of view) not far away from being a nice working 3d application
mcgreg: and it very nice to see google earth working :)
DanaG: http://22.214.171.124/vga/search.php?rsvelikost=uvod&rstext=all-phpRS-all&rstema=26 -- hmm, old boards... interesting.
suokko: whoooo! 260 fps->380fps in gears and xmoto main menu is usable now! http://nopaste.com/p/afvFDih5rb
suokko: Too bad warzone is a bit too much still
nanonyme: Lol. :)
nanonyme: xmoto runs at perfectly usable speeds with r600. :3 (geometric corruption issues persist there too)
suokko: nanonyme: xmoto game runs well except a few levels with huge geometry
suokko: But main menu is very slow (5fps) without my patch. But now I get 30 fps in main menu too
nanonyme: Well, as said, xmoto is nice and fast all around for me. I suspect after the r600 geometric corruption gets fixed, the driver will be mostly usable...
suokko: I still should move index buffer to dma region so it could use same optimization
DanaG: It really has been some amazing progress lately. Really amazing.
nanonyme: DanaG: Yeah, Richard, Cooper and Alex make an awesome team. :)
suokko: Now index buffer bo handling accounts for over 30 % of system time used by gears.
suokko: btw, Does anyone else have r300 card around to test if my patch also works there?
muep__: has even two r300 cards, but none installed and no testing environment :-(
stikonas: suokko: rs480 is ok?
suokko: stikonas: sure. If you have kms working that should even give minor boost to fps
stikonas: yeah, kms since spring
stikonas: suokko: your patch does not apply to mesa master
suokko: stikonas: let me see
stikonas: I've used git apply and I have latest git version
ernstp: yey, compiz on 4770!
ernstp: nice work
ernstp: a number of graphics artifacts, bu not instant death!
ernstp: agd5f: I guess you'll post on your blog when you want bugreports for r600 3d?
suokko: stikonas: I moved my patch to clean master now it should apply http://nopaste.com/p/aJDLwOClA
agd5f: ernstp: yeah, once we figure out this geometry issue
ernstp: supertux2 didn't crash either
ernstp: agd5f: which geometry issue?
agd5f: ernstp: the weird geometry corruption that affects most apps
ernstp: agd5f: btw, do you have a 4770/rv740 at work now? :-)
agd5f: ernstp: yeah, I've had one for a while
ernstp: agd5f: great. saw that they're comming back to the stores now again btw
mcgreg: ernstp: from what I see: google earth is working fine (99% at least). quake 2 + quake 3 "work" - with that geometry corruptions. so it alien arena. mupen64plus is working fine too - as agd5f stated for most apps - also with geometry corruption
mcgreg: nexuiz is not - fails here quickyl
mcgreg: stellarium is quite broken and might crash/freeze X (here)
ernstp: mcgreg: I can imagine, it's using very advanced features
DanaG: hmm, should I try the radeon driver again (considering I've last tried it, oh, yesterday morning.)
mcgreg: spped is okay with most application - goole earth is quite slow, but usable
ernstp: does nexuis work on r300?
DanaG: ? <-- oops, lost that.
ernstp: the new blit accelleration did the trick
mcgreg: ernstp: yes, it is really very impressive what happened in the last weeks
ernstp: guess they've got the good quality of the r300 driver to thank that for?
mcgreg: glxgears gives me now 3300fps :) thats a nice amopunt - even thought it means nothing :) the "r600: implement optimized buffer swap code" things made it is 5x as fats as before
ernstp: got a nice little r300 laptop that I should be trying all the new KMS stuff on but I'm using it for work now so...
DanaG: I'm going to get my old 9800 Pro back from a friend I lent it to, so I'll try KMS on that.
ernstp: agd5f: btw, KMS for r600? have you started working on that at all?
agd5f: ernstp: glisse already has it working
ernstp: mcgreg: got 20 fps before, 2700 now, so 100x here (I think)
ernstp: agd5f: public repo anywhere?
DanaG: Hmm, are KMS and 3D still mutually exclusive?
mcgreg: ernstp: nah. at first it was 20fps here. then 670. now 3300
agd5f: DanaG: for the moment with r6xx/r7xx
ernstp: mcgreg: guess I skipped a few updates
ernstp: agd5f: none of you have a repo on kernel.org do you? why aren't you doing dri/drm development there?
agd5f: ernstp: we are
agd5f: I just don't have a tree on that server
agd5f: but all the patches on the mailing list are generally against linus tree
agd5f: airlied has a tree there and we funnel drm patches through him
ernstp: but the current r600 work is in mesa/drm
ernstp: agd5f: I see
taiu1: agd5f: the geometry issue might be that you emit 1 less indices
taiu1: agd5f: yup, seems better with <=
agd5f: ernstp: historical accident. I just happened to have started working on an internal tree based on that
stikonas: suokko: your patch applies but it does not compile
stikonas: suokko: r300_texstate.c:326: error: ‘struct radeon_dma’ has no member named ‘current’
suokko: aha. I forgot there could be r300 specifig references to that
agd5f: taiu1: doesn't seem to help
taiu1: agd5f: works for me
agd5f: taiu1: patch?
taiu1: like http://pastebin.ca/1529817
suokko: stikonas: It is 2 lines patch to fix r300
suokko: stikonas: http://nopaste.com/p/aBKygU8Y6
suokko: Now r300 compiles in my tree
agd5f: taiu1: that can't work. you'd be sending more indicies than the hw expects
stikonas: suokko: now it compiles
suokko: I hope it runs too
stikonas: suokko: but r600 does not compile :(
stikonas: though I can disable it
suokko: stikonas: It needs same changes
stikonas: the same error with r600
stikonas: ok , will try to patch
tavelram: (slackware) Ive got a rage II that using the "ati" driver can output composite sync on vga, and it works fine in x-window - is there a way to disable the "console"? ie I dont want to accidently output a non composite sync if the x-window server happends to die. or perhaps use the xorg driver even during boot/console, so that I can output the correct sync all the time?
taiu1: agd5f: how so, you program (R600_IT_DRAW_INDEX_IMMD, (num_indices + 1)
taiu1: where num_indices is end-start
taiu1: agd5f: sry, my bad
agd5f: taiu1: in that case, yes, but your patch didn't do that. plus, you need to specify the number of indices the hw expects in vgt_draw_initiator
taiu1: it's the out_batch count
taiu1: well wtf then happened, all demos sofar run without corruption
agd5f: taiu1: maybe falling back to swrast?
taiu1: yeah, new windows without LIBGL_DRIVERS_PATH, how embarassing
Telek: agd5f: Any changes recently that would cause a hardlock on an rv740?
stikonas: r100 also needs the same changes :(
agd5f: Telek: not that I know of
suokko: stikonas: sorry.
stikonas: no problem
stikonas: it will soon compile :)
stikonas: ok, mesa compilation is finished
stikonas: suokko: glxgears fps 533 -> 380
stikonas: openarena seems to work
stikonas: how do I view fps with openarena
suokko: I don't know. But somethig is not right if gears fps goes that much down
stikonas: neevrball is broken
stikonas: but neverputt is ok
stikonas: will have to check without the patch whether neverball works
suokko: stikonas: neverball works but neverputt is broken
suokko: with r200
stikonas: neverball is collecting coins?
stikonas: strange, they use the same engine
stikonas: why only one is broken
suokko: neverputt has lightning problem that has been there since radeon-rewrite
suokko: And they use a bit different way the engine when I looked the code
suokko: neverball looks like more complete implementation of rendering
stikonas: neverball is broken with radeon-rewrite
stikonas: your patch did not broke it
stikonas: airlied: is neveball regression a known bug?
stikonas: I think that clipping is broken
wohnout: Hello guys, I've tried to run googleearth but it crashed with drmRadeonCmdBuffer: -22 and this was in dmesg drmRadeonCmdBuffer: -22
thalunil: there is a xorg.log in /var/log and you should certainly tell us which driver you use
thalunil: and: for what gfx hw....
phercek: I'm thinking about trying newer versions of radeon drivers. I'm interested only in my 2D desktop not to slow down to crawl when I launch thunderbird. Are these locations still the best ones to use? Will it be quicker than the git versions from 20090804?
phercek: git://anongit.freedesktop.org/xorg/driver/xf86-video-ati (master)
phercek: git://cgit.freedesktop.org/mesa/mesa (master)
phercek: git://cgit.freedesktop.org/~agd5f/drm (r6xx-r7xx-3d)
wohnout: thalunil: Sorry. Wait for a while
wohnout: ati radeon x1400. mesa-7.5, libdrm-2.4.12
thalunil: better enable AIGLX
thalunil: for the googleearth-OpenGL-thing
wohnout: ok I had some issues with kde4 and AIGLX. So maybe it is fixed now :) I hope
osiris_: airlied: ping
osiris_: airlied: I'd like to push my vbo_clean branch to master, but before I do this I want to be sure that I used the persistent bo interface correctly. could you check it?
wohnout: is this bug radeon related? http://pastebin.com/d3d52d494
agd5f: wohnout: looks like a radeon drm bug
airlied: osiris_: you need to add them before the space check
DanaG: nifty idea: http://www.realweasel.com
osiris_: airlied: hmm, so maybe I should move the space check calls to r300ValidateBuffers too. what do you think?
suokko: wazaaa! 3142 frames in 5.0 seconds = 628.360 FPS :P
stikonas: suokko: share the patch
suokko: 3 days ago that was 180fps
stikonas: maybe r300 will also perform better
suokko: The last improvement is only for r200
stikonas: ah, ok
suokko: DanaG: It's not benchmark. But now glxgears is not any more cpu bound so worst bottle necks in r200 KMS code was fixed there
agd5f: yangman: you should save the regs on all cards, not just atom
yangman: agd5f: ok. otherwise reasonable? I'm not actually entirely sure where it needs to be done
agd5f: yeah, looks good
agd5f: we should probably reprobe the connectors on resume as well if we don't already
agd5f: in case monitors have changes since suspend
DanaG: hmm, what happens if you have two video outputs active, and unplug one of them on the fly?
DanaG: oh, and /me googles, to try to figure out... what happens with kms on dual-monitors?
agd5f: DanaG: stays on until you turn it off
osiris_: airlied: should I be calling radeon_cs_space_check_with_bo for bo's received from radeonAllocDmaRegion?
suokko: osiris_: no
agd5f: DanaG: eventually we can wire up hotplug interrupts and get an event when that happens
suokko: osiris_: Dma already calls the space check for you.
osiris_: suokko: where?
airlied: osiris_: probably a good idea i fthey are available at that stage
airlied: osiris_: no just the dma one
yangman: oh, oops. I think I did something silly with git send-email
osiris_: airlied: hmm, looks like I actually need to call radeon_cs_space_check_with_bo for bo's received from radeonAllocDmaRegion (at least for index buffer bo), otherwise sauerbraten ends up with sauer_client: radeon_cs_gem.c:121: cs_gem_write_reloc: Assertion `bo->space_accounted' failed.
rnoland: agd5f: would not overwriting the init value with the saved value be the right thing?
rnoland: not that it works for me, but....
suokko: osiris_: That happens if there is flush after you allocate dma buffer and before you use it
rnoland: agd5f: at least for most registers i would think...
suokko: So you have to call space check if there is flush
agd5f: rnoland: depend on the situation, is it's suspend to ram, the system bios doesn't always post the card, so the regs are zeroed. on suspend to disk the card is posted again when it the system boots
agd5f: in most cases the values should be the same other than is the connected monitors changed during suspend
rnoland: agd5f: right, but the saved regs have had full initialization
rnoland: right, that is what i was thinking, if display changed or something...
agd5f: rnoland: they are just bios scratch regs. they don't actually affect the hw
rnoland: i.e. user docked with a panel attached.
agd5f: just used to store state shared by the driver and bios
rnoland: agd5f: ah, ok then...
agd5f: rnoland: although in some cases the atom command tables reference values there
agd5f: so it's good to make sure they are set to some known state
osiris_: suokko: I think I'll call the space check every time then
suokko: osiris_: If you ask from me there is bug somewhere if you get flush while handling dma buffer
airlied: suokko: well the bug is that the dma buffer is gone once you've flushed
airlied: so if you've been writing to it its not longer available
suokko: bug is that there is uncontrolled flush somewhere
airlied: which is what your patches are mostly solving
airlied: I've just been busy rtying to finish off some kernel stuff, I need to gte back to mesa and go over the whole dma stuff agian
airlied: maybe my 3rd time I'll get it right
suokko: airlied: I have at least now performance improvements with r200 when I added linked list to keep dma buffers
suokko: And I put indices to dma buffer too gain some more performance
airlied: suokko: I'll look at the patch next week I promise ;-)
suokko: But I don't understand how the bo sizes is decided there. I mean why there is request for some size and the code to fill empty space
suokko: PRoblem with merging the indices to dma buffer is rendering problems still
osiris_: airlied: ok, I've update the persistent bo patch. if you're ok with it I'm going to merge my VBO to master
suokko: So now I suspect that there is some alignment problems
wohnout: agd5f: i think you were right http://pastebin.com/d37ab043d
airlied: osiris_: still wrong
airlied: osiris_: you just add th epersistent bos
airlied: then do the space check with either the dma buffer or NULL afterwards
suokko: R500 guide sayes: "BUFFER_SIZE: ... For misaligned data, this number must be increased by 1."
osiris_: airlied: so no space check for persistent bos?
suokko: But there is no code to check for that
airlied: osiris_: persistent bos get added to the list so a single space check
airlied: will check everything in the persistent list
airlied: + whatever you passed in
airlied: its commented in radeon_bo.h ;-)
airlied: \/* do a space check with the current persistent BO list and a temporary BO
suokko: And what is size of indices in r200?
airlied: 16 or 32bit are supported
osiris_: airlied: how about know?
airlied: osiris_: so you need to do a space check with the dma bo after the loop
suokko: I guess I'm again blind for full picture what happens for indices
airlied: add persistent bo adds to a linked list
airlied: you then need to check the linkded list
airlied: I suspect doing the dma.current check is all yo uneed
airlied: but if its close enough I'll experiment wiht it
airlied: suokko: I was lost to why my indices didn't work inside DMA buffer
suokko: airlied: http://nopaste.com/p/aQaCIRALc ;)
suokko: I think it might be related to some alignment problem. I think I will try to reert back to separated bo and then check what happens if I break alignment from start of bo
osiris_: airlied: checking dma.current only doesn't work. sauerbraten breaks as without the check for index buffer bo
airlied: yeah INDX_BUFFER might have alignment issues
airlied: osiris_: checking it after you add al lthe persistent bos?
airlied: okay push what works andI'll try andf fix it up
suokko: osiris_: Maybe your problems with index buffers were related to r200 problems
osiris_: suokko: and what are r200 problems?
suokko: Some undocumented limitation maybe
osiris_: suokko: no, that's not it. index buffer size is dword aligned here
suokko: osiris_: If I allocate the buffer to dma bo I sometimes get bogus geametry to screen
osiris_: suokko: any specific app?
suokko: torcs had minor issues too
osiris_: suokko: downloading warzone now
suokko: Found the bug! :)
suokko: in r200 code. tcl renderer was not adding offset to bo pointer
airlied: suokko: oh so it was writing over the vertices.
suokko: Here comes playable warzone for r200! :)
suokko: airlied: yes
nanonyme: suokko: It's kinda funny that when you say "found the bug", you actually mean "fixed the bug". ;)
nanonyme: Just a thought. :)
suokko: Finding a bug in code is not always fixing the bug that you are hunting ;)
nanonyme: Well, yeah. But if you actually manage to spot the real origin of the bug, rest is with luck a simple fix and with bad luck software reconstructions. ^^
nanonyme: doesn't feel that lucky
suokko: warzone with playable fps and no corruption! I start feeling lucky ;)
airlied: suokko: nice.
suokko: I wil lstill have to add that dma buffer return code for elt buffer to save a bit space there
suokko: airlied: or maybe you should revert your revert patch after the offset problem is fixed
suokko: I guess I will do that
osiris_: I've pushed VBO stuff to master. enjoy
nanonyme: Yay. :)
nanonyme: This was KMS-only, aight?
nanonyme: has probably asked this already
nanonyme: So it might affect my experience on the r600 driver too then.
mcgreg: no - he didnt ask already today? :)
osiris_: keep in mind, that you won't get perf boost in all application
airlied: nanonyme: its go nothing to do with r600
osiris_: nanonyme: it's for r300 driver only
nanonyme: airlied: Needs to be ported separately?
airlied: r600 is a different driver
nanonyme: Right, must've mistaken it for some more generic shared stuff then... Carry on.
mcgreg: so r6xx wont take any advantage of that work?
airlied: well it can pull the common code but it needs to write the gpu specifc code
airlied: note the common code isn't the hard bit
airlied: suokko, osiris_ : I looked at r200 VBOs briefly
airlied: it appears r200 can't support all GL primitives
airlied: or the driver doesn't do it if it cna
airlied: so we'd have to fallback to swtnl paths more often
osiris_: airlied: more often than now?
airlied: well r300 supports all prims in hew
airlied: if we hit a prim on r200 that hw doesn't support (or is broken with) we'd need to switch
osiris_: airlied: and what we are doing now if we hit such prim on r200?
airlied: though I'd like to revalidate that it doesn't support all the prims properly
airlied: osiris_: sw tnl degrades it
airlied: see r200_tcl.c
osiris_: airlied: then implementing VBOs should introduce any performance regressions
airlied: no it shouldn't
airlied: its more being careful to fallback correctly
suokko: What primitives are missing?
airlied: r200_Tcl.c has them, anything with HAVE_* == 0
osiris_: airlied: the radeon kms driver is missing RV530_FG_ZBREG_DEST(0x4be8) register in safe registry list
Julia: I hate when my laptops cooler is making noise. I am using RS690M radeon x1200 video card with ppa xorg edgers dradeon rivers. I don't know how they work but it seems that a lot of cpu is used when drawing videos or animations in web browser.
Julia: And when the cpu load is too high (and temperature rises), cooler starts on max power.
Julia: Any ideas how to reduce cooler speed or any other way to make it silent?
papillon81: Julia: watch less videos ;-)
Julia: I hate that ati no longer supports my video card on linux
papillon81: Julia: you are using the fglrx?
Julia: ofcourse I need 3d acceleration but radeon drivers are not so good yet
Julia: I am using xserver-xorg-video-radeon
Julia: fglrx won't work with my card on ubuntu jaunty
papillon81: Julia: well, it's crap anyway
Julia: what is crap?
papillon81: i'd switch rather today than tomorrow
Julia: so far it seems that radeon with linux is like a curse ;D
Julia: I have nvidia 8800 gts on desktop pc and it works perfect with Ubuntu
papillon81: Julia: yes, but there you will get the same problem of being unsopported one day
papillon81: that is what made me buy ATI now and no longer NVIDIA
Julia: I hope that by that time I will have new computer. :D
papillon81: even better :-)
Julia: Video drivers on linux is a mess
DanaG: You ever try using an old laptop with geforce*cough*4*cough*mx?
Julia: Open source drivers are not yet finished and ati official drivers no longer support my card
Julia: it is lame :D
DanaG: Now that... is a prime example of why closed-source hardware is bad.
DanaG: the gf2=4 mx.
Julia: DanaG, maybe you are right
papillon81: DanaG: i know. had a GF 4 too until last week
Julia: and what now?
Julia: what options are there?
DanaG: Granted, that's an old, spare system, but still makes a good example.
Julia: Haven't seen good radeon open source drivers
papillon81: Julia: be positive and wait some weeks. the driver is evolving fast
Julia: with good 3d support
Julia: well yeah :)
Julia: had many problems with default jaunty radeon drivers. Then I installed from ppa and solved most of my problems
papillon81: Julia: exactly. sometimes ubuntu is the problem, not the drivers
papillon81: however, got2go now. sleeptime over here
Julia: well yeah. Latest drivers are better but far from perfect.
Julia: For example
Julia: I get video tearing and stuff like that
Julia: it is 2:48 here
Julia: AM :)
papillon81: Julia: uups. even 1 hour earlier here
Julia: Germani, right?
Julia: ok, good night papillon81! :)
papillon81: n8. and I hope the radeon stuff gets better soon
osiris_: airlied: I just realized that OQ's are even harder than I thought because of ddx. we could have OQ which lasts for few rendering operations, and ddx can insert its rendering operation in the middle - that will result in wrong resuling query value
suokko: How about queuing OQ using multiple IBs and then excecute all of them at once?
Julia: Oh my. Please keep upgrading open source radeon drivers. I get 75% CPU usage when watching youtube hd video in firefox. :(
Julia: and should it use cpu? souldn't it use some sort of video card processor?
suokko: Julia: i would blame flash for not supporting xv
Julia: oh. so if I run it thru xv it should not use cpu?
suokko: Julia: It would use but not that much it uses now
Julia: yeah :)
suokko: Justtry the downlaod link and play same video in your favorite media player
Julia: Ok, one moment
osiris_: suokko: you can't guarantee that all rendering operations will fit in one CS
suokko: Then problem is drm interface
suokko: Because if I'm not mistaken hw would support that we push multiple CS buffers to kernel. drm would scheduler them as indirect buffers for rendering.
Julia: so what so what can I do?
Julia: I tried running video in VLC using default settings and it used a lot of cpu
Julia: then I changed to Xvideo and CPU usage reduced a lot
suokko: Julia: I don't use flash because it doesn't work. I always download all the videos and watch them in native plyer that can play HD stuff when flash can't even play normal videos always
Julia: Now trying to run movie
Julia: well, cpu usage is not so high but I still get some video tearings
suokko: Can you paste your xorg.log?
Julia: and if I maximize video (not running in fullscreen) I get video lags
Julia: sure. one moment
Julia: Xorg.0.log http://pastebin.com/m3dd082d2
Julia: suokko, do you have any other suggestions? Is it possible to make flash use Xv?
bridgman: not yet; apparently flash decompresses to RGB rather than YCbCR, not sure why, but that's why they use opengl
bridgman: still haven't figured out why they're so picky about drivers; they explicitly disable video acceleration if they see the open source driver
bridgman: wonder if we should add an RGB format option to Xv and ask Adobe to use that ?
suokko: Julia: Do you use compiz? Compiz can cause tearing to video
Julia: I will disable it and run that video. one sec.
airlied: osiris_: can we temporarily disable OQ across certain CS packets?
airlied: like DDX doesn't touch Z
Julia: suokko I don't get lags anymore. Now I can maximize video and it plays ok. But I still get some video tearing
Julia: It is like... Some lines appear on the video where is bigger movement
osiris_: airlied: nope
Julia: so got rid of lags, not from tearing :D
airlied: osiris_: might be worthasking anholt if intle has the same issue
suokko: hmm. I'm wondering if your driver is too old. Because the latest drier should prevent tearing if compiz is disabled
Julia: maybe it is VLC's fault
osiris_: airlied: we could write the samples counter for every rendering operation, and then sum them, but that would result in bigger memory use
bridgman: are we sure VLC is using Xv as output, and not X11 or GL ?
Julia: So I changed video mode for totem
Julia: to xv
Julia: got rid of lags for totem but still lines on fullscreen video. (tearing)
Julia: but I get tering only if I maximize that video or run in fullscreen
Julia: let me test it with HD video
bridgman: that's wierd; normally video is tear-free with radeon
bridgman: what is your display refresh rate ?
airlied: osiris_: I do wonder if there is a way to pause the Z pass coiunting stuff
airlied: otherwise yes you'll need to writeback after every CS
Julia: I get no tearings for 720p video
airlied: an dsum them
Julia: I guess 60Hz
Julia: and 1680x1050 resolution
Julia: I think that video tearing only if video is being resized
suokko: Julia: There is limits to what card can play without tearing. That limit was increased in later version than what your driver is
suokko: So for you it is x+y can't be over 2800 or you will get tearing
Julia: so what can I do?
Julia: it is weird that 720p has no tearing and actually it plays better then it does on windows :D
Julia: I have xserver-xorg-video-radeon 1:6.12.99+git20090807.cd99d9f0-0ubuntu0sarvatt~jaunty
bridgman: that seems pretty recent ;)
suokko: Julia: You could try to upgrade your driver to development
suokko: aha it is from master ... That is problem with version numbers
Julia: so what is the solution?
Julia: install it from other repo?
bridgman: Julia, if you play the 720p video but expand it to full screen do you get tearing ?
Julia: no I don't
Julia: only with dvdrips
bridgman: that's wierd...
suokko: Julia: Then problem might be codec that doesn't work well enough. You could convert codec to theora
Julia: I don't know what codec totem uses
suokko: I have seen a few windows based formats playing badly but when I converted them to theora play back was a lot better
Julia: default that comes with ubuntu
osiris_: airlied: that's really wierd. I was happy with ~100fps in sauerbraten, but then the machine hang, I had to reboot and now I get only ~50fps. I didn't change anything
Julia: video is .avi
Julia: or divx
EruditeHermit: osiris_: clock gating?
Julia: so I still don't understand what to do.
Julia: Upgrade drivers or what
EruditeHermit: osiris_: or cpufreq
osiris_: EruditeHermit: hmm, will check the cpufreq
suokko: Julia: no. One solution would be converting the problematic file to more friendly codec like theora
Julia: isn't xvid friendly?
Julia: omg. all dvdrips come in xvid or divx :D
Julia: oh. let me try dvd
suokko: Julia: http://commons.wikimedia.org/wiki/Help:Converting_video#ffmpeg2theora
osiris_: EruditeHermit: nope, it's not cpufreq. and I'm not using any PM options
EruditeHermit: osiris_: the same areas of the game?
Julia: yeah dvd is ok
Julia: ok suokko and what about compiz? I realy can't make it work with it?
EruditeHermit: osiris_: are you working on the OQ stuff?
suokko: Julia: Not until Karmic Koala
osiris_: EruditeHermit: yes
EruditeHermit: how is that going?
Julia: when is it going to come out? :D
suokko: Unless you want to try Fedora 11. There Compiz would work
MostAwesomeDude: osiris_: OQ normally aren't very big; you could use a second CS object to queue up OQ rendering and try and keep it in sane chunks.
suokko: Koala will come in end of October
Julia: I am not in rush :)
MostAwesomeDude: bridgman: Flash does RGB decoding because that's what its renderers expect. It's not a very good tool for doing video. :3
Julia: October isn't so far away
Julia: oh, I'l convert that video and tell you what happens
EruditeHermit: osiris_: did the crash corrupt configuration of the game? Maybe it reverted to a stock configuration?
osiris_: MostAwesomeDude: I can't because we could get: OQ_BEGIN, MESA RENDER, FLUSH, DDX RENDER, MESA RENDER, OQ_END, FLUSH
bridgman: MostAwesomeDude; I guess the question is why expect RGB when YCbCr would give more quality or use less bandwidth
osiris_: EruditeHermit: nope
bridgman: not blaming you personally or anything ;)
EruditeHermit: osiris_: maybe the 100fps was a dream? =p
osiris_: EruditeHermit: nope, I had the fps value written down, because I was comparing VBO non-VBO branches
osiris_: I'm not crazy
EruditeHermit: I was kidding =p
EruditeHermit: oh what was non VBO fps?
EruditeHermit: maybe for some reason its going down non VBO path again?
Julia: only problem is that it takes about 3 hours to convert one movie :|
MostAwesomeDude: Arg, stupid keyboard. :C
Julia: how lame is that :D
EruditeHermit: its ffmpeg, not lame =p
osiris_: ~90FPS without VBOs, ~100FPS with VBOs
osiris_: (in the opening scene)
MostAwesomeDude: bridgman: They really don't understand video, or the various Linux APIs. I offered up a patch for radeon textured video to do RGB; they said that XVideo was "not the way to go" IIRC.
EruditeHermit: oh so this is worse than before
MostAwesomeDude: nouveau already supports RGB Xvideo.
MostAwesomeDude: My intel doesn't, but
MostAwesomeDude: it probably could.
EruditeHermit: MostAwesomeDude: what about binary drivers
EruditeHermit: that would be the problem
MostAwesomeDude: osiris_: Hm. Lemme go check OQ spec really quick.
osiris_: maybe next reboot will fix it. rebooting...
Julia: oh my. how lame is that low res videos have video tearing but high res doesn't :|
MostAwesomeDude: EruditeHermit: Honestly, if they can't figure out how to decode video quickly, I'm not going to hold their hand. I'm okay with Flash being replaced by Gnash or