Re: dri triple buffering?
Hi! Dnia 19-11-2004, pi o godzinie 12:24 -0500, Michel Dnzer napisa(a): On Fri, 2004-11-19 at 12:51 +0100, Jacek Rosik wrote: Am Fr, den 19.11.2004 schrieb Keith Whitwell um 12:14: 1) Do all drawing three times, avoiding the rectangle-blits and possible corruption. or 2) Make the X server do its drawing to the current frontbuffer (rather than just buffer 0), and then do the shadow-blits from that buffer. 2) is the more appealing option for me. I'm not sure how to get it to work in the context of the XAA pixmap cache which seems to be indexed from the same origin as X's idea of the frontbuffer. The 2D acceleration hooks could check whether the coordinates are within the virtual screen size and adjust the buffer offsets accordingly. Nasty, but seems feasible. 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. 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. 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. I was thinking also about allocating more than one depth/stencil buffer which would reduce reduce amount of pixmap cache further. Best, -- Jacek Rosik [EMAIL PROTECTED] --- 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
Re: dri triple buffering?
On Sat, 2004-11-20 at 21:30 +0100, Jacek Rosik wrote: Dnia 19-11-2004, pi o godzinie 12:24 -0500, Michel Dnzer 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 Dnzer | 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
Re: dri triple buffering?
Dave Airlie wrote: I've got my internal app currently running with vblank_mode=2 at 60Hz, if I put in vblank_mode=3 I get a drop to about 40Hz which is no good for what I need I'm told that triple buffering might be the solution to this, does anyone know how much work this would be to implement in the radeon/r200 drivers? or dri in general? Initially I'd like to do it for a single full screen app (my case) and not worry about the issues with multiple apps... I would assume I need to allocate a 3rd buffer (wayback buffer...) in VRAM and have the bufferswap take an extra step to go wayback-back-front.. I'm pretty interested to see how much difference triple buffering makes. I used to be somewhat skeptical, but recently I've had that view challenged... The obvious way to implement it is to extend the current mechanism to allocate another shared buffer at X server startup and add one more blit destination to the pageflipping code. As Alan points out, we blit the dirty regions to the back buffer rather than re-rendering everything multiple times. This was the easiest scheme to implement, and has a big speed advantage for fallback and complex rendering. It is however the reason that the current page-flipping code isn't strictly conformant, as the situation where X11 and GL rendering to the same drawable simultaneously isn't handled correctly in all circumstances. I expect that there will be a bunch of annoying compatiblity, etc problems in the drm and dri interfaces to do with getting the information to the client, etc, where the assumption has been made that there are only 2 buffers. Keith --- 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
Re: dri triple buffering?
Hi! Am Fr, den 19.11.2004 schrieb Keith Whitwell um 10:50: As Alan points out, we blit the dirty regions to the back buffer rather than re-rendering everything multiple times. This was the easiest scheme to implement, and has a big speed advantage for fallback and complex rendering. It is however the reason that the current page-flipping code isn't strictly conformant, as the situation where X11 and GL rendering to the same drawable simultaneously isn't handled correctly in all circumstances. Do You mean that X rendering should go only into front buffer. I tried to fix that situation. I just skip shadowfb updates to areas covered by 3d windows, this was necessary to solve some problems with moving windows and stereo. I expect that there will be a bunch of annoying compatibility, etc problems in the drm and dri interfaces to do with getting the information to the client, etc, where the assumption has been made that there are only 2 buffers. Actually I don't think this would be really hard. I have added to additional buffers (front right, and back right) in radeon driver and only few places in mesa driver needed modifications. Currently page flipping and stereo are exclusive due to some race issues, but this could be fixed using radeon registers for stereo and would have nothing to do with tripple buffering. Actually I even had a version with stereo and pageflipping working simultaneously. You can take a look at my patches: http://stud.ics.p.lodz.pl/~paproch/dri-stereo Maybe You will find some helpful informations. best, -- Jacek Rosik [EMAIL PROTECTED] --- 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
Re: dri triple buffering?
Jacek Rosik wrote: Hi! Am Fr, den 19.11.2004 schrieb Keith Whitwell um 10:50: As Alan points out, we blit the dirty regions to the back buffer rather than re-rendering everything multiple times. This was the easiest scheme to implement, and has a big speed advantage for fallback and complex rendering. It is however the reason that the current page-flipping code isn't strictly conformant, as the situation where X11 and GL rendering to the same drawable simultaneously isn't handled correctly in all circumstances. Do You mean that X rendering should go only into front buffer. I tried to fix that situation. I just skip shadowfb updates to areas covered by 3d windows, this was necessary to solve some problems with moving windows and stereo. Well, X rendering needs to be propogated to all three buffers somehow. The problem with the current situation is that the 'real' rendering only happens on buffer 0, and the dirty rectangle is blitted to the other buffers. Imagine you are doing Xlib drawing to a window which is also being used for OpenGL frontbuffer rendering - this works OK if buffer 0 is the frontbuffer (or if you aren't pageflipping), but if say buffer 1 is the current frontbuffer, when the dirty rectangle is blitted from buffer 0, the whole rectangle will overwrite whatever GL rendering had been going on. There are two ways I can see to fix this: 1) Do all drawing three times, avoiding the rectangle-blits and possible corruption. or 2) Make the X server do its drawing to the current frontbuffer (rather than just buffer 0), and then do the shadow-blits from that buffer. 2) is the more appealing option for me. I'm not sure how to get it to work in the context of the XAA pixmap cache which seems to be indexed from the same origin as X's idea of the frontbuffer. Keith --- 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
Re: dri triple buffering?
Hi! Am Fr, den 19.11.2004 schrieb Keith Whitwell um 12:14: Well, X rendering needs to be propogated to all three buffers somehow. The problem with the current situation is that the 'real' rendering only happens on buffer 0, and the dirty rectangle is blitted to the other buffers. Imagine you are doing Xlib drawing to a window which is also being used for OpenGL frontbuffer rendering - this works OK if buffer 0 is the frontbuffer (or if you aren't pageflipping), but if say buffer 1 is the current frontbuffer, when the dirty rectangle is blitted from buffer 0, the whole rectangle will overwrite whatever GL rendering had been going on. There are two ways I can see to fix this: 1) Do all drawing three times, avoiding the rectangle-blits and possible corruption. or 2) Make the X server do its drawing to the current frontbuffer (rather than just buffer 0), and then do the shadow-blits from that buffer. 2) is the more appealing option for me. I'm not sure how to get it to work in the context of the XAA pixmap cache which seems to be indexed from the same origin as X's idea of the frontbuffer. 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. But I presume that implementing #1 may be quite hard. If I find time this weekend I will try to modify my radeon ddx to allocate any number of color buffers and render into any of them. 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. best, -- Jacek Rosik [EMAIL PROTECTED] --- 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
Re: dri triple buffering?
On Fri, 2004-11-19 at 12:51 +0100, Jacek Rosik wrote: Am Fr, den 19.11.2004 schrieb Keith Whitwell um 12:14: 1) Do all drawing three times, avoiding the rectangle-blits and possible corruption. or 2) Make the X server do its drawing to the current frontbuffer (rather than just buffer 0), and then do the shadow-blits from that buffer. 2) is the more appealing option for me. I'm not sure how to get it to work in the context of the XAA pixmap cache which seems to be indexed from the same origin as X's idea of the frontbuffer. The 2D acceleration hooks could check whether the coordinates are within the virtual screen size and adjust the buffer offsets accordingly. Nasty, but seems feasible. 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? 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. Curious, why would you want a pitch that's larger than the required minimum? -- Earthling Michel Dnzer | 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
dri triple buffering?
I've got my internal app currently running with vblank_mode=2 at 60Hz, if I put in vblank_mode=3 I get a drop to about 40Hz which is no good for what I need I'm told that triple buffering might be the solution to this, does anyone know how much work this would be to implement in the radeon/r200 drivers? or dri in general? Initially I'd like to do it for a single full screen app (my case) and not worry about the issues with multiple apps... I would assume I need to allocate a 3rd buffer (wayback buffer...) in VRAM and have the bufferswap take an extra step to go wayback-back-front.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
Re: dri triple buffering?
Dave Airlie wrote: I've got my internal app currently running with vblank_mode=2 at 60Hz, if I put in vblank_mode=3 I get a drop to about 40Hz which is no good for what I need I'm told that triple buffering might be the solution to this, does anyone know how much work this would be to implement in the radeon/r200 drivers? or dri in general? Initially I'd like to do it for a single full screen app (my case) and not worry about the issues with multiple apps... I would assume I need to allocate a 3rd buffer (wayback buffer...) in VRAM and have the bufferswap take an extra step to go wayback-back-front.. The problem with that is the X-server will have to render everything 3 times. That's going to suck. You'll have some of the same problems that Jacek had with his stereo patch. A better sollution would be to forget pageflipping and have two back-buffers. The bufferswap routine would queue a blit from the current back-buffer to the front-buffer and switch back-buffers. You might want to coordinate some of this with Jacek. --- 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
Re: dri triple buffering?
The problem with that is the X-server will have to render everything 3 times. That's going to suck. You'll have some of the same problems that Jacek had with his stereo patch. hehe, that's why I was mentioning only doing it for full screen apps :-), I'm using solo in my application at the moment anyways... I've also not used pageflipping as the Radeon M7 chip seems to have issues with it... The bufferswap routine would queue a blit from the current back-buffer to the front-buffer and switch back-buffers. You might want to coordinate some of this with Jacek. I think a fix in my app has made the tearing less often, I might get away with it, I also realised triplebuffer is freerunning CPU user I would like to use some of my CPU for other processes :-) so blocking on the swap is useful feature... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
Re: dri triple buffering?
On Iau, 2004-11-18 at 23:22, Ian Romanick wrote: The problem with that is the X-server will have to render everything 3 times. That's going to suck. You'll have some of the same problems that Jacek had with his stereo patch. No the X server needs to render everything (expensive bit) _once_. It needs to blit it to the other surfaces (cheap) once per surface. Thats a very important distinction. Especially as the shadowfb code just happens to include all the needed rectangle list stuff... Alan --- 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
