On Sat, 2004-11-20 at 21:30 +0100, Jacek Rosik wrote: > > Dnia 19-11-2004, piÄ o godzinie 12:24 -0500, Michel DÃnzer napisaÅ(a): > > On Fri, 2004-11-19 at 12:51 +0100, Jacek Rosik wrote: > > > > > > For now I would also vote for #2. This could help some other things (eg. > > > GLcore could render directly into back buffer). But I think we need > > > combination of both. Method #2 won't do for stereo. There You have two > > > frontbuffers and everything rendered by X server should appear in both > > > buffers. > > > > How is that different from page flipping, where the X rendering has to > > appear in all buffers as well? > > As Keith wrote, the problem is when you combine X drawing with GL > drawing. For current page flipping we have front and back buffers. When > we do some X drawing it should appear in *current* front buffer (it may > actually be front or back if pages are flipped). This drawing should not > appear in back buffer, as X doesn't know about back buffer and it may > destroy GL image in back. For stereo we have two front buffers and two > back buffers. X drawing has to appear in both front buffers. Simple > dirty rectangle copying from left buffer will not work as it may destroy > contents of left buffer which may be different, we should draw things > twice.
I see. I thought a generalization of what I proposed for page flipping might still work though: Check whether the target coordinates of a 2D operation lie within the virtual screen dimensions, and if they do, repeat them for both current front buffers. Then for page flipping, in the shadowfb callback, copy the dirty rectangles outside of the 3D window(s) from the current front buffer(s) to the current back buffer(s). Of course, only now do I remember why my 'clever trick' doesn't work: It doesn't deal with X software rendering outside of the driver. Oh well. > > > BTW: What is the reason that fb has alway width equal to virtual desktop > > > width (pScrn->displayWidth)? I think that Alan Hourihane said that > > > different width would screw up accelerator. But I don't see why. > > > > The accelerator imposes restrictions on the alignment of the pitch, so > > they're actually not always the same but happen to be for most > > resolutions commonly used today. > > So accelerator may work on some fixed set of pitches if I understand > properly. Yes, basically the multiples of the required alignment, within a certain range. > > Curious, why would you want a pitch that's larger than the required > > minimum? > > I was just curious too ;). For stereo we have four color buffers so we > use a lot of pixmap cache. I thought that placing left buffers left will > leave more pixmap cache for X. You mean placing the buffers side by side instead of one after another? One problem with that is the accelerator also requires the start of the buffer to be aligned (as a side note, both requirements become stricter with tiling). Of course, that can be dealt with, but I'm not sure that XAA will use the pixmap cache beyond the virtual width at all. Also, the second front buffer doesn't have to lie in the pixmap cache area in the first place. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
