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
<kallis...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to