[Bug 14099] r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 Corbin Simpson mostawesomed...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Corbin Simpson mostawesomed...@gmail.com 2010-03-19 16:45:51 PST --- Closing as FIXED, to the extent that it can be fixed. :3 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14099] r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 --- Comment #4 from Jerome Glisse [EMAIL PROTECTED] 2008-01-18 07:11:04 PST --- (In reply to comment #2) If you really have private render buffers, those will be as big as needed and not bigger, so pitch shouldn't be above 2560 (I think this was the correct number?) if your rendering area (I assume this really means the size of your window in which 3d rendering happens) isn't larger. Blitter can copy to the larger real framebuffer just fine (up to 8k). If you want compiz on dual 23 screen you need a viewport bigger than 2560 (at least from 23 native resolution 1920*2=3840) so the rendering area is bigger than 2560. Anyway after thinking a bit to that, the work around might be easier. Basicly you have your big private 3840*1200 render buffer (2x23 case) then you do rendering to first 2560*1200 (set pitch to 3840) then add add a screen translation of -2560 to rendering command and a clip above 3840 and finaly do rendering but add 2560 to render buffer offset. This should work. It needs to be tested but i believe this should work properly. Drawback of this solution is that it's specific to radeon and might not work with other hw. The common solution would be to split the viewport in tile no bigger than hw reported limit and ask a blitter to blit to the final buffer. This is based on the assumption that 3d max pitch 2d max pitch which might not be the case on all cards. Anyway we can't work around the maximum 2d hw pitch (maximum scan out buffer pitch). So i got mixed feeling on this, especially as working around glviewport limit isn't enough for the biggest user i see (compiz) as you also need to work around 2d texture size limit and working around this one sounds really tricky. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14099] r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 Jerome Glisse [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from Jerome Glisse [EMAIL PROTECTED] 2008-01-16 09:27:52 PST --- Well it'snt as easy as that. I think that what ever is the pitch (8192 is hw limit on r300/r400 hw i think) the rendering will be broken above 2650 pixels so to work around this you would have to allocate several small render buffer and then blit then in a bigger one (pitch now becoming the upper limit). I haven't time to checkout that render if broken what ever we do above 2650, to check this disable cliprect and clip things in drm at top of r300_cmd.c and try with a big enough window if things appear properly above 2650 then we might have somethings but this would imply a security risk at it would mean we need to disable clipping which we would hate to do. Private render buffer are needed if we want to have the split solution but i think this should be done in a driver independent way. As a side note iirc fglrx is broken too and can't render above 2650. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14099] r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 Roland Scheidegger [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #2 from Roland Scheidegger [EMAIL PROTECTED] 2008-01-16 09:34:55 PST --- (In reply to comment #1) Well it'snt as easy as that. I think that what ever is the pitch (8192 is hw limit on r300/r400 hw i think) the rendering will be broken above 2650 pixels so to work around this you would have to allocate several small render buffer and then blit then in a bigger one (pitch now becoming the upper limit). If you really have private render buffers, those will be as big as needed and not bigger, so pitch shouldn't be above 2560 (I think this was the correct number?) if your rendering area (I assume this really means the size of your window in which 3d rendering happens) isn't larger. Blitter can copy to the larger real framebuffer just fine (up to 8k). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14099] r300 should use private backbuffers
http://bugs.freedesktop.org/show_bug.cgi?id=14099 --- Comment #3 from Michel Dänzer [EMAIL PROTECTED] 2008-01-16 09:47:28 PST --- With the upcoming DRI2 rework, every driver will use private renderbuffers, and doing it before then isn't very practical. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
