On Thu, 2009-08-20 at 13:17 +0200, Thomas Hellstrom wrote: 
> 
> 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.

Does this affect real apps with sane framerates? With current intel and
radeon bits, gears runs in excess of 1000 fps with DRI2 here, so I'm
sceptical about this being a real problem.


> 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.

I think Kristian's plan for this is to introduce a DRI2 X protocol event
to indicate that the DRI2 buffer information has been invalidated.

Even without that, we only need a round-trip for buffer information if
the app calls something like glXMakeContextCurrent or glViewport for
windows, and in theory never for pixmaps (not implemented yet). Maybe
XvMC offers similar opportunities to avoid round-trips.


> 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.

The DRI2 buffer information passed from the X driver to the client
driver is completely up to the drivers, it could be a handle which
allows retrieving all of the above.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to