airlied: woot I fixed it (may or may not be fixed, just tempting fate)
airlied: agd5f: emitting an SC reg before the 3D flush all in done composite seemsto help
airlied: but I'm just testing it to more death now
airlied: christ gtkperf 100000 loops take ages.
agd5f: yeah, you need to write a downstream reg at the end for proper cache flushing iirc. the driver tips section of the r5xx accel book is probably a good place to look
airlied: yeah thatss where I guessed it from
airlied: so I'm hitting SC_CLIP_RULE
airlied: spstarr: give ati-57 a go one some cards with kms if you have a chance.
airlied: just building it in koji now
spstarr: with 3D on?
airlied: not sure if it'll help any of your cards
spstarr: or just 2D exa comp
spstarr: which you fixed
airlied: well its mostly EXA fixes
airlied: see if it makes things worse :)
spstarr: sure, can see what changes, NO agp?
spstarr: or with agp
airlied: agp might or might not get better...
spstarr: will try both...
spstarr: EXA UploadToScreen bits
spstarr: getting now
spstarr: well im in agp mode...
spstarr: this looks funky...
spstarr: lemme record if i can see wth im typing
airlied: spstarr: yeah that agp funkyness is wierd.
airlied: no idea what changed there :(
spstarr: oh it is, very nice corruption with text glyphs i wish I could see what im typing :)
spstarr: recorded goin gto non-agpnow
spstarr: airlied: http://www.sh0n.net/spstarr/agp-corrupt2.ogg
spstarr: logging into KDE to see if i saw the pixmap corruption on some icons
airlied: spstarr_work: perms!
airlied: gives up for today, rs690 still crashes if I do enough damage to it
spstarr: airlied: hmmmm worse with non-agp
spstarr: with KDE i see this:
spstarr: with GNOME it looks ok
spstarr: airlied: http://www.sh0n.net/spstarr/kms-nonagp-kde-corruption.ogg
airlied: spstarr: permissions?
spstarr: try again
airlied: wow messed up.
spstarr: the text in the menu is ok
spstarr: the other bits are corrupt
spstarr: sleep, good luck :)
airlied: decides to test rv370 in no-tcl mode to see if it dies like rs690
glisse: airlied_: cmd validation and checking will always took times
glisse: even more time with full cmd checking
glisse: oh and in my experience inline vertex are stabler than vbo
glisse: iirc when i converted mesa to send all vertex inlines i never was able to trigger vap lockup anymore
glisse: if you come up with figures on where kms+cs is slower i would love to see them, haven't gone around of doing such things yet
glisse: got to run bbl
airlied_: the big one is the checking of the X server stresm.
airlied_: the old code just trusted the IB from X, now we check it and memcpy it
airlied_: sw fallbacks onto uncached pixmaps also is a bit slower
airlied_: but otherwise are mostly as fast.
glisse: well avoiding the memcpy might save few cycles
glisse: but it will get slower with my cmd checking
airlied_: yeah readback would suck.
airlied_: the memcpy isn't that bad with PAT
airlied_: & zzzz
glisse: ok got to run anyway
glisse: bonne nuit :)
janboe: Hi, when kms initialize screen resolution?
adamk: janboe, When it loads the drm kernel module.
janboe: adamk, you mean radeon_drm driver?
janboe: But I could not find it following radeon_driver_load.
janboe: it seems I found it, Thanks
janboe: After kms setup display, how console access it, via framebuffer driver?
spstarr_work: glisse: how goes DRI2 or you working on Gallium driver now?
glisse: spstarr_work: haven't done a thing in a couple of week
glisse: busy with others things
agd5f: airlied: regarding your comment about additional overhead in command checking if we use new IB's for each command stream, I don't think it would be
agd5f: you'll have to do the relocs and and checks regardless of whether they are all cramed into one buffer or several buffers
glisse: agd5f: yup, only way to cut reloc time is by making it efficient and i don't think that merging ib would bring any speedup
glisse: agd5f: have you ever played with CRTC_GUI_TRIG_VLINE & WAIT_UNTIL ?
agd5f: glisse: yes
agd5f: glisse: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=vsync_accel
glisse: does it looked like a solution to tearing ?
agd5f: glisse: http://bugs.freedesktop.org/show_bug.cgi?id=18542
agd5f: in theory. although not much luck so far
glisse: agd5f: i was hopping that by selecting only appropriate vline (start & end) we could avoid to stall cp for too long
agd5f: glisse: I think it should work, but I haven't had time to play with it in a while
MrCooper: glisse: seems to work according to the above bug report
glisse: MrCooper: yup, i was going through the bug report
glisse: i would be curious to know about EXA perf after such things
MrCooper: yeah, though I suspect changing the VLINE range too often could be a lot of overhead
MrCooper: the problem is really that there's no way for the driver to know which operations need to be consistent with each other
glisse: MrCooper: so X client should know when their rendering are on screen ?
glisse: damm i need to read the protocol bits sometimes :)
MrCooper: what do you mean?
glisse: MrCooper: you said that client needs to control when they are displayed
MrCooper: there's no X11 protocol I know of to say 'now I'm starting with a set of operations that need to be consistent, now I'm done'
glisse: pagefliping sounds like the easiest solution
agd5f: glisse: http://www.botchco.com/alex/xorg/exa_double_buffer.diff
agd5f: problem is sw fallbacks
MrCooper: I don't think that's the only problem :) Again, what is a good time to flip?
MrCooper: you don't really know, and guessing wrong will still give tearing and/or kill performance
glisse: MrCooper: well in composited case i would say compiz can tell us, can't he ?
MrCooper: only for its own rendering; it still gets damage events from clients piecemeal
onestone: you need something like XDamageBeginRender() /XDamageEndRender() on clinet side and accumulate all damage between this two calls
onestone: and then a glx enxtension where the composite manager can say I'm currently rendering this damage please make sure it's already done.
MrCooper: for the latter, I think glXWaitX should be sufficient, if maybe too heavy
onestone: MrCooper: I've been discussing it already with the nvidia guys. And they think about using non blocking sync markers, so that the driver can synchronize the command streams
otaylor: onestone: right now with open source drivers, flushing buffers (glFlush()) should be sufficient
otaylor: onestone: Since there's never any reordering of buffers once they are submitted to the kernel, as far as I know.
otaylor: So if the client flushes to before telling the CM that it is done drawing, and the CM makes sure it has flushed after receives the notification of damage and before it starts drawing again, you should be OK
onestone: otaylor: it is problematic if compiz uses direct rendering
onestone: otaylor: and damage is send before the xserver starts rendering
otaylor: onestone: Yes, raw damage events without any higher level protocol and rendering in the server makes it harder
otaylor: onestone: I was thinking ahead a bit to a) direct rendering clients b) higher level protocol to get frame-accurate redraws
otaylor: for a direct-rendering 3d client with dri2, you probably could go with the simple idea that you don't generate damage until the SwapBuffers is flushed to the kernel
otaylor: onestone: For Damage events, if you wanted to be able to wait until the accompanying rendering finished you'd clearly need protocol extensions
otaylor: since the serial in the event isn't usable ... it's only about the CM's X request stream
otaylor: I wonder if you could simply not generate damage until the block handler after drawing has been flushed
otaylor: Not sure what the ordering constraints really are for damage events
onestone: otaylor: you don't really want to wait in the composite manager. You want that the driver delays the composite manager command stream until the xrendering is finished. so that the GPU doesn't run empty
otaylor: onestone: yeah, that's what I meant
onestone: but then you have to produce early damage events
otaylor: onestone: if you submit things to the kernel in the right order, then you don't need semaphores unless you have multiple command streams
otaylor: (for nvidia, they do have multiple command streams, as I understand...)
onestone: otaylor: the problem is that if you send the xrendering to the kernel and then send the damage event to the CM the GPU might run empty until the CM sends its rendering commands. But if you send the damage early, then x and the CM can create rendering request at the same time and you only need to make sure they are executed in the right order
otaylor: onestone: if you are running the GPU fully loaded, then the CM is rendering once per vblank, not when it gets damage from the server
otaylor: If you are not running the GPU fully loaded ,then I don'tthink it matters if you get a smal gap in the GPU workload between when the damage occurs and when the cm redraws it
otaylor: But really, more importantly, what I'm saying is that X server doesnt' need to wait until the rendering is *finished* to send damage to the CM
otaylor: it needs to wait until rendering has been submitted to the kernel
otaylor: So, the compositor can the get the damage and start rendering itself and submit that to the kernel while the buffers generated by the X server are still being processed
onestone: otaylor: I understand it, but I'm thinking that if we delay the damage events to the point after x has send the the rendering to the kernel, that this also delays the rendering command generation in the CM that might result in a missed frame in some cases
otaylor: onestone: currently, we are really never generating long queued buffers at all from the X server
otaylor: onestone: So, the interval between the damage being processed and it being submitted to the kernel should be minimal
onestone: otaylor: We don't have a direct rendered CM now, so maybe we should wait until we run into problems, and then try to fix them
otaylor: onestone: I saw krh demo one once, but yeah, we aren't quite there.
otaylor: onestone: Thinking ahead to multiple command queues and how to do synchronization *is* probably useful.
onestone: otaylor: nvidia has the problem now, so let them find the best solution, and use this for the free drivers later ;-)
otaylor: onestone: Except that they can't really find the solution on their own, because it's an X protocol issue.
onestone: Thats the reason why they want to extend XDamage and create a new glx extension
otaylor: yeah, well if they do that publically, great.
spstarr_work: airlied: any DDX to test today?
airlied: spstarr_work: maybe later, when I actually start work.
airlied: spstarr_work: oh btw how much RAM the AGP r3xx you using have?
kupo: hi channel I'm having an issue with my radeon firegl T2 , since upgrading to intrepid exiting any game hangs the system
spstarr: airlied: are you staying in rawhide or remaining in F10 updates?
airlied: spstarr: depends on the fixes I have to make
spstarr: hmm, ok
airlied: at the moment I'm trying to fix EXA breakages on some IGPs.
spstarr: that might help me :)
airlied: nope it won't
airlied: unless they are as broken as AGP.