[Mesa3d-dev] gallium-strict-aliasing branch merge
Hello, I'm planning to merge gallium-strict-aliasing branch soon, which will bring another gallium api change. pipe_reference function has different arguments, because the old version was pretty much not really useful for strict-aliasing compliant code (util_color_pack functions also gets an update for the same reason). The goal of course it to enable builds which do no longer need -fno-strict-aliasing. scons builds already didn't do this (which was a bug since the builds were indeed broken). I didn't check all drivers for strict-aliasing compliance, but for gallium everybody should make sure the code they are submitting is according to strict aliasing rules (*). One downside of compiling with -fno-strict-aliasing is also that you don't get the warnings wrt strict aliasing, so you might have missed that in the past. (There are no build system changes yet, there's still some strict aliasing violating code in shader/grammar which should get replaced soon anyway.) (*) Strictly speaking, it looks like c99 actually has undefined behaviour writing and reading different members of a union (wtf?), but this is considered acceptable here, and all compilers should support it. Roland -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Mesa 7.6.2 release candidate 3 and Mesa 7.7 release candidate 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mesa 7.6.1-rc3 available for testing at ftp://freedesktop.org/pub/mesa/7.6.1/ md5sums: e3953c0922e106d3bb17d8885aa6b381 MesaDemos-7.6.1-rc3.tar.bz2 7defc7f743df092379e7867c22c806f4 MesaDemos-7.6.1-rc3.tar.gz 24e143039540f744ada492946fea6afa MesaDemos-7.6.1-rc3.zip 147950cefe8697267d199ab7ab1233e4 MesaGLUT-7.6.1-rc3.tar.bz2 e8e93a519f07384c4c0e565505dbb3f6 MesaGLUT-7.6.1-rc3.tar.gz 17fd8141a7faff55aa8e2d2d0bb1e58a MesaGLUT-7.6.1-rc3.zip 555f593b0928471836ed77fccd93be39 MesaLib-7.6.1-rc3.tar.bz2 dcfaa8e4c1d7f9bc7083ac1558a48837 MesaLib-7.6.1-rc3.tar.gz 0827fb672e5186fba09e9401696568c1 MesaLib-7.6.1-rc3.zip Mesa 7.7-rc2 available for testing at ftp://freedesktop.org/pub/mesa/7.7/ md5sums: 7d24f141f0396177103b9b7cadc98c19 MesaDemos-7.7-rc2.tar.bz2 05285a8b0a701d1e0a4c12917a8c81a3 MesaDemos-7.7-rc2.tar.gz b70e92f8555681df20127b5180ce5cef MesaDemos-7.7-rc2.zip fc4b3d796eeb57abbe2dcb66a45b7ed3 MesaGLUT-7.7-rc2.tar.bz2 4ce18df198681e45b60ec89cde9ca988 MesaGLUT-7.7-rc2.tar.gz 6e9f7f95c2215423ec5316af798aa5ba MesaGLUT-7.7-rc2.zip 516ed92eab0c230c3606623437b014bf MesaLib-7.7-rc2.tar.bz2 d2aa216524346304c5277d00347e94a3 MesaLib-7.7-rc2.tar.gz c896ddaec3416cbfd1f1cb793e86271b MesaLib-7.7-rc2.zip I'm expecting one more release candidate of 7.6.1 and 7.7 next Monday, and a final release no later than 12/21. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksdr6sACgkQX1gOwKyEAw8mmwCePlxWJgk2Y0BZjKv5qd0cbfMO OOQAnjvlUh4NTeZGJkiRlvw+U1nm9Yae =uOgU -END PGP SIGNATURE- -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Forwarding... --- Begin Message --- It appears that R3xx-R4xx can sample from the Z16 format only. R5xx should be able to sample from both Z16 and Z24S8. References: http://aras-p.info/texts/D3D9GPUHacks.html Marek On Tue, Dec 8, 2009 at 12:31 AM, Brian Paul wrote: > OK, for the MESA_FORMAT_Z24_S8 case in r300SetDepthTexMode() the > 'format' pointer is set to the "X24_Y8" entries. > > If you read the comment for X24_Y8 in r300_reg.h it says: > >/* These two values are wrong, but they're the only values that > * produce any even vaguely correct results. Can r300 only do 16-bit > * depth textures? > */ > # define R300_TX_FORMAT_X24_Y80x1e > # define R300_TX_FORMAT_X32 0x1e > > Maybe the Z24_S8 case has never worked? > > Also, maybe radeonChooseTextureFormat() should be smarter about the > texture format it chooses for the depth/stencil formats. Right now, > MESA_FORMAT_S8_Z24 is the only one ever returned. > > -Brian > > > Maciej Cencora wrote: >> Depth/stencil buffer formats is a different thing (already fixed). Currently >> the >> problem is with depth textures. Formerly driver choose _mesa_texformat_s8_z24 >> for depth textures (radeonChooseTextureFormat in radeon_texture.c) then in >> r300SetDepthTexMode (r300_texstate.c) we set proper hw format (but I'm not >> sure how it worked because the texformat is _mesa_texformat_s8_z24 and there >> we checked for MESA_FORMAT_Z24_S8 ???). That setup worked somehow. >> Now you've changed the case in r300SetDepthTexMode from MESA_FORMAT_Z24_S8 to >> MESA_FORMAT_S8_Z24 and it stopped working. >> >> I'm using r300 driver (rv380 card). The piglit output is partially random. >> The >> background is black, and sometimes there's white rectangle on top of it >> (random size and placement). >> >> Regards, >> Maciej >> >> Dnia poniedziałek, 7 grudnia 2009 o 22:36:19 Brian Paul napisał(a): >>> The main thing is to choose the z/stencil format that's supported by >>> the hardware. As I mentioned before, it looks like different >>> generations of ATI/radeon hardware used different formats. It sounds >>> like that should be resolved now though. >>> >>> What does piglit's texdepth rendering look like? Which driver are you >>> using? >>> >>> -Brian >>> >>> Maciej Cencora wrote: I've worked some more on the texdepth problem, and looks like it works as long I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8, S8_Z24, X8_Z24 formats seems to work. Has anything changed regarding storing images in these formats? Regards, Maciej Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a): > OK, I've committed your patch. > > -Brian > > Maciej Cencora wrote: >> Yes, with attached glean/readPixSanity test is passing now. The only >> regressed test now is texturing/texdepth but I believe that something >> else must have broken it. >> >> Regards, >> Maciej >> >> Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a): >>> Do Michel's recents commits help with these? >>> >>> -Brian >>> >>> Maciej Cencora wrote: There's certainly a progress. Now only glean/readPixSanity and texturing/texDepth tests are failing. I've checked glean/readPixSanity and it's failing for 24bit depth buffer (no stencil buffer) visuals. I've tried modifying radeon_span.c code but without a luck. I'm attaching the patch I've used. Regards, Maciej Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a): > Please update your Mesa from git. I fixed the assertion at line 123 > yesterday. > > -Brian > > On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora > wrote: >> I've tried your patch (+some minor fixes to make it work) but >> running texdepth with it results in failing assertion rb->Format >> == MESA_FORMAT_X8_Z24 (s_readpix.c:123). >> I've also tried modifying span functions to convert between Z24_S8 >> (hw format) to S8_Z24 (mesa format) but wasn't able to get correct >> result. Any other ideas? >> >> Maciej >> >> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a): >>> I think the problem is confusion between MESA_FORMAT_Z24_S8 and >>> MESA_FORMAT_S8_Z24 in the radeon drivers. >>> >>> Looking at the span code, it appears that R300, R200 use Z24_S8 >>> format while R600 and others use S8_Z24. >>> >>> Here's a patch that attempts to fix things. I don't have radeon >>> hardware to test so maybe someone else can start with this and >>> finish it up. >>> >>> -Brian >>> >>> 2009/11/11 Maciej Cencora : I've checked
Re: [Mesa3d-dev] texformat-rework branch
OK, for the MESA_FORMAT_Z24_S8 case in r300SetDepthTexMode() the 'format' pointer is set to the "X24_Y8" entries. If you read the comment for X24_Y8 in r300_reg.h it says: /* These two values are wrong, but they're the only values that * produce any even vaguely correct results. Can r300 only do 16-bit * depth textures? */ # define R300_TX_FORMAT_X24_Y80x1e # define R300_TX_FORMAT_X32 0x1e Maybe the Z24_S8 case has never worked? Also, maybe radeonChooseTextureFormat() should be smarter about the texture format it chooses for the depth/stencil formats. Right now, MESA_FORMAT_S8_Z24 is the only one ever returned. -Brian Maciej Cencora wrote: > Depth/stencil buffer formats is a different thing (already fixed). Currently > the > problem is with depth textures. Formerly driver choose _mesa_texformat_s8_z24 > for depth textures (radeonChooseTextureFormat in radeon_texture.c) then in > r300SetDepthTexMode (r300_texstate.c) we set proper hw format (but I'm not > sure how it worked because the texformat is _mesa_texformat_s8_z24 and there > we checked for MESA_FORMAT_Z24_S8 ???). That setup worked somehow. > Now you've changed the case in r300SetDepthTexMode from MESA_FORMAT_Z24_S8 to > MESA_FORMAT_S8_Z24 and it stopped working. > > I'm using r300 driver (rv380 card). The piglit output is partially random. > The > background is black, and sometimes there's white rectangle on top of it > (random size and placement). > > Regards, > Maciej > > Dnia poniedziałek, 7 grudnia 2009 o 22:36:19 Brian Paul napisał(a): >> The main thing is to choose the z/stencil format that's supported by >> the hardware. As I mentioned before, it looks like different >> generations of ATI/radeon hardware used different formats. It sounds >> like that should be resolved now though. >> >> What does piglit's texdepth rendering look like? Which driver are you >> using? >> >> -Brian >> >> Maciej Cencora wrote: >>> I've worked some more on the texdepth problem, and looks like it works as >>> long I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8, >>> S8_Z24, X8_Z24 formats seems to work. Has anything changed regarding >>> storing images in these formats? >>> >>> Regards, >>> Maciej >>> >>> Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a): OK, I've committed your patch. -Brian Maciej Cencora wrote: > Yes, with attached glean/readPixSanity test is passing now. The only > regressed test now is texturing/texdepth but I believe that something > else must have broken it. > > Regards, > Maciej > > Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a): >> Do Michel's recents commits help with these? >> >> -Brian >> >> Maciej Cencora wrote: >>> There's certainly a progress. Now only glean/readPixSanity and >>> texturing/texDepth tests are failing. I've checked >>> glean/readPixSanity and it's failing for 24bit depth buffer (no >>> stencil buffer) visuals. I've tried modifying radeon_span.c code but >>> without a luck. >>> I'm attaching the patch I've used. >>> >>> Regards, >>> Maciej >>> >>> Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a): Please update your Mesa from git. I fixed the assertion at line 123 yesterday. -Brian On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora >>> wrote: > I've tried your patch (+some minor fixes to make it work) but > running texdepth with it results in failing assertion rb->Format > == MESA_FORMAT_X8_Z24 (s_readpix.c:123). > I've also tried modifying span functions to convert between Z24_S8 > (hw format) to S8_Z24 (mesa format) but wasn't able to get correct > result. Any other ideas? > > Maciej > > Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a): >> I think the problem is confusion between MESA_FORMAT_Z24_S8 and >> MESA_FORMAT_S8_Z24 in the radeon drivers. >> >> Looking at the span code, it appears that R300, R200 use Z24_S8 >> format while R600 and others use S8_Z24. >> >> Here's a patch that attempts to fix things. I don't have radeon >> hardware to test so maybe someone else can start with this and >> finish it up. >> >> -Brian >> >> 2009/11/11 Maciej Cencora : >>> I've checked the other failing tests. >>> Following were also passing before the texformat-rework merge: >>> fdo23670-drawpix_stencil >>> stencil-drawpixels >>> fragProg1 (Z write test) >>> readPixSanity >>> stencil2 >>> >>> Maciej >>> >>> Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a): It pas
Re: [Mesa3d-dev] texformat-rework branch
Depth/stencil buffer formats is a different thing (already fixed). Currently the problem is with depth textures. Formerly driver choose _mesa_texformat_s8_z24 for depth textures (radeonChooseTextureFormat in radeon_texture.c) then in r300SetDepthTexMode (r300_texstate.c) we set proper hw format (but I'm not sure how it worked because the texformat is _mesa_texformat_s8_z24 and there we checked for MESA_FORMAT_Z24_S8 ???). That setup worked somehow. Now you've changed the case in r300SetDepthTexMode from MESA_FORMAT_Z24_S8 to MESA_FORMAT_S8_Z24 and it stopped working. I'm using r300 driver (rv380 card). The piglit output is partially random. The background is black, and sometimes there's white rectangle on top of it (random size and placement). Regards, Maciej Dnia poniedziałek, 7 grudnia 2009 o 22:36:19 Brian Paul napisał(a): > The main thing is to choose the z/stencil format that's supported by > the hardware. As I mentioned before, it looks like different > generations of ATI/radeon hardware used different formats. It sounds > like that should be resolved now though. > > What does piglit's texdepth rendering look like? Which driver are you > using? > > -Brian > > Maciej Cencora wrote: > > I've worked some more on the texdepth problem, and looks like it works as > > long I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8, > > S8_Z24, X8_Z24 formats seems to work. Has anything changed regarding > > storing images in these formats? > > > > Regards, > > Maciej > > > > Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a): > >> OK, I've committed your patch. > >> > >> -Brian > >> > >> Maciej Cencora wrote: > >>> Yes, with attached glean/readPixSanity test is passing now. The only > >>> regressed test now is texturing/texdepth but I believe that something > >>> else must have broken it. > >>> > >>> Regards, > >>> Maciej > >>> > >>> Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a): > Do Michel's recents commits help with these? > > -Brian > > Maciej Cencora wrote: > > There's certainly a progress. Now only glean/readPixSanity and > > texturing/texDepth tests are failing. I've checked > > glean/readPixSanity and it's failing for 24bit depth buffer (no > > stencil buffer) visuals. I've tried modifying radeon_span.c code but > > without a luck. > > I'm attaching the patch I've used. > > > > Regards, > > Maciej > > > > Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a): > >> Please update your Mesa from git. I fixed the assertion at line 123 > >> yesterday. > >> > >> -Brian > >> > >> On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora > >> > > > > wrote: > >>> I've tried your patch (+some minor fixes to make it work) but > >>> running texdepth with it results in failing assertion rb->Format > >>> == MESA_FORMAT_X8_Z24 (s_readpix.c:123). > >>> I've also tried modifying span functions to convert between Z24_S8 > >>> (hw format) to S8_Z24 (mesa format) but wasn't able to get correct > >>> result. Any other ideas? > >>> > >>> Maciej > >>> > >>> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a): > I think the problem is confusion between MESA_FORMAT_Z24_S8 and > MESA_FORMAT_S8_Z24 in the radeon drivers. > > Looking at the span code, it appears that R300, R200 use Z24_S8 > format while R600 and others use S8_Z24. > > Here's a patch that attempts to fix things. I don't have radeon > hardware to test so maybe someone else can start with this and > finish it up. > > -Brian > > 2009/11/11 Maciej Cencora : > > I've checked the other failing tests. > > Following were also passing before the texformat-rework merge: > > fdo23670-drawpix_stencil > > stencil-drawpixels > > fragProg1 (Z write test) > > readPixSanity > > stencil2 > > > > Maciej > > > > Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a): > >> It passes with swrast and the i965 driver here. > >> > >> Did this test pass prior to the texformat work? > >> > >> -Brian > >> > >> 2009/11/10 Maciej Cencora : > >>> It doesn't assert anymore, but the test is still failing. > >>> > >>> @test: texturing/texdepth > >>> info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG > >>> build Nov 8 2009 21:21:48\nMesa warning: couldn\'t open > >>> libtxc_dxtn.so, software DXTn compression/decompression > >>> unavailable\nMesa: Initializing x86-64 optimizations\nMesa: > >>> 3Dnow! > >>> detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25 > >>> 0.25 0.25 1.00\n Observed: 0.00 0.
[Mesa3d-dev] [Bug 25500] Add linker option to mklib call
http://bugs.freedesktop.org/show_bug.cgi?id=25500 --- Comment #1 from Robert Schwebel 2009-12-07 13:39:06 PST --- Created an attachment (id=31828) --> (http://bugs.freedesktop.org/attachment.cgi?id=31828) patch to fix the issue -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25500] New: Add linker option to mklib call
http://bugs.freedesktop.org/show_bug.cgi?id=25500 Summary: Add linker option to mklib call Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: r.schwe...@pengutronix.de CC: m...@pengutronix.de When cross compiling, we have to handle the (cross-)linker to the mklib call. Signed-off-by: Marc Kleine-Budde Signed-off-by: Robert Schwebel -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
The main thing is to choose the z/stencil format that's supported by the hardware. As I mentioned before, it looks like different generations of ATI/radeon hardware used different formats. It sounds like that should be resolved now though. What does piglit's texdepth rendering look like? Which driver are you using? -Brian Maciej Cencora wrote: > I've worked some more on the texdepth problem, and looks like it works as > long > I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8, S8_Z24, > X8_Z24 formats seems to work. Has anything changed regarding storing images > in > these formats? > > Regards, > Maciej > > Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a): >> OK, I've committed your patch. >> >> -Brian >> >> Maciej Cencora wrote: >>> Yes, with attached glean/readPixSanity test is passing now. The only >>> regressed test now is texturing/texdepth but I believe that something >>> else must have broken it. >>> >>> Regards, >>> Maciej >>> >>> Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a): Do Michel's recents commits help with these? -Brian Maciej Cencora wrote: > There's certainly a progress. Now only glean/readPixSanity and > texturing/texDepth tests are failing. I've checked glean/readPixSanity > and it's failing for 24bit depth buffer (no stencil buffer) visuals. > I've tried modifying radeon_span.c code but without a luck. > I'm attaching the patch I've used. > > Regards, > Maciej > > Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a): >> Please update your Mesa from git. I fixed the assertion at line 123 >> yesterday. >> >> -Brian >> >> On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora > wrote: >>> I've tried your patch (+some minor fixes to make it work) but running >>> texdepth with it results in failing assertion rb->Format == >>> MESA_FORMAT_X8_Z24 (s_readpix.c:123). >>> I've also tried modifying span functions to convert between Z24_S8 >>> (hw format) to S8_Z24 (mesa format) but wasn't able to get correct >>> result. Any other ideas? >>> >>> Maciej >>> >>> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a): I think the problem is confusion between MESA_FORMAT_Z24_S8 and MESA_FORMAT_S8_Z24 in the radeon drivers. Looking at the span code, it appears that R300, R200 use Z24_S8 format while R600 and others use S8_Z24. Here's a patch that attempts to fix things. I don't have radeon hardware to test so maybe someone else can start with this and finish it up. -Brian 2009/11/11 Maciej Cencora : > I've checked the other failing tests. > Following were also passing before the texformat-rework merge: > fdo23670-drawpix_stencil > stencil-drawpixels > fragProg1 (Z write test) > readPixSanity > stencil2 > > Maciej > > Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a): >> It passes with swrast and the i965 driver here. >> >> Did this test pass prior to the texformat work? >> >> -Brian >> >> 2009/11/10 Maciej Cencora : >>> It doesn't assert anymore, but the test is still failing. >>> >>> @test: texturing/texdepth >>> info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG >>> build Nov 8 2009 21:21:48\nMesa warning: couldn\'t open >>> libtxc_dxtn.so, software DXTn compression/decompression >>> unavailable\nMesa: Initializing x86-64 optimizations\nMesa: >>> 3Dnow! >>> detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25 >>> 0.25 0.25 1.00\n Observed: 0.00 0.00 >>> 0.00 1.00\nTest failed: \'Render textures GL_LUMINANCE >>> (no shadow functionality)\'\nSee above for details.\n\n >>> errors! >>> >>> Maciej >>> >>> Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a): Can you try again with Mesa git/master? I've updated the assertions. -Brian On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora > wrote: > It is r300 driver (RV530 GPU). > > I'm sending the backtrace as attachement. > > Maciej > > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a): >> Which driver? >> >> Could you provide a stack trace for the failed assertion? >> >> -Brian >> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora >> >>> wrote: >>> Hi Brian,
[Mesa3d-dev] [Bug 25499] Add DESTDIR support to src/gallium/winsys/xlib/Makefile
http://bugs.freedesktop.org/show_bug.cgi?id=25499 Robert Schwebel changed: What|Removed |Added CC||m...@pengutronix.de -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25499] New: Add DESTDIR support to src/gallium/winsys/xlib/Makefile
http://bugs.freedesktop.org/show_bug.cgi?id=25499 Summary: Add DESTDIR support to src/gallium/winsys/xlib/Makefile Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: r.schwe...@pengutronix.de Created an attachment (id=31827) --> (http://bugs.freedesktop.org/attachment.cgi?id=31827) patch to fix the issue This makefile is not DESTDIR aware, the patch below fixes it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium3D Developers Workshop Now Online
Excellent news! Please update site as soon as possible. Topics are more than interesting. If you have some otherPDF documenation, book, or other materials (white papers,blueprints, etc.) you want to open to the public, pleasedo it since it is very important for us who are not at theepicenter of events and do not have resources to attendsuch conferences. Uros --- "Every kind of peaceful cooperation among men is primarily based on mutual trust and only secondarily on institutions such as courts of justice and police." - Albert Einstein (1879 - 1955) > From: j...@lunarg.com > To: mesa3d-dev@lists.sourceforge.net; dri-de...@lists.sourceforge.net > Subject: Gallium3D Developers Workshop Now Online > Date: Mon, 7 Dec 2009 12:49:43 -0700 > > Gallium3D Developers, > > The videos and slide decks from the Gallium3D Developers Workshop > hosted by VMware on Nov 13th are now being posted online at: > > > http://www.lunarg.com/wordpress/technologies/gallium-3d/gallium3d-online-developers-workshop/ > > More of the presentations will be posted to this page as they become > available. > > Don't hesitate to contact me directly if you have any questions about > the workshop material. > > Regards, > Jens Owen > > > -- > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > -- > ___ > Dri-devel mailing list > dri-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel _ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009-- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Gallium3D Developers Workshop Now Online
Gallium3D Developers, The videos and slide decks from the Gallium3D Developers Workshop hosted by VMware on Nov 13th are now being posted online at: http://www.lunarg.com/wordpress/technologies/gallium-3d/gallium3d-online-developers-workshop/ More of the presentations will be posted to this page as they become available. Don't hesitate to contact me directly if you have any questions about the workshop material. Regards, Jens Owen -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium: let drivers fallback on framebuffer clearing
Hi,
Because some hardware under some circumstances (e.g. disabled tiling)
may not be able to use a hardware-specific clear path, it would be
nice to let a state tracker do the clearing by drawing a
screen-aligned quad. I am proposing to change the pipe_context->clear
function to return TRUE if buffers were cleared by the driver, and
FALSE if the state tracker should do the clearing by taking a generic
path.
As an example, r300g can use the fast clearing only if colorbuffers
and zbuffers are micro-tiled, otherwise it must draw a screen-aligned
quad and doing it in the driver is really messy.
The attached patch implements this interface change and adapts all
state trackers and drivers.
I noticed that a lot of drivers still use slow util_clear, so they
will greatly benefit from this patch. It's up to their maintainers
whether they enable it, I suspect some unstable drivers may not be
able to draw a quad without visual errors.
Please review.
Best regards
Marek Olšák
From a6d16e7bce330900d496593054ec6aeb3ed51a2f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?=
Date: Mon, 7 Dec 2009 00:33:17 +0100
Subject: [PATCH] gallium: let drivers fallback on framebuffer clearing
A driver can either clear a framebuffer by itself or can tell the state tracker
to draw a screen-aligned quad if a hardware-specific clear path is not
available.
---
src/gallium/drivers/cell/ppu/cell_clear.c|4 +++-
src/gallium/drivers/cell/ppu/cell_clear.h|3 ++-
src/gallium/drivers/i915/i915_clear.c|3 ++-
src/gallium/drivers/i915/i915_context.h |4 ++--
src/gallium/drivers/identity/id_context.c| 12 ++--
src/gallium/drivers/llvmpipe/lp_clear.c |4 +++-
src/gallium/drivers/llvmpipe/lp_clear.h |2 +-
src/gallium/drivers/nv04/nv04_clear.c| 10 ++
src/gallium/drivers/nv04/nv04_context.h |4 ++--
src/gallium/drivers/nv10/nv10_clear.c|3 ++-
src/gallium/drivers/nv10/nv10_context.h |2 +-
src/gallium/drivers/nv20/nv20_clear.c|3 ++-
src/gallium/drivers/nv20/nv20_context.h |2 +-
src/gallium/drivers/nv30/nv30_clear.c|3 ++-
src/gallium/drivers/nv30/nv30_context.h |2 +-
src/gallium/drivers/nv40/nv40_clear.c|3 ++-
src/gallium/drivers/nv40/nv40_context.h |2 +-
src/gallium/drivers/nv50/nv50_clear.c|4 +++-
src/gallium/drivers/nv50/nv50_context.h |2 +-
src/gallium/drivers/r300/r300_clear.c| 11 ++-
src/gallium/drivers/r300/r300_clear.h| 12 +++-
src/gallium/drivers/softpipe/sp_clear.c |5 +++--
src/gallium/drivers/softpipe/sp_clear.h |2 +-
src/gallium/drivers/svga/svga_context.h | 10 +-
src/gallium/drivers/svga/svga_pipe_clear.c |3 ++-
src/gallium/drivers/trace/tr_context.c |7 +--
src/gallium/include/pipe/p_context.h |4 +++-
src/gallium/state_trackers/vega/api_masks.c | 11 +++
src/gallium/state_trackers/vega/vg_context.c |6 +-
src/gallium/state_trackers/vega/vg_tracker.c |8 ++--
src/gallium/state_trackers/xorg/xorg_exa.c |7 +--
src/mesa/state_tracker/st_cb_clear.c | 12 +---
32 files changed, 107 insertions(+), 63 deletions(-)
diff --git a/src/gallium/drivers/cell/ppu/cell_clear.c b/src/gallium/drivers/cell/ppu/cell_clear.c
index 79ad687..553d924 100644
--- a/src/gallium/drivers/cell/ppu/cell_clear.c
+++ b/src/gallium/drivers/cell/ppu/cell_clear.c
@@ -48,7 +48,7 @@
/**
* Called via pipe->clear()
*/
-void
+boolean
cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
double depth, unsigned stencil)
{
@@ -89,4 +89,6 @@ cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
clr->surface = surfIndex;
clr->value = clearValue;
}
+
+ return TRUE;
}
diff --git a/src/gallium/drivers/cell/ppu/cell_clear.h b/src/gallium/drivers/cell/ppu/cell_clear.h
index 08e091a..9fc3a01 100644
--- a/src/gallium/drivers/cell/ppu/cell_clear.h
+++ b/src/gallium/drivers/cell/ppu/cell_clear.h
@@ -29,11 +29,12 @@
#ifndef CELL_CLEAR_H
#define CELL_CLEAR_H
+#include "pipe/p_compiler.h"
struct pipe_context;
-extern void
+extern boolean
cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
double depth, unsigned stencil);
diff --git a/src/gallium/drivers/i915/i915_clear.c b/src/gallium/drivers/i915/i915_clear.c
index 90530f2..21528e5 100644
--- a/src/gallium/drivers/i915/i915_clear.c
+++ b/src/gallium/drivers/i915/i915_clear.c
@@ -39,10 +39,11 @@
* Clear the given buffers to the specified values.
* No masking, no scissor (clear entire buffer).
*/
-void
+boolean
i915_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
double depth, unsigned stencil)
{
util_clear(pipe, &i915_context(pipe)->framebuffer, buffers, rgba, depth,
stencil
