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
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
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_Z2
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.
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
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? Wh
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 200
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
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?
>
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
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.
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_Z2
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 c
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 m
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 i
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 as
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
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-6
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):
>> W
-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 == 0x81
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:
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_readpi
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 bu
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.
>>> *
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
>> functio
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
> * textu
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
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
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 sp
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
>> driv
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 to
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
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 forma
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
glxge
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)
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
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'
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 f
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.
H
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/t
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 Confe
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
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 chang
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
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
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
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). T
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 cle
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 unif
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 dat
50 matches
Mail list logo
