[Mesa-dev] [PATCH 1/2] gallium/st: Clean up Haiku depth mapping, fix colorspace errors

[kallisti5]

On 2014-12-29 16:55, Roland Scheidegger wrote:
> Am 27.12.2014 um 18:41 schrieb Ilia Mirkin:
>> On Sat, Dec 27, 2014 at 1:13 AM, Alexander von Gluck IV
>> <kallisti5 at unixzen.com> wrote:
>>> ---
>>>  src/gallium/state_trackers/hgl/hgl.c |   48 
>>> +++++++++++++--------------------
>>>  1 files changed, 19 insertions(+), 29 deletions(-)
>>> 
>>> @@ -244,9 +245,9 @@ hgl_create_st_visual(ulong options)
>>>         TRACE("alpha    :\t%d\n", (bool)alphaFlag);
>>>         TRACE("dbl      :\t%d\n", (bool)dblFlag);
>>>         TRACE("stereo   :\t%d\n", (bool)stereoFlag);
>>> -       TRACE("depth    :\t%d\n", depth);
>>> -       TRACE("stencil  :\t%d\n", stencil);
>>> -       TRACE("accum    :\t%d\n", accum);
>>> +       TRACE("depth    :\t%d\n", (bool)depthFlag);
>>> +       TRACE("stencil  :\t%d\n", (bool)stencilFlag);
>>> +       TRACE("accum    :\t%d\n", (bool)accumFlag);
>>>         TRACE("red      :\t%d\n", red);
>>>         TRACE("green    :\t%d\n", green);
>>>         TRACE("blue     :\t%d\n", blue);
>>> @@ -254,34 +255,23 @@ hgl_create_st_visual(ulong options)
>>> 
>>>         // Determine color format
>>>         if (red == 8) {
>>> +               // Color format
>>>                 if (alpha == 8)
>>> -                       visual->color_format = 
>>> PIPE_FORMAT_A8R8G8B8_UNORM;
>>> +                       visual->color_format = 
>>> PIPE_FORMAT_B8G8R8A8_UNORM;
>>>                 else
>>> -                       visual->color_format = 
>>> PIPE_FORMAT_X8R8G8B8_UNORM;
>>> +                       visual->color_format = 
>>> PIPE_FORMAT_B8G8R8X8_UNORM;
>>> +
>>> +               // Depth buffer
>>> +               if (depthFlag)
>>> +                       visual->depth_stencil_format = 
>>> PIPE_FORMAT_Z32_UNORM;
>> 
>> I guess you only work with llvmpipe which supports whatever, but I
>> don't think a lot of hw drivers support Z32_UNORM. Z24 is much more
>> common. Some hardware also supports Z16 and Z32_FLOAT (and
>> Z32_FLOAT_S8X24_UNORM for depth/stencil combined version).
> FWIW llvmpipe (and softpipe) do not really support z32_unorm neither, 
> it
> should
> never be used. (The reason is just like hw most things are done with
> floats, so you've got only 24bit mantissa bits to work with really). 
> So,
> while it may work, the precision is probably not what you expected and
> if you rely on some specific accuracy (for instance for depth offsets)
> the results may be somewhat bogus. We actually wanted to drop the 
> format
> entirely at some point, could still do it at some point. Similar things
> can be said about the other 32bit snorm/unorm formats though IIRC these
> are sort of necessary for supporting gl vertex attribs which can be
> 32bit normalized, but they should not be needed as render target /
> texture support.
> So indeed z24 (with or without stencil), z16_unorm if that's good 
> enough
> or z32_float should be used.
> 

I actually just rewrote pretty much all of our state_tracker code. I was 
cheating
in a a few places and using _mesa_* calls vs using stamps :-)

The patch can be found here:
http://unixzen.com/patchwork/0001-gallium-state_tracker-Rewrite-Haiku-s-state-tracker.patch

This isn't final, so i'm not attaching it to the ML just yet.

My remaining issue is when I have an OpenGL window open, and resize it, 
the
rendered item remains in the bottom left corner of the viewport at the 
original size.
This didn't happen-pre this patch. (attached)

I can say that:
   * The winsys bitmap resizes with the window
   * The state_tracker frame buffer gets destroyed and recreated that the 
proper size.

So no idea what i'm missing :-)

Feedback very, very, welcome.

  -- Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: teapot.jpg
Type: image/jpeg
Size: 62598 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141229/4d7a3089/attachment-0001.jpg>