texformat-rework branch

[Brian Paul-4]

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-4]

On Mon, Oct 5, 2009 at 9:14 PM, Brian Paul <brian.e.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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[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 <brian.e.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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Nicolai Hähnle wrote:

> Am Wednesday 14 October 2009 03:45:26 schrieb Brian Paul:
>> On Mon, Oct 5, 2009 at 9:14 PM, Brian Paul <brian.e.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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

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

<snip>
> > It may just be an issue of properly guarding the call in the driver, it
> > might also be a sign of something deeper. Unfortunately I don't have the
> > time to investigate right now.
>
> I've just committed a (hopeful) fix.

Thank you; I re-tested, but go another such assertion in Sauerbraten, this
time it seems to be coming from some other source of texture data:

(gdb) bt                                
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb7bc16d0 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7bc3098 in *__GI_abort () at abort.c:88
#3  0xb7bba5ce in *__GI___assert_fail (assertion=0xb74a7811 "info-
>BytesPerBlock", file=0xb74a77d6 "main/formats.c", line=576,
    function=0xb74a77fa "_mesa_get_format_bytes") at assert.c:78
#4  0xb729117a in _mesa_get_format_bytes (format=MESA_FORMAT_NONE) at
main/formats.c:576
#5  0xb7240d78 in radeon_teximage (ctx=0x85a3e60, dims=2, target=3553,
level=0, internalFormat=6409, width=256, height=256, depth=1,
    imageSize=0, format=6409, type=5121, pixels=0xad2fd70, packing=0x85b0da4,
texObj=0x929d540, texImage=0xad00890, compressed=0)
    at radeon_texture.c:547
#6  0xb7241447 in radeonTexImage2D (ctx=0x85a3e60, target=3553, level=0,
internalFormat=6409, width=256, height=256, border=0, format=6409,
    type=5121, pixels=0xad2fd70, packing=0x85b0da4, texObj=0x929d540,
texImage=0xad00890) at radeon_texture.c:688
#7  0xb72e478b in _mesa_TexImage2D (target=3553, level=0, internalFormat=6409,
width=256, height=256, border=0, format=6409, type=5121,
    pixels=0xad2fd70) at main/teximage.c:2316

cu,
Nicolai

> -Brian



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[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 <brian.e.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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alex Deucher]

On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul <brianp@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Alex Deucher wrote:

> On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul <brianp@...> 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_RGBA8888) { /* XXX */
+ } else if (rrb->base.Format == MESA_FORMAT_XRGB8888) {
  radeonInitPointers_xRGB8888(&rrb->base);
- } else if (rrb->base.Format == MESA_FORMAT_RGBA8888) {
+ } else if (rrb->base.Format == MESA_FORMAT_ARGB8888) {
  radeonInitPointers_ARGB8888(&rrb->base);
  } else if (rrb->base.Format == MESA_FORMAT_ARGB4444) {
  radeonInitPointers_ARGB4444(&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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alex Deucher]

On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul <brianp@...> wrote:

> Alex Deucher wrote:
>>
>> On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul <brianp@...> 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_RGBA8888) { /* XXX */
> +       } else if (rrb->base.Format == MESA_FORMAT_XRGB8888) {
>                radeonInitPointers_xRGB8888(&rrb->base);
> -       } else if (rrb->base.Format == MESA_FORMAT_RGBA8888) {
> +       } else if (rrb->base.Format == MESA_FORMAT_ARGB8888) {
>                radeonInitPointers_ARGB8888(&rrb->base);
>        } else if (rrb->base.Format == MESA_FORMAT_ARGB4444) {
>                radeonInitPointers_ARGB4444(&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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Alex Deucher wrote:

> On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul <brianp@...> wrote:
>> Alex Deucher wrote:
>>> On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul <brianp@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alex Deucher]

On Thu, Oct 22, 2009 at 2:24 PM, Brian Paul <brianp@...> wrote:

> Alex Deucher wrote:
>>
>> On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul <brianp@...> wrote:
>>>
>>> Alex Deucher wrote:
>>>>
>>>> On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul <brianp@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alex Deucher]

On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul <brianp@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Alex Deucher wrote:

> On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul <brianp@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alex Deucher]

On Mon, Oct 26, 2009 at 3:06 PM, Brian Paul <brianp@...> wrote:

> Alex Deucher wrote:
>>
>> On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul <brianp@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

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 RGBA8888 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev