Re: [Mesa3d-dev] texformat-rework branch
On Fri, Dec 11, 2009 at 3:49 PM, Maciej Cencora m.cenc...@gmail.com wrote: Thanks for that info. Looks like Marek is right. R300 doesn't support packed depth stencil formats as sampler format, it can only render to such formats. The R500 cards supports these formats as sampler and render targets. I'm going to push a patch soon, that fixes the texdepth. There's just one thing I want to know before I do that. If some texture image format is GL_DEPTH_STENCIL_EXT and the texture is sampled from, does the value of stencil component of the image affects rendering or is only the depth component used and stencil component is skipped? Only the depth/Z value is used; stencil is ignored. -Brian -- 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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,
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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
Re: [Mesa3d-dev] texformat-rework branch
Forwarding... ---BeginMessage--- 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 bri...@vmware.com 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - --- --- --- --- - 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev --
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - --- --- --- --- - Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design,
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - --- --- --- --- - 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.
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - --- --- --- --- - Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev --- --- --- - 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev --- --- --- - 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment -
Re: [Mesa3d-dev] texformat-rework branch
Yes, it was passing right before the texformat-rework merge. 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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian -- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev --- --- --- - 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian -- --- --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev --- --- --- - 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Which driver? Could you provide a stack trace for the failed assertion? -Brian On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com wrote:
Hi Brian,
there's at least one more regression in the code.
Piglit's texdepth test is failing because of following assertion:
texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb-
InternalFormat == 0x81A6' failed.
There are also other regressions (mostly related to depth/stencil buffer)
but I'm not sure it's the texformat branch merge is to blame:
fdo23670-drawpix_stencil
stencil-drawpixels
fragProg1 (Z write test)
paths
polygonOffset
readPixSanity
stencil2
Regards,
Maciej
Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a):
Alex, Nicolai,
Would you guys please test the texformat-rework branch again?
If it looks OK, I'd like to merge to master soon, but probably not
until next week.
Thanks.
-Brian
--- --- Come build with us! The BlackBerry(R) Developer Conference in SF,
CA is the only developer event you need to attend this year. Jumpstart
your developing skills, take BlackBerry mobile applications to market
and stay ahead of the curve. Join us from November 9 - 12, 2009.
Register now! http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
-
- 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
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
gdb ./texdepth
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from
/home/maciej/radeon_developement/piglit/bin/texdepth...done.
(gdb) r
Starting program: /home/maciej/radeon_developement/piglit/bin/texdepth
[Thread debugging using libthread_db enabled]
Mesa: Mesa 7.7-devel DEBUG build Nov 8 2009 21:21:48
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
Mesa: 3Dnow! detected
Press 't' to cycle through test images
texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion
`rb-InternalFormat == 0x81A6' failed.
Program received signal SIGABRT, Aborted.
0x770c84b5 in *__GI_raise (sig=value optimized out) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt full
#0 0x770c84b5 in *__GI_raise (sig=value optimized out) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
pid = value optimized out
selftid = value optimized out
#1 0x770cbf50 in *__GI_abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = 0x73bc10ad, sa_sigaction
= 0x73bc10ad}, sa_mask = {__val = {140737339238472, 140737488329568, 122,
140737488329808,
140737338386886, 206158430232, 140737488329824, 140737488329600,
140737338297768, 206158430256, 140737488329848, 10599680, 123424,
7886488245735878258,
Re: [Mesa3d-dev] texformat-rework branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maciej Cencora wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. This seems to happen in some cases if the driver does not support GL_EXT_packed_depth_stencil. I was able to produce this (after fixing another bug) when running with indirect rendering on the i915 driver. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 There are a bunch of similar regressions reported in bugzilla. Pretty much all of the reports are against the i915 or i965 driver. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr5/AwACgkQX1gOwKyEAw91rACfZbPEU/VXStG+MWTCILrHJ/Fy kwUAoJ7wEDelyidlI6DwHg565r3EEFrr =Daem -END PGP SIGNATURE- -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - - 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian - --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- --- - 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
It passes with swrast and the i965 driver here. Did this test pass prior to the texformat work? -Brian 2009/11/10 Maciej Cencora m.cenc...@gmail.com: 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 m.cenc...@gmail.com 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 m.cenc...@gmail.com wrote: Hi Brian, there's at least one more regression in the code. Piglit's texdepth test is failing because of following assertion: texdepth: swrast/s_readpix.c:122: read_depth_pixels: Assertion `rb- InternalFormat == 0x81A6' failed. There are also other regressions (mostly related to depth/stencil buffer) but I'm not sure it's the texformat branch merge is to blame: fdo23670-drawpix_stencil stencil-drawpixels fragProg1 (Z write test) paths polygonOffset readPixSanity stencil2 Regards, Maciej Dnia piątek, 23 października 2009 o 23:23:34 Brian Paul napisał(a): Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian - --- --- --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- --- - 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Alex Deucher wrote: On Wed, Oct 28, 2009 at 11:44 PM, Brian Paul brian.e.p...@gmail.com wrote: OK, the merge is done. Here's a quick summary of the changes: * The old gl_texture_format struct is replaced by a new gl_format enum. * The new formats are defined in formats.h and all the helper functions are in formats.c * textures and renderbuffers now use the same format info/fields * some special case code for compressed vs. uncompressed textures was unified. * new XRGB and X8Z24 formats * removed swrast-only/GLchan texture formats I don't know of any regressions but I haven't tested all the DRI drivers. If anyone finds any problems, let me know (please provide details) and I'll help you ASAP. fbo_firecube spews the following: radeonSetSpanFunctions: bad format: 0x001C OK, should be fixed now. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Thu, Oct 29, 2009 at 9:49 AM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Wed, Oct 28, 2009 at 11:44 PM, Brian Paul brian.e.p...@gmail.com wrote: OK, the merge is done. Here's a quick summary of the changes: * The old gl_texture_format struct is replaced by a new gl_format enum. * The new formats are defined in formats.h and all the helper functions are in formats.c * textures and renderbuffers now use the same format info/fields * some special case code for compressed vs. uncompressed textures was unified. * new XRGB and X8Z24 formats * removed swrast-only/GLchan texture formats I don't know of any regressions but I haven't tested all the DRI drivers. If anyone finds any problems, let me know (please provide details) and I'll help you ASAP. fbo_firecube spews the following: radeonSetSpanFunctions: bad format: 0x001C OK, should be fixed now. Yep, that did it. thanks! Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
OK, the merge is done. Here's a quick summary of the changes: * The old gl_texture_format struct is replaced by a new gl_format enum. * The new formats are defined in formats.h and all the helper functions are in formats.c * textures and renderbuffers now use the same format info/fields * some special case code for compressed vs. uncompressed textures was unified. * new XRGB and X8Z24 formats * removed swrast-only/GLchan texture formats I don't know of any regressions but I haven't tested all the DRI drivers. If anyone finds any problems, let me know (please provide details) and I'll help you ASAP. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
perhaps?
diff --git a/src/mesa/swrast/s_triangle.c b/src/mesa/swrast/s_triangle.c
index 5ecc769..2fc7ec2 100644
--- a/src/mesa/swrast/s_triangle.c
+++ b/src/mesa/swrast/s_triangle.c
@@ -1101,13 +1101,15 @@ _swrast_choose_triangle( GLcontext *ctx )
#if CHAN_BITS != 8
USE(general_triangle);
#else
- if (format == MESA_FORMAT_RGBA !_mesa_little_endian())
+ if (format == MESA_FORMAT_RGBA
!_mesa_little_endian()) {
/* We only handle RGBA correctly on little endian
* in the optimized code above.
*/
USE(general_triangle);
- else
+ }
+ else {
USE(affine_textured_triangle);
+ }
#endif
}
}
On Wed, Oct 28, 2009 at 8:44 PM, Brian Paul brian.e.p...@gmail.com wrote:
OK, the merge is done.
Here's a quick summary of the changes:
* The old gl_texture_format struct is replaced by a new gl_format enum.
* The new formats are defined in formats.h and all the helper
functions are in formats.c
* textures and renderbuffers now use the same format info/fields
* some special case code for compressed vs. uncompressed textures was unified.
* new XRGB and X8Z24 formats
* removed swrast-only/GLchan texture formats
I don't know of any regressions but I haven't tested all the DRI
drivers. If anyone finds any problems, let me know (please provide
details) and I'll help you ASAP.
-Brian
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Done. Though I mistakenly attributed the patch to Chia-I Wu. Oops.
Thanks.
-Brian
On Wed, Oct 28, 2009 at 10:09 PM, Wil Reichert wil.reich...@gmail.com wrote:
perhaps?
diff --git a/src/mesa/swrast/s_triangle.c b/src/mesa/swrast/s_triangle.c
index 5ecc769..2fc7ec2 100644
--- a/src/mesa/swrast/s_triangle.c
+++ b/src/mesa/swrast/s_triangle.c
@@ -1101,13 +1101,15 @@ _swrast_choose_triangle( GLcontext *ctx )
#if CHAN_BITS != 8
USE(general_triangle);
#else
- if (format == MESA_FORMAT_RGBA
!_mesa_little_endian())
+ if (format == MESA_FORMAT_RGBA
!_mesa_little_endian()) {
/* We only handle RGBA correctly on little endian
* in the optimized code above.
*/
USE(general_triangle);
- else
+ }
+ else {
USE(affine_textured_triangle);
+ }
#endif
}
}
On Wed, Oct 28, 2009 at 8:44 PM, Brian Paul brian.e.p...@gmail.com wrote:
OK, the merge is done.
Here's a quick summary of the changes:
* The old gl_texture_format struct is replaced by a new gl_format enum.
* The new formats are defined in formats.h and all the helper
functions are in formats.c
* textures and renderbuffers now use the same format info/fields
* some special case code for compressed vs. uncompressed textures was
unified.
* new XRGB and X8Z24 formats
* removed swrast-only/GLchan texture formats
I don't know of any regressions but I haven't tested all the DRI
drivers. If anyone finds any problems, let me know (please provide
details) and I'll help you ASAP.
-Brian
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Wed, Oct 28, 2009 at 11:44 PM, Brian Paul brian.e.p...@gmail.com wrote: OK, the merge is done. Here's a quick summary of the changes: * The old gl_texture_format struct is replaced by a new gl_format enum. * The new formats are defined in formats.h and all the helper functions are in formats.c * textures and renderbuffers now use the same format info/fields * some special case code for compressed vs. uncompressed textures was unified. * new XRGB and X8Z24 formats * removed swrast-only/GLchan texture formats I don't know of any regressions but I haven't tested all the DRI drivers. If anyone finds any problems, let me know (please provide details) and I'll help you ASAP. fbo_firecube spews the following: radeonSetSpanFunctions: bad format: 0x001C Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Mon, Oct 26, 2009 at 3:06 PM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul bri...@vmware.com wrote: Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Most apps assert: radeon_create_renderbuffer: Unknown format 0x001b glxgears: main/renderbuffer.c:1981: _mesa_add_renderbuffer: Assertion `rb' failed. Here's a patch to try. That seems to fix it. Alex -Brian diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c b/src/mesa/drivers/dri/radeon/radeon_fbo.c index 4084682..fc0d312 100644 --- a/src/mesa/drivers/dri/radeon/radeon_fbo.c +++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c @@ -280,12 +280,17 @@ radeon_create_renderbuffer(gl_format format, __DRIdrawablePrivate *driDrawPriv) rrb-base.DataType = GL_UNSIGNED_SHORT; rrb-base._BaseFormat = GL_DEPTH_COMPONENT; break; + case MESA_FORMAT_X8_Z24: + rrb-base.DataType = GL_UNSIGNED_INT; + rrb-base._BaseFormat = GL_DEPTH_COMPONENT; + break; case MESA_FORMAT_S8_Z24: rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT; rrb-base._BaseFormat = GL_DEPTH_STENCIL; break; default: - fprintf(stderr, %s: Unknown format 0x%04x\n, __FUNCTION__, format); + fprintf(stderr, %s: Unknown format %s\n, + __FUNCTION__, _mesa_get_format_name(format)); _mesa_delete_renderbuffer(rrb-base); return NULL; } -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Mon, Oct 05, 2009 at 09:14:04PM -0600, Brian Paul wrote: The texformat-rework branch cleans up the texture format code. The gl_texture_format struct is replaced by a simple gl_format enum (see formats.h). This leads to assorted clean-ups in core mesa and the drivers. This is a step toward unifying and cleaning up the texture image and renderbuffer data structures. I am reading 3fa7db and 8c36ca. While GLchan-based formats are endian-neutral, the memory layout of formats like RGBA are affected by host endian. As a result, opt_sample_rgba_2d and others seem not respect the endian. -- Regards, olv -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul bri...@vmware.com wrote: Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Most apps assert: radeon_create_renderbuffer: Unknown format 0x001b glxgears: main/renderbuffer.c:1981: _mesa_add_renderbuffer: Assertion `rb' failed. Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Alex Deucher wrote: On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul bri...@vmware.com wrote: Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Most apps assert: radeon_create_renderbuffer: Unknown format 0x001b glxgears: main/renderbuffer.c:1981: _mesa_add_renderbuffer: Assertion `rb' failed. Here's a patch to try. -Brian diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c b/src/mesa/drivers/dri/radeon/radeon_fbo.c index 4084682..fc0d312 100644 --- a/src/mesa/drivers/dri/radeon/radeon_fbo.c +++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c @@ -280,12 +280,17 @@ radeon_create_renderbuffer(gl_format format, __DRIdrawablePrivate *driDrawPriv) rrb-base.DataType = GL_UNSIGNED_SHORT; rrb-base._BaseFormat = GL_DEPTH_COMPONENT; break; + case MESA_FORMAT_X8_Z24: + rrb-base.DataType = GL_UNSIGNED_INT; +rrb-base._BaseFormat = GL_DEPTH_COMPONENT; + break; case MESA_FORMAT_S8_Z24: rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT; rrb-base._BaseFormat = GL_DEPTH_STENCIL; break; default: - fprintf(stderr, %s: Unknown format 0x%04x\n, __FUNCTION__, format); + fprintf(stderr, %s: Unknown format %s\n, +__FUNCTION__, _mesa_get_format_name(format)); _mesa_delete_renderbuffer(rrb-base); return NULL; } -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Thanks. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Nicolai, I made some changes on the texformat-rework branch last night. Could you re-test? There may still be issues but I'll work with you to fix them. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul bri...@vmware.com wrote: Nicolai, I made some changes on the texformat-rework branch last night. Could you re-test? There may still be issues but I'll work with you to fix them. I did a quick test of the branch on r600. openarena works ok. However demos/teapot, rain, engine, and tests/zcomp, zdrawpix, zreaddraw all segfault with the following: GL_VERSION = 1.4 Mesa 7.7-devel GL_RENDERER = Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x001C Segmentation fault Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Alex Deucher wrote:
On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul bri...@vmware.com wrote:
Nicolai,
I made some changes on the texformat-rework branch last night. Could
you re-test? There may still be issues but I'll work with you to fix
them.
I did a quick test of the branch on r600. openarena works ok.
However demos/teapot, rain, engine, and tests/zcomp, zdrawpix,
zreaddraw all segfault with the following:
GL_VERSION = 1.4 Mesa 7.7-devel
GL_RENDERER = Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2
radeonSetSpanFunctions: bad format: 0x0003
radeonSetSpanFunctions: bad format: 0x0003
radeonSetSpanFunctions: bad format: 0x001C
Segmentation fault
Does the attached patch help?
-Brian
diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c
b/src/mesa/drivers/dri/radeon/radeon_fbo.c
index 21007d8..096ded2 100644
--- a/src/mesa/drivers/dri/radeon/radeon_fbo.c
+++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c
@@ -280,14 +280,14 @@ radeon_create_renderbuffer(GLenum format,
__DRIdrawablePrivate *driDrawPriv)
rrb-base._BaseFormat = GL_DEPTH_COMPONENT;
break;
case GL_DEPTH_COMPONENT24:
- rrb-base.Format = MESA_FORMAT_Z32;
- rrb-base.DataType = GL_UNSIGNED_INT;
-rrb-base._BaseFormat = GL_DEPTH_COMPONENT;
+ rrb-base.Format = MESA_FORMAT_S8_Z24;
+ rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT;
+rrb-base._BaseFormat = GL_DEPTH_STENCIL;
break;
case GL_DEPTH24_STENCIL8_EXT:
rrb-base.Format = MESA_FORMAT_S8_Z24;
rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT;
-rrb-base._BaseFormat = GL_STENCIL_INDEX;
+rrb-base._BaseFormat = GL_DEPTH_STENCIL;
break;
default:
fprintf(stderr, %s: Unknown format 0x%04x\n, __FUNCTION__,
format);
diff --git a/src/mesa/drivers/dri/radeon/radeon_span.c
b/src/mesa/drivers/dri/radeon/radeon_span.c
index 9cdcde1..2add8c3 100644
--- a/src/mesa/drivers/dri/radeon/radeon_span.c
+++ b/src/mesa/drivers/dri/radeon/radeon_span.c
@@ -848,9 +848,9 @@ static void radeonSetSpanFunctions(struct
radeon_renderbuffer *rrb)
{
if (rrb-base.Format == MESA_FORMAT_RGB565) {
radeonInitPointers_RGB565(rrb-base);
- } else if (rrb-base.Format == MESA_FORMAT_RGBA) { /* XXX */
+ } else if (rrb-base.Format == MESA_FORMAT_XRGB) {
radeonInitPointers_xRGB(rrb-base);
- } else if (rrb-base.Format == MESA_FORMAT_RGBA) {
+ } else if (rrb-base.Format == MESA_FORMAT_ARGB) {
radeonInitPointers_ARGB(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_ARGB) {
radeonInitPointers_ARGB(rrb-base);
@@ -858,7 +858,7 @@ static void radeonSetSpanFunctions(struct
radeon_renderbuffer *rrb)
radeonInitPointers_ARGB1555(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_Z16) {
radeonInitDepthPointers_z16(rrb-base);
- } else if (rrb-base.Format == GL_DEPTH_COMPONENT32) { /* XXX */
+ } else if (rrb-base.Format == MESA_FORMAT_X8_Z24) {
radeonInitDepthPointers_z24(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_S8_Z24) {
radeonInitDepthPointers_s8_z24(rrb-base);
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul bri...@vmware.com wrote:
Alex Deucher wrote:
On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul bri...@vmware.com wrote:
Nicolai,
I made some changes on the texformat-rework branch last night. Could
you re-test? There may still be issues but I'll work with you to fix
them.
I did a quick test of the branch on r600. openarena works ok.
However demos/teapot, rain, engine, and tests/zcomp, zdrawpix,
zreaddraw all segfault with the following:
GL_VERSION = 1.4 Mesa 7.7-devel
GL_RENDERER = Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2
radeonSetSpanFunctions: bad format: 0x0003
radeonSetSpanFunctions: bad format: 0x0003
radeonSetSpanFunctions: bad format: 0x001C
Segmentation fault
Does the attached patch help?
Yes, that fixes the segfaults. The tests/z* tests fail to render
correctly though. r600 span code probably needs to be changed to deal
with the new depth format changes.
Alex
-Brian
diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c
b/src/mesa/drivers/dri/radeon/radeon_fbo.c
index 21007d8..096ded2 100644
--- a/src/mesa/drivers/dri/radeon/radeon_fbo.c
+++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c
@@ -280,14 +280,14 @@ radeon_create_renderbuffer(GLenum format,
__DRIdrawablePrivate *driDrawPriv)
rrb-base._BaseFormat = GL_DEPTH_COMPONENT;
break;
case GL_DEPTH_COMPONENT24:
- rrb-base.Format = MESA_FORMAT_Z32;
- rrb-base.DataType = GL_UNSIGNED_INT;
- rrb-base._BaseFormat = GL_DEPTH_COMPONENT;
+ rrb-base.Format = MESA_FORMAT_S8_Z24;
+ rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT;
+ rrb-base._BaseFormat = GL_DEPTH_STENCIL;
break;
case GL_DEPTH24_STENCIL8_EXT:
rrb-base.Format = MESA_FORMAT_S8_Z24;
rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT;
- rrb-base._BaseFormat = GL_STENCIL_INDEX;
+ rrb-base._BaseFormat = GL_DEPTH_STENCIL;
break;
default:
fprintf(stderr, %s: Unknown format 0x%04x\n, __FUNCTION__,
format);
diff --git a/src/mesa/drivers/dri/radeon/radeon_span.c
b/src/mesa/drivers/dri/radeon/radeon_span.c
index 9cdcde1..2add8c3 100644
--- a/src/mesa/drivers/dri/radeon/radeon_span.c
+++ b/src/mesa/drivers/dri/radeon/radeon_span.c
@@ -848,9 +848,9 @@ static void radeonSetSpanFunctions(struct
radeon_renderbuffer *rrb)
{
if (rrb-base.Format == MESA_FORMAT_RGB565) {
radeonInitPointers_RGB565(rrb-base);
- } else if (rrb-base.Format == MESA_FORMAT_RGBA) { /* XXX */
+ } else if (rrb-base.Format == MESA_FORMAT_XRGB) {
radeonInitPointers_xRGB(rrb-base);
- } else if (rrb-base.Format == MESA_FORMAT_RGBA) {
+ } else if (rrb-base.Format == MESA_FORMAT_ARGB) {
radeonInitPointers_ARGB(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_ARGB) {
radeonInitPointers_ARGB(rrb-base);
@@ -858,7 +858,7 @@ static void radeonSetSpanFunctions(struct
radeon_renderbuffer *rrb)
radeonInitPointers_ARGB1555(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_Z16) {
radeonInitDepthPointers_z16(rrb-base);
- } else if (rrb-base.Format == GL_DEPTH_COMPONENT32) { /* XXX */
+ } else if (rrb-base.Format == MESA_FORMAT_X8_Z24) {
radeonInitDepthPointers_z24(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_S8_Z24) {
radeonInitDepthPointers_s8_z24(rrb-base);
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Alex Deucher wrote: On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul bri...@vmware.com wrote: Nicolai, I made some changes on the texformat-rework branch last night. Could you re-test? There may still be issues but I'll work with you to fix them. I did a quick test of the branch on r600. openarena works ok. However demos/teapot, rain, engine, and tests/zcomp, zdrawpix, zreaddraw all segfault with the following: GL_VERSION = 1.4 Mesa 7.7-devel GL_RENDERER = Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x001C Segmentation fault Does the attached patch help? Yes, that fixes the segfaults. OK, I'll commit that. More clean-up and simplification can be done (maybe tonight). The tests/z* tests fail to render correctly though. r600 span code probably needs to be changed to deal with the new depth format changes. Yes, the R600 WRITE_DEPTH() macro seems to change S8Z24 into Z24S8 (or vice versa). That shouldn't be needed any more. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Thu, Oct 22, 2009 at 2:24 PM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul bri...@vmware.com wrote: Nicolai, I made some changes on the texformat-rework branch last night. Could you re-test? There may still be issues but I'll work with you to fix them. I did a quick test of the branch on r600. openarena works ok. However demos/teapot, rain, engine, and tests/zcomp, zdrawpix, zreaddraw all segfault with the following: GL_VERSION = 1.4 Mesa 7.7-devel GL_RENDERER = Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x001C Segmentation fault Does the attached patch help? Yes, that fixes the segfaults. OK, I'll commit that. More clean-up and simplification can be done (maybe tonight). The tests/z* tests fail to render correctly though. r600 span code probably needs to be changed to deal with the new depth format changes. Yes, the R600 WRITE_DEPTH() macro seems to change S8Z24 into Z24S8 (or vice versa). That shouldn't be needed any more. I've pushed a fix. thanks, Alex -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Nicolai Hähnle wrote: Am Thursday 15 October 2009 22:50:21 schrieb Brian Paul: Nicolai Hähnle wrote: I sent the last mail a little too quickly: This seems to affect only certain programs, in particular I have seen it with Sauerbraten; Compiz on the other hand seems to work. I've committed another change that should fix that. Thank you. Indeed, the games and applications I've tested all work fine. Unfortunately, there's a problem with swrast access (in particular ReadPixels, which causes readPixSanity to fail). Can you clarify what each of the fields ::_BaseFormat, ::InternalFormat and ::Format are supposed to mean, and how they interact with GetRow, PutValues, etc.? (sorry for the slow reply) InternalFormat is the user value passed to glRenderbufferStorage. _BaseFormat is the InternalFormat boiled down to one of GL_RGBA, GL_DEPTH_COMPONENT, GL_STENCIL_INDEX, etc. Format is the actual hardware format for the buffer. The GetRow(), etc. functions generally return either RGBA or stencil or depth values according to _BaseFormat. The DataType field indicates the datatype for the values (GL_UNSIGNED_BYTE, GL_FLOAT, etc) passed through Get/PutRow(). My observations: 1. Your change to radeon_span.c indicates that you want GetRow to depend on ::Format, but ::Format does not distinguish between stencil and depth buffer access when Format == MESA_FORMAT_S8_Z24. Hmmm, it should be the equivalent of what we had before with the obsolete _ActualFormat field. When core Mesa needs to read Z or stencil values out of a combined Z+Stencil buffer we use renderbuffer adaptors which wrap the underlying buffer and make it look like a Z-only or Stencil-only buffer. See main/depthstencil.c. 2. The assertion in s_readpix.c:122 gets triggered because rb-InternalFormat == GL_DEPTH24_STENCIL8 happens. I think that assertion will need to be removed. At that point what does *rb look like (gdb: print *rb). 3. The stencil read code expects GetRow to return only stencil values even when ::Format is one of the mixed depth/stencil formats. Again, the renderbuffer depth/stencil adaptors above should take care of this. fb-_StencilBuffer should point to a stencil wrapper around the combined depth/stencil buffer. These wrappers are installed during framebuffer state validation in _mesa_update_depth_buffer() and _mesa_update_stencil_buffer(). I just noticed that tests/zreaddraw.c fails with the i965 driver. It may be something similar to the radeon issue. So what is really the way to go forward? It seems radeon_span.c should probably use ::_BaseFormat to decide whether Mesa wants depth or stencil access functions, use ::InternalFormat to decide the data type that Mesa wants to use (e.g. GL_DEPTH24_STENCIL8 and GL_DEPTH_COMPONENT24 both mean 24-bit Z values if _BaseFormat == GL_DEPTH_COMPONENT, whereas GL_DEPTH_COMPONENT16 means 16-bit Z values) and then pick the particular family of access functions based on the ::Format. Is that correct? Are there invariants of the form: If Format == MESA_FORMAT_S8_Z24, then InternalFormat is always GL_DEPTH24_STENCIL8? That example isn't true because the InternalFormat comes from the user and could be one of several values. One of the next steps I want to make after the texformat-rework is removing the Get/PutRow() functions and move toward a Map/Unmap model where drivers won't have to worry about span functions at all. The span functions go back to the very first version of Mesa circa 1993. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Am Thursday 15 October 2009 22:50:21 schrieb Brian Paul: Nicolai Hähnle wrote: I sent the last mail a little too quickly: This seems to affect only certain programs, in particular I have seen it with Sauerbraten; Compiz on the other hand seems to work. I've committed another change that should fix that. Thank you. Indeed, the games and applications I've tested all work fine. Unfortunately, there's a problem with swrast access (in particular ReadPixels, which causes readPixSanity to fail). Can you clarify what each of the fields ::_BaseFormat, ::InternalFormat and ::Format are supposed to mean, and how they interact with GetRow, PutValues, etc.? My observations: 1. Your change to radeon_span.c indicates that you want GetRow to depend on ::Format, but ::Format does not distinguish between stencil and depth buffer access when Format == MESA_FORMAT_S8_Z24. 2. The assertion in s_readpix.c:122 gets triggered because rb-InternalFormat == GL_DEPTH24_STENCIL8 happens. 3. The stencil read code expects GetRow to return only stencil values even when ::Format is one of the mixed depth/stencil formats. So what is really the way to go forward? It seems radeon_span.c should probably use ::_BaseFormat to decide whether Mesa wants depth or stencil access functions, use ::InternalFormat to decide the data type that Mesa wants to use (e.g. GL_DEPTH24_STENCIL8 and GL_DEPTH_COMPONENT24 both mean 24-bit Z values if _BaseFormat == GL_DEPTH_COMPONENT, whereas GL_DEPTH_COMPONENT16 means 16-bit Z values) and then pick the particular family of access functions based on the ::Format. Is that correct? Are there invariants of the form: If Format == MESA_FORMAT_S8_Z24, then InternalFormat is always GL_DEPTH24_STENCIL8? In addition to that, the mentioned assertion in s_readpix.c:122 needs to be relaxed in any case. cu, Nicolai Thanks for testing! -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Am Wednesday 14 October 2009 21:15:29 schrieb Brian Paul: Nicolai Hähnle wrote: Am Wednesday 14 October 2009 03:45:26 schrieb Brian Paul: On Mon, Oct 5, 2009 at 9:14 PM, Brian Paul brian.e.p...@gmail.com wrote: The texformat-rework branch cleans up the texture format code. The gl_texture_format struct is replaced by a simple gl_format enum (see formats.h). This leads to assorted clean-ups in core mesa and the drivers. This is a step toward unifying and cleaning up the texture image and renderbuffer data structures. There may be some regressions in the tdfx and savage drivers. If/when anyone complains I can help diagnose/fix the regressions. I'd like to merge this branch to master by the end of the week. Let me know if there's any concerns. I've been too busy to merge this to master, but hopefully soon. In the mean time, it'd be great if someone could test this branch with one of the radeon Rxxx drivers. Everything seems OK with the Intel drivers and gallium. Just tested on an R300, I get glxgears: main/formats.c:576: _mesa_get_format_bytes: Assertion `info- BytesPerBlock' failed. snip It may just be an issue of properly guarding the call in the driver, it might also be a sign of something deeper. Unfortunately I don't have the time to investigate right now. I've just committed a (hopeful) fix. Thank you; I re-tested, but go another such assertion in Sauerbraten, this time it seems to be coming from some other source of texture data: (gdb) bt #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb7bc16d0 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7bc3098 in *__GI_abort () at abort.c:88 #3 0xb7bba5ce in *__GI___assert_fail (assertion=0xb74a7811 info- BytesPerBlock, file=0xb74a77d6 main/formats.c, line=576, function=0xb74a77fa _mesa_get_format_bytes) at assert.c:78 #4 0xb729117a in _mesa_get_format_bytes (format=MESA_FORMAT_NONE) at main/formats.c:576 #5 0xb7240d78 in radeon_teximage (ctx=0x85a3e60, dims=2, target=3553, level=0, internalFormat=6409, width=256, height=256, depth=1, imageSize=0, format=6409, type=5121, pixels=0xad2fd70, packing=0x85b0da4, texObj=0x929d540, texImage=0xad00890, compressed=0) at radeon_texture.c:547 #6 0xb7241447 in radeonTexImage2D (ctx=0x85a3e60, target=3553, level=0, internalFormat=6409, width=256, height=256, border=0, format=6409, type=5121, pixels=0xad2fd70, packing=0x85b0da4, texObj=0x929d540, texImage=0xad00890) at radeon_texture.c:688 #7 0xb72e478b in _mesa_TexImage2D (target=3553, level=0, internalFormat=6409, width=256, height=256, border=0, format=6409, type=5121, pixels=0xad2fd70) at main/teximage.c:2316 cu, Nicolai -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
I sent the last mail a little too quickly: This seems to affect only certain programs, in particular I have seen it with Sauerbraten; Compiz on the other hand seems to work. cu, Nicolai Am Wednesday 14 October 2009 21:15:29 schrieb Brian Paul: Nicolai Hähnle wrote: Am Wednesday 14 October 2009 03:45:26 schrieb Brian Paul: On Mon, Oct 5, 2009 at 9:14 PM, Brian Paul brian.e.p...@gmail.com wrote: The texformat-rework branch cleans up the texture format code. The gl_texture_format struct is replaced by a simple gl_format enum (see formats.h). This leads to assorted clean-ups in core mesa and the drivers. This is a step toward unifying and cleaning up the texture image and renderbuffer data structures. There may be some regressions in the tdfx and savage drivers. If/when anyone complains I can help diagnose/fix the regressions. I'd like to merge this branch to master by the end of the week. Let me know if there's any concerns. I've been too busy to merge this to master, but hopefully soon. In the mean time, it'd be great if someone could test this branch with one of the radeon Rxxx drivers. Everything seems OK with the Intel drivers and gallium. Just tested on an R300, I get glxgears: main/formats.c:576: _mesa_get_format_bytes: Assertion `info- BytesPerBlock' failed. because that function seems to be called with a NONE format: (gdb) bt #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb7de86d0 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7dea098 in *__GI_abort () at abort.c:88 #3 0xb7de15ce in *__GI___assert_fail (assertion=0xb7bf57d1 info- BytesPerBlock, file=0xb7bf5796 main/formats.c, line=576, function=0xb7bf57ba _mesa_get_format_bytes) at assert.c:78 #4 0xb79df12e in _mesa_get_format_bytes (format=MESA_FORMAT_NONE) at main/formats.c:576 #5 0xb7979277 in radeon_bits_per_pixel (rb=0x83bcaf8) at radeon_common_context.c:499 #6 0xb79793ce in radeon_update_renderbuffers (context=0x805ff10, drawable=0x8059a00) at radeon_common_context.c:539 #7 0xb7979da7 in radeonMakeCurrent (driContextPriv=0x805ff10, driDrawPriv=0x8059a00, driReadPriv=0x8059a00) at radeon_common_context.c:739 #8 0xb794ae8e in driBindContext (pcp=0x805ff10, pdp=0x8059a00, prp=0x8059a00) at ../common/dri_util.c:206 #9 0xb7fafb24 in dri2BindContext (context=0x80588d8, draw=0x8059968, read=0x8059968) at dri2_glx.c:107 #10 0xb7f7998b in MakeContextCurrent (dpy=0x804e008, draw=52428802, read=52428802, gc=0x8059b00) at glxcurrent.c:378 #11 0xb7f79ce6 in glXMakeCurrent (dpy=0x804e008, draw=52428802, gc=0x8059b00) at glxcurrent.c:512 It may just be an issue of properly guarding the call in the driver, it might also be a sign of something deeper. Unfortunately I don't have the time to investigate right now. I've just committed a (hopeful) fix. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Nicolai Hähnle wrote: I sent the last mail a little too quickly: This seems to affect only certain programs, in particular I have seen it with Sauerbraten; Compiz on the other hand seems to work. I've committed another change that should fix that. Thanks for testing! -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Am Wednesday 14 October 2009 03:45:26 schrieb Brian Paul: On Mon, Oct 5, 2009 at 9:14 PM, Brian Paul brian.e.p...@gmail.com wrote: The texformat-rework branch cleans up the texture format code. The gl_texture_format struct is replaced by a simple gl_format enum (see formats.h). This leads to assorted clean-ups in core mesa and the drivers. This is a step toward unifying and cleaning up the texture image and renderbuffer data structures. There may be some regressions in the tdfx and savage drivers. If/when anyone complains I can help diagnose/fix the regressions. I'd like to merge this branch to master by the end of the week. Let me know if there's any concerns. I've been too busy to merge this to master, but hopefully soon. In the mean time, it'd be great if someone could test this branch with one of the radeon Rxxx drivers. Everything seems OK with the Intel drivers and gallium. Just tested on an R300, I get glxgears: main/formats.c:576: _mesa_get_format_bytes: Assertion `info- BytesPerBlock' failed. because that function seems to be called with a NONE format: (gdb) bt #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb7de86d0 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7dea098 in *__GI_abort () at abort.c:88 #3 0xb7de15ce in *__GI___assert_fail (assertion=0xb7bf57d1 info- BytesPerBlock, file=0xb7bf5796 main/formats.c, line=576, function=0xb7bf57ba _mesa_get_format_bytes) at assert.c:78 #4 0xb79df12e in _mesa_get_format_bytes (format=MESA_FORMAT_NONE) at main/formats.c:576 #5 0xb7979277 in radeon_bits_per_pixel (rb=0x83bcaf8) at radeon_common_context.c:499 #6 0xb79793ce in radeon_update_renderbuffers (context=0x805ff10, drawable=0x8059a00) at radeon_common_context.c:539 #7 0xb7979da7 in radeonMakeCurrent (driContextPriv=0x805ff10, driDrawPriv=0x8059a00, driReadPriv=0x8059a00) at radeon_common_context.c:739 #8 0xb794ae8e in driBindContext (pcp=0x805ff10, pdp=0x8059a00, prp=0x8059a00) at ../common/dri_util.c:206 #9 0xb7fafb24 in dri2BindContext (context=0x80588d8, draw=0x8059968, read=0x8059968) at dri2_glx.c:107 #10 0xb7f7998b in MakeContextCurrent (dpy=0x804e008, draw=52428802, read=52428802, gc=0x8059b00) at glxcurrent.c:378 #11 0xb7f79ce6 in glXMakeCurrent (dpy=0x804e008, draw=52428802, gc=0x8059b00) at glxcurrent.c:512 It may just be an issue of properly guarding the call in the driver, it might also be a sign of something deeper. Unfortunately I don't have the time to investigate right now. cu, Nicolai -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
Nicolai Hähnle wrote: Am Wednesday 14 October 2009 03:45:26 schrieb Brian Paul: On Mon, Oct 5, 2009 at 9:14 PM, Brian Paul brian.e.p...@gmail.com wrote: The texformat-rework branch cleans up the texture format code. The gl_texture_format struct is replaced by a simple gl_format enum (see formats.h). This leads to assorted clean-ups in core mesa and the drivers. This is a step toward unifying and cleaning up the texture image and renderbuffer data structures. There may be some regressions in the tdfx and savage drivers. If/when anyone complains I can help diagnose/fix the regressions. I'd like to merge this branch to master by the end of the week. Let me know if there's any concerns. I've been too busy to merge this to master, but hopefully soon. In the mean time, it'd be great if someone could test this branch with one of the radeon Rxxx drivers. Everything seems OK with the Intel drivers and gallium. Just tested on an R300, I get glxgears: main/formats.c:576: _mesa_get_format_bytes: Assertion `info- BytesPerBlock' failed. because that function seems to be called with a NONE format: (gdb) bt #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb7de86d0 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7dea098 in *__GI_abort () at abort.c:88 #3 0xb7de15ce in *__GI___assert_fail (assertion=0xb7bf57d1 info- BytesPerBlock, file=0xb7bf5796 main/formats.c, line=576, function=0xb7bf57ba _mesa_get_format_bytes) at assert.c:78 #4 0xb79df12e in _mesa_get_format_bytes (format=MESA_FORMAT_NONE) at main/formats.c:576 #5 0xb7979277 in radeon_bits_per_pixel (rb=0x83bcaf8) at radeon_common_context.c:499 #6 0xb79793ce in radeon_update_renderbuffers (context=0x805ff10, drawable=0x8059a00) at radeon_common_context.c:539 #7 0xb7979da7 in radeonMakeCurrent (driContextPriv=0x805ff10, driDrawPriv=0x8059a00, driReadPriv=0x8059a00) at radeon_common_context.c:739 #8 0xb794ae8e in driBindContext (pcp=0x805ff10, pdp=0x8059a00, prp=0x8059a00) at ../common/dri_util.c:206 #9 0xb7fafb24 in dri2BindContext (context=0x80588d8, draw=0x8059968, read=0x8059968) at dri2_glx.c:107 #10 0xb7f7998b in MakeContextCurrent (dpy=0x804e008, draw=52428802, read=52428802, gc=0x8059b00) at glxcurrent.c:378 #11 0xb7f79ce6 in glXMakeCurrent (dpy=0x804e008, draw=52428802, gc=0x8059b00) at glxcurrent.c:512 It may just be an issue of properly guarding the call in the driver, it might also be a sign of something deeper. Unfortunately I don't have the time to investigate right now. I've just committed a (hopeful) fix. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] texformat-rework branch
The texformat-rework branch cleans up the texture format code. The gl_texture_format struct is replaced by a simple gl_format enum (see formats.h). This leads to assorted clean-ups in core mesa and the drivers. This is a step toward unifying and cleaning up the texture image and renderbuffer data structures. There may be some regressions in the tdfx and savage drivers. If/when anyone complains I can help diagnose/fix the regressions. I'd like to merge this branch to master by the end of the week. Let me know if there's any concerns. -Brian -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
