Re: [Mesa3d-dev] texformat-rework branch

[Brian Paul]

On Fri, Dec 11, 2009 at 3:49 PM, Maciej Cencora  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

[Maciej Cencora]

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?

Regards,
Maciej

--
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

[Brian Paul]

Forwarding...
--- Begin Message ---
It appears that R3xx-R4xx can sample from the Z16 format only. R5xx
should be able to sample from both Z16 and Z24S8.

References:
http://aras-p.info/texts/D3D9GPUHacks.html

Marek

On Tue, Dec 8, 2009 at 12:31 AM, Brian Paul  wrote:
> OK, for the MESA_FORMAT_Z24_S8 case in r300SetDepthTexMode() the
> 'format' pointer is set to the "X24_Y8" entries.
>
> If you read the comment for X24_Y8 in r300_reg.h it says:
>
>/* These two values are wrong, but they're the only values that
> * produce any even vaguely correct results.  Can r300 only do 16-bit
> * depth textures?
> */
> #   define R300_TX_FORMAT_X24_Y80x1e
> #   define R300_TX_FORMAT_X32   0x1e
>
> Maybe the Z24_S8 case has never worked?
>
> Also, maybe radeonChooseTextureFormat() should be smarter about the
> texture format it chooses for the depth/stencil formats.  Right now,
> MESA_FORMAT_S8_Z24 is the only one ever returned.
>
> -Brian
>
>
> Maciej Cencora wrote:
>> Depth/stencil buffer formats is a different thing (already fixed). Currently 
>> the
>> problem is with depth textures. Formerly driver choose _mesa_texformat_s8_z24
>> for depth textures (radeonChooseTextureFormat in radeon_texture.c) then in
>> r300SetDepthTexMode (r300_texstate.c) we set proper hw format (but I'm not
>> sure how it worked because the texformat is _mesa_texformat_s8_z24 and there
>> we checked for MESA_FORMAT_Z24_S8 ???). That setup worked somehow.
>> Now you've changed the case in r300SetDepthTexMode from MESA_FORMAT_Z24_S8 to
>> MESA_FORMAT_S8_Z24 and it stopped working.
>>
>> I'm using r300 driver (rv380 card). The piglit output is partially random. 
>> The
>> background is black, and sometimes there's white rectangle on top of it
>> (random size and placement).
>>
>> Regards,
>> Maciej
>>
>> Dnia poniedziałek, 7 grudnia 2009 o 22:36:19 Brian Paul napisał(a):
>>> The main thing is to choose the z/stencil format that's supported by
>>> the hardware.  As I mentioned before, it looks like different
>>> generations of ATI/radeon hardware used different formats.  It sounds
>>> like that should be resolved now though.
>>>
>>> What does piglit's texdepth rendering look like?  Which driver are you
>>> using?
>>>
>>> -Brian
>>>
>>> Maciej Cencora wrote:
 I've worked some more on the texdepth problem, and looks like it works as
 long I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8,
 S8_Z24, X8_Z24 formats seems to work. Has anything changed regarding
 storing images in these formats?

 Regards,
 Maciej

 Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a):
> OK, I've committed your patch.
>
> -Brian
>
> Maciej Cencora wrote:
>> Yes, with attached glean/readPixSanity test is passing now. The only
>> regressed test now is texturing/texdepth but I believe that something
>> else must have broken it.
>>
>> Regards,
>> Maciej
>>
>> Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a):
>>> Do Michel's recents commits help with these?
>>>
>>> -Brian
>>>
>>> Maciej Cencora wrote:
 There's certainly a progress. Now only glean/readPixSanity and
 texturing/texDepth tests are failing. I've checked
 glean/readPixSanity and it's failing for 24bit depth buffer (no
 stencil buffer) visuals. I've tried modifying radeon_span.c code but
 without a luck.
 I'm attaching the patch I've used.

 Regards,
 Maciej

 Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
> Please update your Mesa from git.  I fixed the assertion at line 123
>  yesterday.
>
> -Brian
>
> On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora
> 
 wrote:
>> I've tried your patch (+some minor fixes to make it work) but
>> running texdepth with it results in failing assertion  rb->Format
>> == MESA_FORMAT_X8_Z24 (s_readpix.c:123).
>> I've also tried modifying span functions to convert between Z24_S8
>> (hw format) to S8_Z24 (mesa format) but wasn't able to get correct
>> result. Any other ideas?
>>
>> Maciej
>>
>> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
>>> I think the problem is confusion between MESA_FORMAT_Z24_S8 and
>>> MESA_FORMAT_S8_Z24 in the radeon drivers.
>>>
>>> Looking at the span code, it appears that R300, R200 use Z24_S8
>>> format while R600 and others use S8_Z24.
>>>
>>> Here's a patch that attempts to fix things.  I don't have radeon
>>> hardware to test so maybe someone else can start with this and
>>> finish it up.
>>>
>>> -Brian
>>>
>>> 2009/11/11 Maciej Cencora :
 I've checked 

Re: [Mesa3d-dev] texformat-rework branch

[Brian Paul]

OK, for the MESA_FORMAT_Z24_S8 case in r300SetDepthTexMode() the 
'format' pointer is set to the "X24_Y8" entries.

If you read the comment for X24_Y8 in r300_reg.h it says:

/* These two values are wrong, but they're the only values that
 * produce any even vaguely correct results.  Can r300 only do 16-bit
 * depth textures?
 */
#   define R300_TX_FORMAT_X24_Y80x1e
#   define R300_TX_FORMAT_X32   0x1e

Maybe the Z24_S8 case has never worked?

Also, maybe radeonChooseTextureFormat() should be smarter about the 
texture format it chooses for the depth/stencil formats.  Right now, 
MESA_FORMAT_S8_Z24 is the only one ever returned.

-Brian


Maciej Cencora wrote:
> Depth/stencil buffer formats is a different thing (already fixed). Currently 
> the 
> problem is with depth textures. Formerly driver choose _mesa_texformat_s8_z24 
> for depth textures (radeonChooseTextureFormat in radeon_texture.c) then in 
> r300SetDepthTexMode (r300_texstate.c) we set proper hw format (but I'm not 
> sure how it worked because the texformat is _mesa_texformat_s8_z24 and there 
> we checked for MESA_FORMAT_Z24_S8 ???). That setup worked somehow.
> Now you've changed the case in r300SetDepthTexMode from MESA_FORMAT_Z24_S8 to 
> MESA_FORMAT_S8_Z24 and it stopped working.
> 
> I'm using r300 driver (rv380 card). The piglit output is partially random. 
> The 
> background is black, and sometimes there's white rectangle on top of it 
> (random size and placement).
> 
> Regards,
> Maciej
> 
> Dnia poniedziałek, 7 grudnia 2009 o 22:36:19 Brian Paul napisał(a):
>> The main thing is to choose the z/stencil format that's supported by
>> the hardware.  As I mentioned before, it looks like different
>> generations of ATI/radeon hardware used different formats.  It sounds
>> like that should be resolved now though.
>>
>> What does piglit's texdepth rendering look like?  Which driver are you
>> using?
>>
>> -Brian
>>
>> Maciej Cencora wrote:
>>> I've worked some more on the texdepth problem, and looks like it works as
>>> long I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8,
>>> S8_Z24, X8_Z24 formats seems to work. Has anything changed regarding
>>> storing images in these formats?
>>>
>>> Regards,
>>> Maciej
>>>
>>> Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a):
 OK, I've committed your patch.

 -Brian

 Maciej Cencora wrote:
