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_Y8                0x1e
#       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
>>>>>>>> <[email protected]>
>>>>>>> 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 <[email protected]>:
>>>>>>>>>>> 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 <[email protected]>:
>>>>>>>>>>>>> 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.250000
>>>>>>>>>>>>> 0.250000 0.250000 1.000000\n  Observed: 0.000000 0.000000
>>>>>>>>>>>>> 0.000000 1.000000\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
>>>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to