Michel Dänzer wrote: > 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. > >
Perhaps not. It seems to mostly affect certain systems, perhaps where a TLB flush is very expensive. A little off the topic, gears framerate should be constant since it's GPU (usually swapbuffer) bound unless something really stupid is being done, or your processor is slow enough to make you GPU bound. Thats one of the reasons why gears sometimes _is_ a good benchmark. If a change to a driver makes gears run slower, you're either messing up your command stream with unnecessary commands, inserting unnecessary synchronizations or end up CPU bound. Also a lot of small changes that increases the CPU usage of our drivers are sooner or later bound to add up. If there exists simple solutions to get close to optimal, I believe those changes should be worth exploring. >> 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. > That would probably help. > 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. > The situation is a little more complicated there but it's hard to compete with a solution where you don't do any X calls at all during steady-state full-screen overlaid rendering. For composited rendering, the getBuffers() call is probably unnecessary, and everything could be handled in swapBuffers(). > > >> 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. > > Yes, that's exactly what I was requesting comments on: Drivers communicating handles to sareas. I'm not suggesting any changes to the DRI2 protocol itself, exept perhaps adding a sequence of tokens that are driver private. I'm not trying to impose sareas as a needed dri2 thing. The comments I've got so far and from IRC discussions are that sareas are unnecessary because the frequency of the roundtrips is too small, and there will hopefully be protocol events to make the frequency even lower. But at the same time, calling getBuffers() before (all?) flushes that touch the backbuffer will be necessary for pageflipping applications with the current pageflipping proposal. This seems inconsistent to me. Obviously if there is no motivation for using sareas, nobody would bother implementing them. But I haven't yet heard a single argument why they are a technically bad solution. Only arguments of the type "they can be avoided using....". What I guess I'm seeking an answer to: _If_ a driver finds a big benefit by using sareas. Is there something that makes them fundamentally bad or incompatible with current or future use of dri2? /Thomas ------------------------------------------------------------------------------ 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