> Yes, with attached glean/readPixSanity test is passing now. The only
> regressed test now is texturing/texdepth but I believe that something
> else must have broken it.
>
> Regards,
> Maciej
>
> Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a):
>> Do Michel's recents commits help with these?
>>
>> -Brian
>>
>> Maciej Cencora wrote:
>>> There's certainly a progress. Now only glean/readPixSanity and
>>> texturing/texDepth tests are failing. I've checked
>>> glean/readPixSanity and it's failing for 24bit depth buffer (no
>>> stencil buffer) visuals. I've tried modifying radeon_span.c code but
>>> without a luck.
>>> I'm attaching the patch I've used.
>>>
>>> Regards,
>>> Maciej
>>>
>>> Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
 Please update your Mesa from git.  I fixed the assertion at line 123
  yesterday.

 -Brian

 On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora
 
>>> wrote:
> I've tried your patch (+some minor fixes to make it work) but
> running texdepth with it results in failing assertion  rb->Format
> == MESA_FORMAT_X8_Z24 (s_readpix.c:123).
> I've also tried modifying span functions to convert between Z24_S8
> (hw format) to S8_Z24 (mesa format) but wasn't able to get correct
> result. Any other ideas?
>
> Maciej
>
> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
>> I think the problem is confusion between MESA_FORMAT_Z24_S8 and
>> MESA_FORMAT_S8_Z24 in the radeon drivers.
>>
>> Looking at the span code, it appears that R300, R200 use Z24_S8
>> format while R600 and others use S8_Z24.
>>
>> Here's a patch that attempts to fix things.  I don't have radeon
>> hardware to test so maybe someone else can start with this and
>> finish it up.
>>
>> -Brian
>>
>> 2009/11/11 Maciej Cencora :
>>> I've checked the other failing tests.
>>> Following were also passing before the texformat-rework merge:
>>> fdo23670-drawpix_stencil
>>> stencil-drawpixels
>>> fragProg1 (Z write test)
>>> readPixSanity
>>> stencil2
>>>
>>> Maciej
>>>
>>> Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
 It pas

Re: [Mesa3d-dev] texformat-rework branch

[Maciej Cencora]

Depth/stencil buffer formats is a different thing (already fixed). Currently 
the 
problem is with depth textures. Formerly driver choose _mesa_texformat_s8_z24 
for depth textures (radeonChooseTextureFormat in radeon_texture.c) then in 
r300SetDepthTexMode (r300_texstate.c) we set proper hw format (but I'm not 
sure how it worked because the texformat is _mesa_texformat_s8_z24 and there 
we checked for MESA_FORMAT_Z24_S8 ???). That setup worked somehow.
Now you've changed the case in r300SetDepthTexMode from MESA_FORMAT_Z24_S8 to 
MESA_FORMAT_S8_Z24 and it stopped working.

I'm using r300 driver (rv380 card). The piglit output is partially random. The 
background is black, and sometimes there's white rectangle on top of it 
(random size and placement).

Regards,
Maciej

Dnia poniedziałek, 7 grudnia 2009 o 22:36:19 Brian Paul napisał(a):
> The main thing is to choose the z/stencil format that's supported by
> the hardware.  As I mentioned before, it looks like different
> generations of ATI/radeon hardware used different formats.  It sounds
> like that should be resolved now though.
> 
> What does piglit's texdepth rendering look like?  Which driver are you
> using?
> 
> -Brian
> 
> Maciej Cencora wrote:
> > I've worked some more on the texdepth problem, and looks like it works as
> > long I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8,
> > S8_Z24, X8_Z24 formats seems to work. Has anything changed regarding
> > storing images in these formats?
> >
> > Regards,
> > Maciej
> >
> > Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a):
> >> OK, I've committed your patch.
> >>
> >> -Brian
> >>
> >> Maciej Cencora wrote:
> >>> Yes, with attached glean/readPixSanity test is passing now. The only
> >>> regressed test now is texturing/texdepth but I believe that something
> >>> else must have broken it.
> >>>
> >>> Regards,
> >>> Maciej
> >>>
> >>> Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a):
>  Do Michel's recents commits help with these?
> 
>  -Brian
> 
>  Maciej Cencora wrote:
> > There's certainly a progress. Now only glean/readPixSanity and
> > texturing/texDepth tests are failing. I've checked
> > glean/readPixSanity and it's failing for 24bit depth buffer (no
> > stencil buffer) visuals. I've tried modifying radeon_span.c code but
> > without a luck.
> > I'm attaching the patch I've used.
> >
> > Regards,
> > Maciej
> >
> > Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
> >> Please update your Mesa from git.  I fixed the assertion at line 123
> >>  yesterday.
> >>
> >> -Brian
> >>
> >> On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora
> >> 
> >
> > wrote:
> >>> I've tried your patch (+some minor fixes to make it work) but
> >>> running texdepth with it results in failing assertion  rb->Format
> >>> == MESA_FORMAT_X8_Z24 (s_readpix.c:123).
> >>> I've also tried modifying span functions to convert between Z24_S8
> >>> (hw format) to S8_Z24 (mesa format) but wasn't able to get correct
> >>> result. Any other ideas?
> >>>
> >>> Maciej
> >>>
> >>> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
>  I think the problem is confusion between MESA_FORMAT_Z24_S8 and
>  MESA_FORMAT_S8_Z24 in the radeon drivers.
> 
>  Looking at the span code, it appears that R300, R200 use Z24_S8
>  format while R600 and others use S8_Z24.
> 
>  Here's a patch that attempts to fix things.  I don't have radeon
>  hardware to test so maybe someone else can start with this and
>  finish it up.
> 
>  -Brian
> 
>  2009/11/11 Maciej Cencora :
> > I've checked the other failing tests.
> > Following were also passing before the texformat-rework merge:
> > fdo23670-drawpix_stencil
> > stencil-drawpixels
> > fragProg1 (Z write test)
> > readPixSanity
> > stencil2
> >
> > Maciej
> >
> > Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
> >> It passes with swrast and the i965 driver here.
> >>
> >> Did this test pass prior to the texformat work?
> >>
> >> -Brian
> >>
> >> 2009/11/10 Maciej Cencora :
> >>> It doesn't assert anymore, but the test is still failing.
> >>>
> >>> @test: texturing/texdepth
> >>> info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG
> >>> build Nov 8 2009 21:21:48\nMesa warning: couldn\'t open
> >>> libtxc_dxtn.so, software DXTn compression/decompression
> >>> unavailable\nMesa: Initializing x86-64 optimizations\nMesa:
> >>> 3Dnow!
> >>> detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25
> >>> 0.25 0.25 1.00\n  Observed: 0.00 0.

