[RFC] dri2-sarea

[Thomas H. <the...@vm...>]

Hi!

I wanted to get some comments about an idea to use dri2 that might 
improve some drawbacks on dri2 compared to dri1.
What's motivating this is the following:

1) On some systems, X roundtrips are very costly. For example on via 
processors when running gears, X ends up at around 10% for just the 
reportdamage call of dri1. I see similar or worse results on vms, but 
since I'm not 100% sure how to interpret "top" in these cases those 
results might be insignificant.
2) Some dri clients, like XvMC, might not be interested in other 
information than whether the cliprects of the dri drawable have changed, 
and given the above, might not want to call the X server once per frame 
to get the dimensions, since that would double or triple the CPU-usage.
3) In some cases drawables might want to carry extra driver-dependent 
information. This could be shareable synchronization objects and offsets 
into kernel buffers used for sub-allocation.

One way to fix this would be to have the X server set up a per-drawable 
sarea with the contents defined solely by the driver. That sarea could 
perhaps be a shmem object, or a (possibly sub-allocated) GEM/TTM bo. 
Protection of the sarea data could be handled by a per-sarea drm-like or 
futex-like lock. Like dri1, the dri2 client could then update the 
drawables or buffers only when needed, as indicated by a stamp in the sarea.

This idea requires no extra dri2 or drm infrastructure, except perhaps 
for a way to arbitrate the per-sarea locks if a futex isn't used. (Some 
drm_lock.c code could be reused if needed). The existence and format of 
the per-drawable sareas would be up to the driver. In the case of the 
gallium state trackers it would be a matter of the dri- and xorg state 
tracker to agree upon existence and format of these sareas.

Since it seems some people regard sareas as something very evil I'd like 
to get some feedback on this!
It's only an idea at this stage.

/Thomas