Re: [Mesa3d-dev] texformat-rework branch

[Brian Paul]

The main thing is to choose the z/stencil format that's supported by 
the hardware.  As I mentioned before, it looks like different 
generations of ATI/radeon hardware used different formats.  It sounds 
like that should be resolved now though.

What does piglit's texdepth rendering look like?  Which driver are you 
using?

-Brian

Maciej Cencora wrote:
> I've worked some more on the texdepth problem, and looks like it works as 
> long 
> I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8, S8_Z24, 
> X8_Z24 formats seems to work. Has anything changed regarding storing images 
> in 
> these formats?
> 
> Regards,
> Maciej
> 
> Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a):
>> OK, I've committed your patch.
>>
>> -Brian
>>
>> Maciej Cencora wrote:
>>> Yes, with attached glean/readPixSanity test is passing now. The only
>>> regressed test now is texturing/texdepth but I believe that something
>>> else must have broken it.
>>>
>>> Regards,
>>> Maciej
>>>
>>> Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a):
 Do Michel's recents commits help with these?

 -Brian

 Maciej Cencora wrote:
> There's certainly a progress. Now only glean/readPixSanity and
> texturing/texDepth tests are failing. I've checked glean/readPixSanity
> and it's failing for 24bit depth buffer (no stencil buffer) visuals.
> I've tried modifying radeon_span.c code but without a luck.
> I'm attaching the patch I've used.
>
> Regards,
> Maciej
>
> Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
>> Please update your Mesa from git.  I fixed the assertion at line 123
>>  yesterday.
>>
>> -Brian
>>
>> On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora 
> wrote:
>>> I've tried your patch (+some minor fixes to make it work) but running
>>> texdepth with it results in failing assertion  rb->Format ==
>>> MESA_FORMAT_X8_Z24 (s_readpix.c:123).
>>> I've also tried modifying span functions to convert between Z24_S8
>>> (hw format) to S8_Z24 (mesa format) but wasn't able to get correct
>>> result. Any other ideas?
>>>
>>> Maciej
>>>
>>> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
 I think the problem is confusion between MESA_FORMAT_Z24_S8 and
 MESA_FORMAT_S8_Z24 in the radeon drivers.

 Looking at the span code, it appears that R300, R200 use Z24_S8
 format while R600 and others use S8_Z24.

 Here's a patch that attempts to fix things.  I don't have radeon
 hardware to test so maybe someone else can start with this and
 finish it up.

 -Brian

 2009/11/11 Maciej Cencora :
> I've checked the other failing tests.
> Following were also passing before the texformat-rework merge:
> fdo23670-drawpix_stencil
> stencil-drawpixels
> fragProg1 (Z write test)
> readPixSanity
> stencil2
>
> Maciej
>
> Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
>> It passes with swrast and the i965 driver here.
>>
>> Did this test pass prior to the texformat work?
>>
>> -Brian
>>
>> 2009/11/10 Maciej Cencora :
>>> It doesn't assert anymore, but the test is still failing.
>>>
>>> @test: texturing/texdepth
>>> info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG
>>> build Nov 8 2009 21:21:48\nMesa warning: couldn\'t open
>>> libtxc_dxtn.so, software DXTn compression/decompression
>>> unavailable\nMesa: Initializing x86-64 optimizations\nMesa:
>>> 3Dnow!
>>> detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25
>>> 0.25 0.25 1.00\n  Observed: 0.00 0.00
>>> 0.00 1.00\nTest failed: \'Render textures GL_LUMINANCE
>>> (no shadow functionality)\'\nSee above for details.\n\n
>>> errors!
>>>
>>> Maciej
>>>
>>> Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
 Can you try again with Mesa git/master?  I've updated the
 assertions.

 -Brian

 On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora
 
> wrote:
> It is r300 driver (RV530 GPU).
>
> I'm sending the backtrace as attachement.
>
> Maciej
>
> Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
>> Which driver?
>>
>> Could you provide a stack trace for the failed assertion?
>>
>> -Brian
>>
>> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora
>> 
>>> wrote:
>>> Hi Brian,

Re: [Mesa3d-dev] texformat-rework branch

[Maciej Cencora]

I've worked some more on the texdepth problem, and looks like it works as long 
I send the depth textures in Z16 format. None of the Z24_S8,Z24_X8, S8_Z24, 
X8_Z24 formats seems to work. Has anything changed regarding storing images in 
these formats?

Regards,
Maciej

Dnia wtorek, 17 listopada 2009 o 21:42:31 Brian Paul napisał(a):
> OK, I've committed your patch.
> 
> -Brian
> 
> Maciej Cencora wrote:
> > Yes, with attached glean/readPixSanity test is passing now. The only
> > regressed test now is texturing/texdepth but I believe that something
> > else must have broken it.
> >
> > Regards,
> > Maciej
> >
> > Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a):
> >> Do Michel's recents commits help with these?
> >>
> >> -Brian
> >>
> >> Maciej Cencora wrote:
> >>> There's certainly a progress. Now only glean/readPixSanity and
> >>> texturing/texDepth tests are failing. I've checked glean/readPixSanity
> >>> and it's failing for 24bit depth buffer (no stencil buffer) visuals.
> >>> I've tried modifying radeon_span.c code but without a luck.
> >>> I'm attaching the patch I've used.
> >>>
> >>> Regards,
> >>> Maciej
> >>>
> >>> Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
>  Please update your Mesa from git.  I fixed the assertion at line 123
>   yesterday.
> 
>  -Brian
> 
>  On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora 
> >>>
> >>> wrote:
> > I've tried your patch (+some minor fixes to make it work) but running
> > texdepth with it results in failing assertion  rb->Format ==
> > MESA_FORMAT_X8_Z24 (s_readpix.c:123).
> > I've also tried modifying span functions to convert between Z24_S8
> > (hw format) to S8_Z24 (mesa format) but wasn't able to get correct
> > result. Any other ideas?
> >
> > Maciej
> >
> > Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
> >> I think the problem is confusion between MESA_FORMAT_Z24_S8 and
> >> MESA_FORMAT_S8_Z24 in the radeon drivers.
> >>
> >> Looking at the span code, it appears that R300, R200 use Z24_S8
> >> format while R600 and others use S8_Z24.
> >>
> >> Here's a patch that attempts to fix things.  I don't have radeon
> >> hardware to test so maybe someone else can start with this and
> >> finish it up.
> >>
> >> -Brian
> >>
> >> 2009/11/11 Maciej Cencora :
> >>> I've checked the other failing tests.
> >>> Following were also passing before the texformat-rework merge:
> >>> fdo23670-drawpix_stencil
> >>> stencil-drawpixels
> >>> fragProg1 (Z write test)
> >>> readPixSanity
> >>> stencil2
> >>>
> >>> Maciej
> >>>
> >>> Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
>  It passes with swrast and the i965 driver here.
> 
>  Did this test pass prior to the texformat work?
> 
>  -Brian
> 
>  2009/11/10 Maciej Cencora :
> > It doesn't assert anymore, but the test is still failing.
> >
> > @test: texturing/texdepth
> > info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG
> > build Nov 8 2009 21:21:48\nMesa warning: couldn\'t open
> > libtxc_dxtn.so, software DXTn compression/decompression
> > unavailable\nMesa: Initializing x86-64 optimizations\nMesa:
> > 3Dnow!
> > detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25
> > 0.25 0.25 1.00\n  Observed: 0.00 0.00
> > 0.00 1.00\nTest failed: \'Render textures GL_LUMINANCE
> > (no shadow functionality)\'\nSee above for details.\n\n
> > errors!
> >
> > Maciej
> >
> > Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
> >> Can you try again with Mesa git/master?  I've updated the
> >> assertions.
> >>
> >> -Brian
> >>
> >> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora
> >> 
> >>>
> >>> wrote:
> >>> It is r300 driver (RV530 GPU).
> >>>
> >>> I'm sending the backtrace as attachement.
> >>>
> >>> Maciej
> >>>
> >>> Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
>  Which driver?
> 
>  Could you provide a stack trace for the failed assertion?
> 
>  -Brian
> 
>  On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora
>  
> >
> > wrote:
> > Hi Brian,
> >
> > 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

Re: [Mesa3d-dev] texformat-rework branch

[Brian Paul]

OK, I've committed your patch.

-Brian

Maciej Cencora wrote:
> Yes, with attached glean/readPixSanity test is passing now. The only 
> regressed 
> test now is texturing/texdepth but I believe that something else must have 
> broken it.
> 
> Regards,
> Maciej
> 
> Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a):
>> Do Michel's recents commits help with these?
>>
>> -Brian
>>
>> Maciej Cencora wrote:
>>> There's certainly a progress. Now only glean/readPixSanity and
>>> texturing/texDepth tests are failing. I've checked glean/readPixSanity
>>> and it's failing for 24bit depth buffer (no stencil buffer) visuals. I've
>>> tried modifying radeon_span.c code but without a luck.
>>> I'm attaching the patch I've used.
>>>
>>> Regards,
>>> Maciej
>>>
>>> Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
 Please update your Mesa from git.  I fixed the assertion at line 123
  yesterday.

 -Brian

 On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora 
>>> wrote:
> I've tried your patch (+some minor fixes to make it work) but running
> texdepth with it results in failing assertion  rb->Format ==
> MESA_FORMAT_X8_Z24 (s_readpix.c:123).
> I've also tried modifying span functions to convert between Z24_S8 (hw
> format) to S8_Z24 (mesa format) but wasn't able to get correct result.
> Any other ideas?
>
> Maciej
>
> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
>> I think the problem is confusion between MESA_FORMAT_Z24_S8 and
>> MESA_FORMAT_S8_Z24 in the radeon drivers.
>>
>> Looking at the span code, it appears that R300, R200 use Z24_S8 format
>> while R600 and others use S8_Z24.
>>
>> Here's a patch that attempts to fix things.  I don't have radeon
>> hardware to test so maybe someone else can start with this and finish
>> it up.
>>
>> -Brian
>>
>> 2009/11/11 Maciej Cencora :
>>> I've checked the other failing tests.
>>> Following were also passing before the texformat-rework merge:
>>> fdo23670-drawpix_stencil
>>> stencil-drawpixels
>>> fragProg1 (Z write test)
>>> readPixSanity
>>> stencil2
>>>
>>> Maciej
>>>
>>> Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
 It passes with swrast and the i965 driver here.

 Did this test pass prior to the texformat work?

 -Brian

 2009/11/10 Maciej Cencora :
> It doesn't assert anymore, but the test is still failing.
>
> @test: texturing/texdepth
> info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build
> Nov 8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so,
> software DXTn compression/decompression unavailable\nMesa:
> Initializing x86-64 optimizations\nMesa: 3Dnow!
> detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25
> 0.25 0.25 1.00\n  Observed: 0.00 0.00 0.00
> 1.00\nTest failed: \'Render textures GL_LUMINANCE (no shadow
> functionality)\'\nSee above for details.\n\n
> errors!
>
> Maciej
>
> Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
>> Can you try again with Mesa git/master?  I've updated the
>> assertions.
>>
>> -Brian
>>
>> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora
>> 
>>> wrote:
>>> It is r300 driver (RV530 GPU).
>>>
>>> I'm sending the backtrace as attachement.
>>>
>>> Maciej
>>>
>>> Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
 Which driver?

 Could you provide a stack trace for the failed assertion?

 -Brian

 On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora
 
> wrote:
> Hi Brian,
>
> 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

Re: [Mesa3d-dev] texformat-rework branch

[Maciej Cencora]

Yes, with attached glean/readPixSanity test is passing now. The only regressed 
test now is texturing/texdepth but I believe that something else must have 
broken it.

Regards,
Maciej

Dnia wtorek, 17 listopada 2009 o 19:04:47 Brian Paul napisał(a):
> Do Michel's recents commits help with these?
> 
> -Brian
> 
> Maciej Cencora wrote:
> > There's certainly a progress. Now only glean/readPixSanity and
> > texturing/texDepth tests are failing. I've checked glean/readPixSanity
> > and it's failing for 24bit depth buffer (no stencil buffer) visuals. I've
> > tried modifying radeon_span.c code but without a luck.
> > I'm attaching the patch I've used.
> >
> > Regards,
> > Maciej
> >
> > Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
> >> Please update your Mesa from git.  I fixed the assertion at line 123
> >>  yesterday.
> >>
> >> -Brian
> >>
> >> On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora 
> >
> > wrote:
> >>> I've tried your patch (+some minor fixes to make it work) but running
> >>> texdepth with it results in failing assertion  rb->Format ==
> >>> MESA_FORMAT_X8_Z24 (s_readpix.c:123).
> >>> I've also tried modifying span functions to convert between Z24_S8 (hw
> >>> format) to S8_Z24 (mesa format) but wasn't able to get correct result.
> >>> Any other ideas?
> >>>
> >>> Maciej
> >>>
> >>> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
>  I think the problem is confusion between MESA_FORMAT_Z24_S8 and
>  MESA_FORMAT_S8_Z24 in the radeon drivers.
> 
>  Looking at the span code, it appears that R300, R200 use Z24_S8 format
>  while R600 and others use S8_Z24.
> 
>  Here's a patch that attempts to fix things.  I don't have radeon
>  hardware to test so maybe someone else can start with this and finish
>  it up.
> 
>  -Brian
> 
>  2009/11/11 Maciej Cencora :
> > I've checked the other failing tests.
> > Following were also passing before the texformat-rework merge:
> > fdo23670-drawpix_stencil
> > stencil-drawpixels
> > fragProg1 (Z write test)
> > readPixSanity
> > stencil2
> >
> > Maciej
> >
> > Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
> >> It passes with swrast and the i965 driver here.
> >>
> >> Did this test pass prior to the texformat work?
> >>
> >> -Brian
> >>
> >> 2009/11/10 Maciej Cencora :
> >>> It doesn't assert anymore, but the test is still failing.
> >>>
> >>> @test: texturing/texdepth
> >>> info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build
> >>> Nov 8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so,
> >>> software DXTn compression/decompression unavailable\nMesa:
> >>> Initializing x86-64 optimizations\nMesa: 3Dnow!
> >>> detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25
> >>> 0.25 0.25 1.00\n  Observed: 0.00 0.00 0.00
> >>> 1.00\nTest failed: \'Render textures GL_LUMINANCE (no shadow
> >>> functionality)\'\nSee above for details.\n\n
> >>> errors!
> >>>
> >>> Maciej
> >>>
> >>> Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
>  Can you try again with Mesa git/master?  I've updated the
>  assertions.
> 
>  -Brian
> 
>  On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora
>  
> >
> > wrote:
> > It is r300 driver (RV530 GPU).
> >
> > I'm sending the backtrace as attachement.
> >
> > Maciej
> >
> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
> >> Which driver?
> >>
> >> Could you provide a stack trace for the failed assertion?
> >>
> >> -Brian
> >>
> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora
> >> 
> >>>
> >>> wrote:
> >>> Hi Brian,
> >>>
> >>> 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?
> 
> >>>

Re: [Mesa3d-dev] texformat-rework branch

[Brian Paul]

Do Michel's recents commits help with these?

-Brian

Maciej Cencora wrote:
> There's certainly a progress. Now only glean/readPixSanity and 
> texturing/texDepth tests are failing. I've checked glean/readPixSanity and 
> it's failing for 24bit depth buffer (no stencil buffer) visuals.
> I've tried modifying radeon_span.c code but without a luck.
> I'm attaching the patch I've used.
> 
> Regards,
> Maciej
> 
> Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
>> Please update your Mesa from git.  I fixed the assertion at line 123
>>  yesterday.
>>
>> -Brian
>>
>> On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora  
> wrote:
>>> I've tried your patch (+some minor fixes to make it work) but running
>>> texdepth with it results in failing assertion  rb->Format ==
>>> MESA_FORMAT_X8_Z24 (s_readpix.c:123).
>>> I've also tried modifying span functions to convert between Z24_S8 (hw
>>> format) to S8_Z24 (mesa format) but wasn't able to get correct result.
>>> Any other ideas?
>>>
>>> Maciej
>>>
>>> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
 I think the problem is confusion between MESA_FORMAT_Z24_S8 and
 MESA_FORMAT_S8_Z24 in the radeon drivers.

 Looking at the span code, it appears that R300, R200 use Z24_S8 format
 while R600 and others use S8_Z24.

 Here's a patch that attempts to fix things.  I don't have radeon
 hardware to test so maybe someone else can start with this and finish
 it up.

 -Brian

 2009/11/11 Maciej Cencora :
> I've checked the other failing tests.
> Following were also passing before the texformat-rework merge:
> fdo23670-drawpix_stencil
> stencil-drawpixels
> fragProg1 (Z write test)
> readPixSanity
> stencil2
>
> Maciej
>
> Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
>> It passes with swrast and the i965 driver here.
>>
>> Did this test pass prior to the texformat work?
>>
>> -Brian
>>
>> 2009/11/10 Maciej Cencora :
>>> It doesn't assert anymore, but the test is still failing.
>>>
>>> @test: texturing/texdepth
>>> info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build
>>> Nov 8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so,
>>> software DXTn compression/decompression unavailable\nMesa:
>>> Initializing x86-64 optimizations\nMesa: 3Dnow!
>>> detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25
>>> 0.25 0.25 1.00\n  Observed: 0.00 0.00 0.00
>>> 1.00\nTest failed: \'Render textures GL_LUMINANCE (no shadow
>>> functionality)\'\nSee above for details.\n\n
>>> errors!
>>>
>>> Maciej
>>>
>>> Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
 Can you try again with Mesa git/master?  I've updated the
 assertions.

 -Brian

 On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora
 
> wrote:
> It is r300 driver (RV530 GPU).
>
> I'm sending the backtrace as attachement.
>
> Maciej
>
> Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
>> Which driver?
>>
>> Could you provide a stack trace for the failed assertion?
>>
>> -Brian
>>
>> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora
>> 
>>> wrote:
>>> Hi Brian,
>>>
>>> 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 marke

Re: [Mesa3d-dev] texformat-rework branch

[Maciej Cencora]

There's certainly a progress. Now only glean/readPixSanity and 
texturing/texDepth tests are failing. I've checked glean/readPixSanity and 
it's failing for 24bit depth buffer (no stencil buffer) visuals.
I've tried modifying radeon_span.c code but without a luck.
I'm attaching the patch I've used.

Regards,
Maciej

Dnia czwartek, 12 listopada 2009 o 20:55:08 Brian Paul napisał(a):
> Please update your Mesa from git.  I fixed the assertion at line 123
>  yesterday.
> 
> -Brian
> 
> On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora  
wrote:
> > I've tried your patch (+some minor fixes to make it work) but running
> > texdepth with it results in failing assertion  rb->Format ==
> > MESA_FORMAT_X8_Z24 (s_readpix.c:123).
> > I've also tried modifying span functions to convert between Z24_S8 (hw
> > format) to S8_Z24 (mesa format) but wasn't able to get correct result.
> > Any other ideas?
> >
> > Maciej
> >
> > Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
> >> I think the problem is confusion between MESA_FORMAT_Z24_S8 and
> >> MESA_FORMAT_S8_Z24 in the radeon drivers.
> >>
> >> Looking at the span code, it appears that R300, R200 use Z24_S8 format
> >> while R600 and others use S8_Z24.
> >>
> >> Here's a patch that attempts to fix things.  I don't have radeon
> >> hardware to test so maybe someone else can start with this and finish
> >> it up.
> >>
> >> -Brian
> >>
> >> 2009/11/11 Maciej Cencora :
> >> > I've checked the other failing tests.
> >> > Following were also passing before the texformat-rework merge:
> >> > fdo23670-drawpix_stencil
> >> > stencil-drawpixels
> >> > fragProg1 (Z write test)
> >> > readPixSanity
> >> > stencil2
> >> >
> >> > Maciej
> >> >
> >> > Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
> >> >> It passes with swrast and the i965 driver here.
> >> >>
> >> >> Did this test pass prior to the texformat work?
> >> >>
> >> >> -Brian
> >> >>
> >> >> 2009/11/10 Maciej Cencora :
> >> >> > It doesn't assert anymore, but the test is still failing.
> >> >> >
> >> >> > @test: texturing/texdepth
> >> >> > info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build
> >> >> > Nov 8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so,
> >> >> > software DXTn compression/decompression unavailable\nMesa:
> >> >> > Initializing x86-64 optimizations\nMesa: 3Dnow!
> >> >> > detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25
> >> >> > 0.25 0.25 1.00\n  Observed: 0.00 0.00 0.00
> >> >> > 1.00\nTest failed: \'Render textures GL_LUMINANCE (no shadow
> >> >> > functionality)\'\nSee above for details.\n\n
> >> >> > errors!
> >> >> >
> >> >> > Maciej
> >> >> >
> >> >> > Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
> >> >> >> Can you try again with Mesa git/master?  I've updated the
> >> >> >> assertions.
> >> >> >>
> >> >> >> -Brian
> >> >> >>
> >> >> >> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora
> >> >> >> 
> >> >
> >> > wrote:
> >> >> >> > It is r300 driver (RV530 GPU).
> >> >> >> >
> >> >> >> > I'm sending the backtrace as attachement.
> >> >> >> >
> >> >> >> > Maciej
> >> >> >> >
> >> >> >> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
> >> >> >> >> Which driver?
> >> >> >> >>
> >> >> >> >> Could you provide a stack trace for the failed assertion?
> >> >> >> >>
> >> >> >> >> -Brian
> >> >> >> >>
> >> >> >> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora
> >> >> >> >> 
> >> >> >
> >> >> > wrote:
> >> >> >> >> > Hi Brian,
> >> >> >> >> >
> >> >> >> >> > 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)
> >> >> >> >>

Re: [Mesa3d-dev] texformat-rework branch

[Brian Paul]

Please update your Mesa from git.  I fixed the assertion at line 123 yesterday.

-Brian


On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora  wrote:
> I've tried your patch (+some minor fixes to make it work) but running texdepth
> with it results in failing assertion  rb->Format == MESA_FORMAT_X8_Z24
> (s_readpix.c:123).
> I've also tried modifying span functions to convert between Z24_S8 (hw format)
> to S8_Z24 (mesa format) but wasn't able to get correct result.
> Any other ideas?
>
> Maciej
>
> Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
>> I think the problem is confusion between MESA_FORMAT_Z24_S8 and
>> MESA_FORMAT_S8_Z24 in the radeon drivers.
>>
>> Looking at the span code, it appears that R300, R200 use Z24_S8 format
>> while R600 and others use S8_Z24.
>>
>> Here's a patch that attempts to fix things.  I don't have radeon
>> hardware to test so maybe someone else can start with this and finish
>> it up.
>>
>> -Brian
>>
>> 2009/11/11 Maciej Cencora :
>> > I've checked the other failing tests.
>> > Following were also passing before the texformat-rework merge:
>> > fdo23670-drawpix_stencil
>> > stencil-drawpixels
>> > fragProg1 (Z write test)
>> > readPixSanity
>> > stencil2
>> >
>> > Maciej
>> >
>> > Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
>> >> It passes with swrast and the i965 driver here.
>> >>
>> >> Did this test pass prior to the texformat work?
>> >>
>> >> -Brian
>> >>
>> >> 2009/11/10 Maciej Cencora :
>> >> > It doesn't assert anymore, but the test is still failing.
>> >> >
>> >> > @test: texturing/texdepth
>> >> > info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build
>> >> > Nov 8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so,
>> >> > software DXTn compression/decompression unavailable\nMesa:
>> >> > Initializing x86-64 optimizations\nMesa: 3Dnow!
>> >> > detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25 0.25
>> >> > 0.25 1.00\n  Observed: 0.00 0.00 0.00
>> >> > 1.00\nTest failed: \'Render textures GL_LUMINANCE (no shadow
>> >> > functionality)\'\nSee above for details.\n\n
>> >> > errors!
>> >> >
>> >> > Maciej
>> >> >
>> >> > Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
>> >> >> Can you try again with Mesa git/master?  I've updated the assertions.
>> >> >>
>> >> >> -Brian
>> >> >>
>> >> >> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora 
>> >
>> > wrote:
>> >> >> > It is r300 driver (RV530 GPU).
>> >> >> >
>> >> >> > I'm sending the backtrace as attachement.
>> >> >> >
>> >> >> > Maciej
>> >> >> >
>> >> >> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
>> >> >> >> Which driver?
>> >> >> >>
>> >> >> >> Could you provide a stack trace for the failed assertion?
>> >> >> >>
>> >> >> >> -Brian
>> >> >> >>
>> >> >> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora
>> >> >> >> 
>> >> >
>> >> > wrote:
>> >> >> >> > Hi Brian,
>> >> >> >> >
>> >> >> >> > 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
>> >> >> >> >
>> >> >> >> > 
>> >> >> >> >--- --- -

Re: [Mesa3d-dev] texformat-rework branch

[Maciej Cencora]

I've tried your patch (+some minor fixes to make it work) but running texdepth 
with it results in failing assertion  rb->Format == MESA_FORMAT_X8_Z24 
(s_readpix.c:123).
I've also tried modifying span functions to convert between Z24_S8 (hw format) 
to S8_Z24 (mesa format) but wasn't able to get correct result.
Any other ideas?

Maciej

Dnia czwartek, 12 listopada 2009 o 00:18:54 Brian Paul napisał(a):
> I think the problem is confusion between MESA_FORMAT_Z24_S8 and
> MESA_FORMAT_S8_Z24 in the radeon drivers.
> 
> Looking at the span code, it appears that R300, R200 use Z24_S8 format
> while R600 and others use S8_Z24.
> 
> Here's a patch that attempts to fix things.  I don't have radeon
> hardware to test so maybe someone else can start with this and finish
> it up.
> 
> -Brian
> 
> 2009/11/11 Maciej Cencora :
> > I've checked the other failing tests.
> > Following were also passing before the texformat-rework merge:
> > fdo23670-drawpix_stencil
> > stencil-drawpixels
> > fragProg1 (Z write test)
> > readPixSanity
> > stencil2
> >
> > Maciej
> >
> > Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
> >> It passes with swrast and the i965 driver here.
> >>
> >> Did this test pass prior to the texformat work?
> >>
> >> -Brian
> >>
> >> 2009/11/10 Maciej Cencora :
> >> > It doesn't assert anymore, but the test is still failing.
> >> >
> >> > @test: texturing/texdepth
> >> > info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build
> >> > Nov 8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so,
> >> > software DXTn compression/decompression unavailable\nMesa:
> >> > Initializing x86-64 optimizations\nMesa: 3Dnow!
> >> > detected\n\n\nOutput:\nProbe at (80,16)\n Expected: 0.25 0.25
> >> > 0.25 1.00\n  Observed: 0.00 0.00 0.00
> >> > 1.00\nTest failed: \'Render textures GL_LUMINANCE (no shadow
> >> > functionality)\'\nSee above for details.\n\n
> >> > errors!
> >> >
> >> > Maciej
> >> >
> >> > Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
> >> >> Can you try again with Mesa git/master?  I've updated the assertions.
> >> >>
> >> >> -Brian
> >> >>
> >> >> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora 
> >
> > wrote:
> >> >> > It is r300 driver (RV530 GPU).
> >> >> >
> >> >> > I'm sending the backtrace as attachement.
> >> >> >
> >> >> > Maciej
> >> >> >
> >> >> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
> >> >> >> Which driver?
> >> >> >>
> >> >> >> Could you provide a stack trace for the failed assertion?
> >> >> >>
> >> >> >> -Brian
> >> >> >>
> >> >> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora
> >> >> >> 
> >> >
> >> > wrote:
> >> >> >> > Hi Brian,
> >> >> >> >
> >> >> >> > 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 R

Re: [Mesa3d-dev] texformat-rework branch

[Brian Paul]

I think the problem is confusion between MESA_FORMAT_Z24_S8 and
MESA_FORMAT_S8_Z24 in the radeon drivers.

Looking at the span code, it appears that R300, R200 use Z24_S8 format
while R600 and others use S8_Z24.

Here's a patch that attempts to fix things.  I don't have radeon
hardware to test so maybe someone else can start with this and finish
it up.

-Brian



2009/11/11 Maciej Cencora :
> I've checked the other failing tests.
> Following were also passing before the texformat-rework merge:
> fdo23670-drawpix_stencil
> stencil-drawpixels
> fragProg1 (Z write test)
> readPixSanity
> stencil2
>
> Maciej
>
> Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
>> It passes with swrast and the i965 driver here.
>>
>> Did this test pass prior to the texformat work?
>>
>> -Brian
>>
>> 2009/11/10 Maciej Cencora :
>> > It doesn't assert anymore, but the test is still failing.
>> >
>> > @test: texturing/texdepth
>> > info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build Nov
>> >  8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so, software
>> > DXTn compression/decompression unavailable\nMesa: Initializing x86-64
>> > optimizations\nMesa: 3Dnow! detected\n\n\nOutput:\nProbe at (80,16)\n
>> > Expected: 0.25 0.25 0.25 1.00\n  Observed: 0.00
>> > 0.00 0.00 1.00\nTest failed: \'Render textures GL_LUMINANCE
>> > (no shadow functionality)\'\nSee above for details.\n\n
>> > errors!
>> >
>> > Maciej
>> >
>> > Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
>> >> Can you try again with Mesa git/master?  I've updated the assertions.
>> >>
>> >> -Brian
>> >>
>> >> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora 
> wrote:
>> >> > It is r300 driver (RV530 GPU).
>> >> >
>> >> > I'm sending the backtrace as attachement.
>> >> >
>> >> > Maciej
>> >> >
>> >> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
>> >> >> Which driver?
>> >> >>
>> >> >> Could you provide a stack trace for the failed assertion?
>> >> >>
>> >> >> -Brian
>> >> >>
>> >> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora 
>> >
>> > wrote:
>> >> >> > Hi Brian,
>> >> >> >
>> >> >> > 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
>>
>


radeon_z_stencil.patch
Description: Binary data
--
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

[Maciej Cencora]

I've checked the other failing tests.
Following were also passing before the texformat-rework merge:
fdo23670-drawpix_stencil
stencil-drawpixels
fragProg1 (Z write test)
readPixSanity
stencil2

Maciej

Dnia środa, 11 listopada 2009 o 03:44:18 Brian Paul napisał(a):
> It passes with swrast and the i965 driver here.
> 
> Did this test pass prior to the texformat work?
> 
> -Brian
> 
> 2009/11/10 Maciej Cencora :
> > It doesn't assert anymore, but the test is still failing.
> >
> > @test: texturing/texdepth
> > info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build Nov
> >  8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so, software
> > DXTn compression/decompression unavailable\nMesa: Initializing x86-64
> > optimizations\nMesa: 3Dnow! detected\n\n\nOutput:\nProbe at (80,16)\n
> > Expected: 0.25 0.25 0.25 1.00\n  Observed: 0.00
> > 0.00 0.00 1.00\nTest failed: \'Render textures GL_LUMINANCE
> > (no shadow functionality)\'\nSee above for details.\n\n
> > errors!
> >
> > Maciej
> >
> > Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
> >> Can you try again with Mesa git/master?  I've updated the assertions.
> >>
> >> -Brian
> >>
> >> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora  
wrote:
> >> > It is r300 driver (RV530 GPU).
> >> >
> >> > I'm sending the backtrace as attachement.
> >> >
> >> > Maciej
> >> >
> >> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
> >> >> Which driver?
> >> >>
> >> >> Could you provide a stack trace for the failed assertion?
> >> >>
> >> >> -Brian
> >> >>
> >> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora 
> >
> > wrote:
> >> >> > Hi Brian,
> >> >> >
> >> >> > 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

[Maciej Cencora]

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 :
> > It doesn't assert anymore, but the test is still failing.
> >
> > @test: texturing/texdepth
> > info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build Nov
> >  8 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so, software
> > DXTn compression/decompression unavailable\nMesa: Initializing x86-64
> > optimizations\nMesa: 3Dnow! detected\n\n\nOutput:\nProbe at (80,16)\n
> > Expected: 0.25 0.25 0.25 1.00\n  Observed: 0.00
> > 0.00 0.00 1.00\nTest failed: \'Render textures GL_LUMINANCE
> > (no shadow functionality)\'\nSee above for details.\n\n
> > errors!
> >
> > Maciej
> >
> > Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
> >> Can you try again with Mesa git/master?  I've updated the assertions.
> >>
> >> -Brian
> >>
> >> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora  
wrote:
> >> > It is r300 driver (RV530 GPU).
> >> >
> >> > I'm sending the backtrace as attachement.
> >> >
> >> > Maciej
> >> >
> >> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
> >> >> Which driver?
> >> >>
> >> >> Could you provide a stack trace for the failed assertion?
> >> >>
> >> >> -Brian
> >> >>
> >> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora 
> >
> > wrote:
> >> >> > Hi Brian,
> >> >> >
> >> >> > 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

[Brian Paul]

It passes with swrast and the i965 driver here.

Did this test pass prior to the texformat work?

-Brian


2009/11/10 Maciej Cencora :
> It doesn't assert anymore, but the test is still failing.
>
> @test: texturing/texdepth
> info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build Nov  8
> 2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so, software DXTn
> compression/decompression unavailable\nMesa: Initializing x86-64
> optimizations\nMesa: 3Dnow! detected\n\n\nOutput:\nProbe at (80,16)\n
> Expected: 0.25 0.25 0.25 1.00\n  Observed: 0.00 0.00
> 0.00 1.00\nTest failed: \'Render textures GL_LUMINANCE (no shadow
> functionality)\'\nSee above for details.\n\n
> errors!
>
> Maciej
>
> Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
>> Can you try again with Mesa git/master?  I've updated the assertions.
>>
>> -Brian
>>
>> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora  wrote:
>> > It is r300 driver (RV530 GPU).
>> >
>> > I'm sending the backtrace as attachement.
>> >
>> > Maciej
>> >
>> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
>> >> Which driver?
>> >>
>> >> Could you provide a stack trace for the failed assertion?
>> >>
>> >> -Brian
>> >>
>> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora 
> wrote:
>> >> > Hi Brian,
>> >> >
>> >> > 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

[Maciej Cencora]

It doesn't assert anymore, but the test is still failing.

@test: texturing/texdepth
info: @@@Returncode: 1\n\nErrors:\nMesa: Mesa 7.7-devel DEBUG build Nov  8 
2009 21:21:48\nMesa warning: couldn\'t open libtxc_dxtn.so, software DXTn 
compression/decompression unavailable\nMesa: Initializing x86-64 
optimizations\nMesa: 3Dnow! detected\n\n\nOutput:\nProbe at (80,16)\n  
Expected: 0.25 0.25 0.25 1.00\n  Observed: 0.00 0.00 
0.00 1.00\nTest failed: \'Render textures GL_LUMINANCE (no shadow 
functionality)\'\nSee above for details.\n\n
errors!

Maciej

Dnia środa, 11 listopada 2009 o 02:25:52 Brian Paul napisał(a):
> Can you try again with Mesa git/master?  I've updated the assertions.
> 
> -Brian
> 
> On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora  wrote:
> > It is r300 driver (RV530 GPU).
> >
> > I'm sending the backtrace as attachement.
> >
> > Maciej
> >
> > Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
> >> Which driver?
> >>
> >> Could you provide a stack trace for the failed assertion?
> >>
> >> -Brian
> >>
> >> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora  
wrote:
> >> > Hi Brian,
> >> >
> >> > 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

[Brian Paul]

Can you try again with Mesa git/master?  I've updated the assertions.

-Brian


On Tue, Nov 10, 2009 at 3:43 PM, Maciej Cencora  wrote:
> It is r300 driver (RV530 GPU).
>
> I'm sending the backtrace as attachement.
>
> Maciej
>
> Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
>> Which driver?
>>
>> Could you provide a stack trace for the failed assertion?
>>
>> -Brian
>>
>> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora  wrote:
>> > Hi Brian,
>> >
>> > 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

[Ian Romanick]

-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

[Maciej Cencora]

It is r300 driver (RV530 GPU).

I'm sending the backtrace as attachement.

Maciej

Dnia wtorek, 10 listopada 2009 o 23:38:09 Brian Paul napisał(a):
> Which driver?
> 
> Could you provide a stack trace for the failed assertion?
> 
> -Brian
> 
> On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora  wrote:
> > Hi Brian,
> >
> > 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 
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:  
...   
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=) 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=) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
pid =  
   
selftid =  
   
#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, 1407374883

Re: [Mesa3d-dev] texformat-rework branch

[Brian Paul]

Which driver?

Could you provide a stack trace for the failed assertion?

-Brian

On Tue, Nov 10, 2009 at 3:30 PM, Maciej Cencora  wrote:
> Hi Brian,
>
> 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

[Maciej Cencora]

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

[Alex Deucher]

On Thu, Oct 29, 2009 at 9:49 AM, Brian Paul  wrote:
> Alex Deucher wrote:
>>
>> On Wed, Oct 28, 2009 at 11:44 PM, Brian Paul 
>> 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

[Brian Paul]

Alex Deucher wrote:
> On Wed, Oct 28, 2009 at 11:44 PM, Brian Paul  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

[Alex Deucher]

On Wed, Oct 28, 2009 at 11:44 PM, Brian Paul  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

[Brian Paul]

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  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  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

[Wil Reichert]

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  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

[Brian Paul]

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

[Brian Paul]

Chia-I Wu wrote:
> 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.

Thanks.  I'll look into that tonight if possible.

I think I'll merge the branch to master soon after.

-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

[Chia-I Wu]

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

[Alex Deucher]

On Mon, Oct 26, 2009 at 3:06 PM, Brian Paul  wrote:
> Alex Deucher wrote:
>>
>> On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul  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

[Brian Paul]

Alex Deucher wrote:

On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul  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 Deucher]

On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul  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

[Brian Paul]

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

[Alex Deucher]

On Thu, Oct 22, 2009 at 2:24 PM, Brian Paul  wrote:
> Alex Deucher wrote:
>>
>> On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul  wrote:
>>>
>>> Alex Deucher wrote:

 On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul  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

[Brian Paul]

Alex Deucher wrote:
> On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul  wrote:
>> Alex Deucher wrote:
>>> On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul  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

[Alex Deucher]

On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul  wrote:
> Alex Deucher wrote:
>>
>> On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul  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

[Brian Paul]

Alex Deucher wrote:

On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul  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

[Alex Deucher]

On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul  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

[Brian Paul]

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

[Brian Paul]

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

[Nicolai Hähnle]

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

[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.

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

[Nicolai Hähnle]

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  
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]

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  
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.

> > 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

[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  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]

Am Wednesday 14 October 2009 03:45:26 schrieb Brian Paul:
> On Mon, Oct 5, 2009 at 9:14 PM, 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.
> >
> > 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

[Brian Paul]

On Mon, Oct 5, 2009 at 9:14 PM, 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.
>
> 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.

-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

[Brian Paul]

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 BlackBerry® 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/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev