Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
Hi,
this does not seem to work on r600g (or I'm too stupid ;-)).
I updated to latest mesa master, patched piglit and this is the result:
$ glxinfo
[...]
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel
(git-0c181cd)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
[...]
$ MESA_EXTENSION_OVERRIDE=GL_ARB_fragment_layer_viewport bin/shader_runner
tests/spec/arb_fragment_layer_viewport/layer-gs-write-simple.shader_test -fbo
-auto
piglit: info: Requested an OpenGL 3.2 Core Context, and received a matching
3.3 context
Probe color at (0,0)
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
PIGLIT: {'result': 'fail' }
$ MESA_EXTENSION_OVERRIDE=GL_ARB_fragment_layer_viewport bin/shader_runner
tests/spec/arb_fragment_layer_viewport/viewport-gs-write-simple.shader_test -
fbo -auto
piglit: info: Requested an OpenGL 3.2 Core Context, and received a matching
3.3 context
Probe color at (0,0)
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
PIGLIT: {'result': 'fail' }
Tobias
Am Mo, 23. Juni 2014, 23:00:15 schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 3:52 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Jun 23, 2014 at 3:50 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 23.06.2014 21:14, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger
srol...@vmware.com wrote:
Am 23.06.2014 17:18, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger
srol...@vmware.com wrote:
Am 23.06.2014 16:43, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
If multiple viewports are supported, that implies the presence of
a GS
and layered rendering, so we can enable
ARB_fragment_layer_viewport as
well.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic
testing.
Grr... actually llvmpipe fails for viewport, but works for layer.
But... it draws all black instead of red, which means it's probably
either my or llvmpipe's understanding of default viewport state
that's
wrong. I assumed that by default viewports were initialized s.t.
they
would Just Work without having to be touched. Or... it's not
clamping the viewport index properly. Will investigate later.
Hmm I'm not sure. This was tested with d3d10 rules which of course
doesn't have the commands to set all viewports at once. But this is
handled by the state tracker.
Well, the tests don't set viewports at all. I was under the
(potentially incorrect) assumption that the default state was good
enough.
Yes it should be - the viewport should be set somewhere (I'm not
exactly
sure where it gets set) and since in GL the old commands just set all
viewports this should work.
This is the first time I'm looking at llvmpipe in detail, so forgive
the potential stupidity...
It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the
viewport index. Should it be? [Or is there some non-obvious place
where it's actually being clamped?] It seems like the layer is clamped
explicitly in lp_setup_tri and lp_setup_point.
This is sort of complicated.
Note that for ordinary fs input handling, you don't see viewport index
handling anywhere in llvmpipe - this is just handled like any other
ordinary attribute (through the interpolation stuff).
The code in lp_state_fs for viewport handling is just to get the correct
depth range, so you are right the viewport index must be clamped. The
clamping is done in lp_setup_tri() however (watch out for
viewport_index), the value then gets passed to rasterization (via
tri-inputs) and there written into the thread_data (in
lp_rast_shade_tile / lp_rast_shade_quads_mask). This is the value the
code in lp_state_fs.c will then pick up to fetch the correct depthrange
values (for depth clamping).
Though now that I look at it, this looks wrong in draw:
draw_clamp_viewport_idx(int idx)
{
return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0);
}
The same clamping in llvmpipe looks like this:
lp_clamp_viewport_idx(int idx)
{
return (PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0;
}
Would only make a difference for negative viewport indices though (and
don't ask me what would happen but draw might indeed fetch the viewport
values from random memory locations so the result might be quite
unpredictable...).
Roland
And a viewport index of -1 was one of my test cases. That's probably it!
Just to close the loop here, this was indeed it. With the patch that
fixes that (which is already in the repo),
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Tue, Jun 24, 2014 at 12:44 PM, Tobias Droste tdro...@gmx.de wrote:
Hi,
this does not seem to work on r600g (or I'm too stupid ;-)).
I updated to latest mesa master, patched piglit and this is the result:
$ glxinfo
[...]
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel
(git-0c181cd)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
[...]
$ MESA_EXTENSION_OVERRIDE=GL_ARB_fragment_layer_viewport bin/shader_runner
tests/spec/arb_fragment_layer_viewport/layer-gs-write-simple.shader_test -fbo
-auto
piglit: info: Requested an OpenGL 3.2 Core Context, and received a matching
3.3 context
Probe color at (0,0)
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
PIGLIT: {'result': 'fail' }
$ MESA_EXTENSION_OVERRIDE=GL_ARB_fragment_layer_viewport bin/shader_runner
tests/spec/arb_fragment_layer_viewport/viewport-gs-write-simple.shader_test -
fbo -auto
piglit: info: Requested an OpenGL 3.2 Core Context, and received a matching
3.3 context
Probe color at (0,0)
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
PIGLIT: {'result': 'fail' }
B :(
Could I trouble you to figure out which of the 4 draws (in each) is
failing? (Just comment out the probe lines, leaving only one in for
each)
Thanks for testing, BTW!
-ilia
Tobias
Am Mo, 23. Juni 2014, 23:00:15 schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 3:52 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Jun 23, 2014 at 3:50 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 23.06.2014 21:14, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger
srol...@vmware.com wrote:
Am 23.06.2014 17:18, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger
srol...@vmware.com wrote:
Am 23.06.2014 16:43, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
If multiple viewports are supported, that implies the presence of
a GS
and layered rendering, so we can enable
ARB_fragment_layer_viewport as
well.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic
testing.
Grr... actually llvmpipe fails for viewport, but works for layer.
But... it draws all black instead of red, which means it's probably
either my or llvmpipe's understanding of default viewport state
that's
wrong. I assumed that by default viewports were initialized s.t.
they
would Just Work without having to be touched. Or... it's not
clamping the viewport index properly. Will investigate later.
Hmm I'm not sure. This was tested with d3d10 rules which of course
doesn't have the commands to set all viewports at once. But this is
handled by the state tracker.
Well, the tests don't set viewports at all. I was under the
(potentially incorrect) assumption that the default state was good
enough.
Yes it should be - the viewport should be set somewhere (I'm not
exactly
sure where it gets set) and since in GL the old commands just set all
viewports this should work.
This is the first time I'm looking at llvmpipe in detail, so forgive
the potential stupidity...
It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the
viewport index. Should it be? [Or is there some non-obvious place
where it's actually being clamped?] It seems like the layer is clamped
explicitly in lp_setup_tri and lp_setup_point.
This is sort of complicated.
Note that for ordinary fs input handling, you don't see viewport index
handling anywhere in llvmpipe - this is just handled like any other
ordinary attribute (through the interpolation stuff).
The code in lp_state_fs for viewport handling is just to get the correct
depth range, so you are right the viewport index must be clamped. The
clamping is done in lp_setup_tri() however (watch out for
viewport_index), the value then gets passed to rasterization (via
tri-inputs) and there written into the thread_data (in
lp_rast_shade_tile / lp_rast_shade_quads_mask). This is the value the
code in lp_state_fs.c will then pick up to fetch the correct depthrange
values (for depth clamping).
Though now that I look at it, this looks wrong in draw:
draw_clamp_viewport_idx(int idx)
{
return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0);
}
The same clamping in llvmpipe looks like this:
lp_clamp_viewport_idx(int idx)
{
return (PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0;
}
Would only make a difference for negative viewport indices though (and
don't ask me what would happen but draw might indeed fetch the viewport
values from random memory
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
Am Di, 24. Juni 2014, 12:46:39 schrieb Ilia Mirkin:
On Tue, Jun 24, 2014 at 12:44 PM, Tobias Droste tdro...@gmx.de wrote:
Hi,
this does not seem to work on r600g (or I'm too stupid ;-)).
I updated to latest mesa master, patched piglit and this is the result:
$ glxinfo
[...]
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel
(git-0c181cd)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
[...]
$ MESA_EXTENSION_OVERRIDE=GL_ARB_fragment_layer_viewport bin/shader_runner
tests/spec/arb_fragment_layer_viewport/layer-gs-write-simple.shader_test
-fbo -auto
piglit: info: Requested an OpenGL 3.2 Core Context, and received a
matching
3.3 context
Probe color at (0,0)
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
PIGLIT: {'result': 'fail' }
$ MESA_EXTENSION_OVERRIDE=GL_ARB_fragment_layer_viewport bin/shader_runner
tests/spec/arb_fragment_layer_viewport/viewport-gs-write-simple.shader_tes
t - fbo -auto
piglit: info: Requested an OpenGL 3.2 Core Context, and received a
matching
3.3 context
Probe color at (0,0)
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
PIGLIT: {'result': 'fail' }
B :(
Could I trouble you to figure out which of the 4 draws (in each) is
failing? (Just comment out the probe lines, leaving only one in for
each)
Thanks for testing, BTW!
-ilia
All 4 probes in each test fail with the same result:
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
(And just to make sure I'm doing the right thing, I removed all 4 probes in
each test and then it passes).
Tobias
Tobias
Am Mo, 23. Juni 2014, 23:00:15 schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 3:52 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Mon, Jun 23, 2014 at 3:50 PM, Roland Scheidegger
srol...@vmware.com
wrote:
Am 23.06.2014 21:14, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger
srol...@vmware.com wrote:
Am 23.06.2014 17:18, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger
srol...@vmware.com wrote:
Am 23.06.2014 16:43, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin
imir...@alum.mit.edu
wrote:
On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin
imir...@alum.mit.edu
wrote:
If multiple viewports are supported, that implies the presence
of
a GS
and layered rendering, so we can enable
ARB_fragment_layer_viewport as
well.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic
testing.
Grr... actually llvmpipe fails for viewport, but works for
layer.
But... it draws all black instead of red, which means it's
probably
either my or llvmpipe's understanding of default viewport state
that's
wrong. I assumed that by default viewports were initialized s.t.
they
would Just Work without having to be touched. Or... it's not
clamping the viewport index properly. Will investigate later.
Hmm I'm not sure. This was tested with d3d10 rules which of course
doesn't have the commands to set all viewports at once. But this
is
handled by the state tracker.
Well, the tests don't set viewports at all. I was under the
(potentially incorrect) assumption that the default state was good
enough.
Yes it should be - the viewport should be set somewhere (I'm not
exactly
sure where it gets set) and since in GL the old commands just set
all
viewports this should work.
This is the first time I'm looking at llvmpipe in detail, so forgive
the potential stupidity...
It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the
viewport index. Should it be? [Or is there some non-obvious place
where it's actually being clamped?] It seems like the layer is
clamped
explicitly in lp_setup_tri and lp_setup_point.
This is sort of complicated.
Note that for ordinary fs input handling, you don't see viewport index
handling anywhere in llvmpipe - this is just handled like any other
ordinary attribute (through the interpolation stuff).
The code in lp_state_fs for viewport handling is just to get the
correct
depth range, so you are right the viewport index must be clamped. The
clamping is done in lp_setup_tri() however (watch out for
viewport_index), the value then gets passed to rasterization (via
tri-inputs) and there written into the thread_data (in
lp_rast_shade_tile / lp_rast_shade_quads_mask). This is the value the
code in lp_state_fs.c will then pick up to fetch the correct
depthrange
values (for depth clamping).
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Tue, Jun 24, 2014 at 12:58 PM, Tobias Droste tdro...@gmx.de wrote:
Am Di, 24. Juni 2014, 12:46:39 schrieb Ilia Mirkin:
On Tue, Jun 24, 2014 at 12:44 PM, Tobias Droste tdro...@gmx.de wrote:
Hi,
this does not seem to work on r600g (or I'm too stupid ;-)).
I updated to latest mesa master, patched piglit and this is the result:
$ glxinfo
[...]
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel
(git-0c181cd)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
[...]
$ MESA_EXTENSION_OVERRIDE=GL_ARB_fragment_layer_viewport bin/shader_runner
tests/spec/arb_fragment_layer_viewport/layer-gs-write-simple.shader_test
-fbo -auto
piglit: info: Requested an OpenGL 3.2 Core Context, and received a
matching
3.3 context
Probe color at (0,0)
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
PIGLIT: {'result': 'fail' }
$ MESA_EXTENSION_OVERRIDE=GL_ARB_fragment_layer_viewport bin/shader_runner
tests/spec/arb_fragment_layer_viewport/viewport-gs-write-simple.shader_tes
t - fbo -auto
piglit: info: Requested an OpenGL 3.2 Core Context, and received a
matching
3.3 context
Probe color at (0,0)
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
PIGLIT: {'result': 'fail' }
B :(
Could I trouble you to figure out which of the 4 draws (in each) is
failing? (Just comment out the probe lines, leaving only one in for
each)
Thanks for testing, BTW!
-ilia
All 4 probes in each test fail with the same result:
Expected: 0.00 1.00 0.00
Observed: 1.00 0.00 0.00
(And just to make sure I'm doing the right thing, I removed all 4 probes in
each test and then it passes).
Marek, any idea what's missing? If this is easily fixed, would be nice
to avoid the cap.
Looking at r600_spi_pid, it seems like layer/viewport index are
handled differently, which presumably means they must be handled
differently on the ps end as well.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. If someone with r600g could test this series out with the 2 piglit tests I sent to piglit@, that'd be great (http://patchwork.freedesktop.org/patch/28375/ -- no actual deps on chrisf's series if you run them directly via shader_runner.) docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. The index of the viewport itself isn't clamped but set to to zero if it exceeds 16 (PIPE_MAX_VIEWPORTS) but only for the actual selection of the viewport, again this is required by d3d10. GL has undefined results there so this should be ok (and hw will do near certainly the same anyway). The value you get in the fragment shader though will NOT be clamped, which as far as I can tell is required by both d3d10 and GL. But of course there could always be some other bug... Roland If someone with r600g could test this series out with the 2 piglit tests I sent to piglit@, that'd be great (https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/28375/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=67e6d3d7200289af788142c217a7c1cb598ccbeb7122ec52a358f60ffd98be2d -- no actual deps on chrisf's series if you run them directly via shader_runner.) docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=a6d6c596fee80884f66960766ae2d42d9f8426eabc4a352bc48ed38e5bb811e2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. Well, the tests don't set viewports at all. I was under the (potentially incorrect) assumption that the default state was good enough. The index of the viewport itself isn't clamped but set to to zero if it exceeds 16 (PIPE_MAX_VIEWPORTS) but only for the actual selection of the viewport, again this is required by d3d10. GL has undefined results there so this should be ok (and hw will do near certainly the same anyway). The value you get in the fragment shader though will NOT be clamped, which as far as I can tell is required by both d3d10 and GL. But of course there could always be some other bug... Bleh. Well, if GL has undefined rendering results for invalid gl_ViewportIndex, then my viewport test won't work -- it checks various out-of-bounds values. I'll scale it back to only testing legal values. Roland If someone with r600g could test this series out with the 2 piglit tests I sent to piglit@, that'd be great (https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/28375/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=67e6d3d7200289af788142c217a7c1cb598ccbeb7122ec52a358f60ffd98be2d -- no actual deps on chrisf's series if you run them directly via shader_runner.) docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=a6d6c596fee80884f66960766ae2d42d9f8426eabc4a352bc48ed38e5bb811e2 ___ mesa-dev mailing list
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
Am 23.06.2014 17:18, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. Well, the tests don't set viewports at all. I was under the (potentially incorrect) assumption that the default state was good enough. Yes it should be - the viewport should be set somewhere (I'm not exactly sure where it gets set) and since in GL the old commands just set all viewports this should work. The index of the viewport itself isn't clamped but set to to zero if it exceeds 16 (PIPE_MAX_VIEWPORTS) but only for the actual selection of the viewport, again this is required by d3d10. GL has undefined results there so this should be ok (and hw will do near certainly the same anyway). The value you get in the fragment shader though will NOT be clamped, which as far as I can tell is required by both d3d10 and GL. But of course there could always be some other bug... Bleh. Well, if GL has undefined rendering results for invalid gl_ViewportIndex, then my viewport test won't work -- it checks various out-of-bounds values. I'll scale it back to only testing legal values. Well I suspect for most hw it should still work (even if technically undefined in GL) due to d3d10 requirements which hw is likely to follow in any case. It definitely should work in llvmpipe. Roland Roland If someone with r600g could test this series out with the 2 piglit tests I sent to piglit@, that'd be great (https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/28375/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=J%2BXkuCJ6cA3U%2F2geD8pCPdQJ3h9Cu5xb%2BmaqRqBDoq4%3D%0As=67e6d3d7200289af788142c217a7c1cb598ccbeb7122ec52a358f60ffd98be2d -- no actual deps on chrisf's series if you run them directly via shader_runner.) docs/GL3.txt | 2 +- docs/relnotes/10.3.html| 1 + src/mesa/state_tracker/st_extensions.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 47165fe..ab90997 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -161,7 +161,7 @@ GL 4.3: GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) - GL_ARB_fragment_layer_viewport not started + GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600) GL_ARB_framebuffer_no_attachmentsnot started GL_ARB_internalformat_query2 not started GL_ARB_invalidate_subdataDONE (all drivers) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index ecc8580..99e0311 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -53,6 +53,7 @@ Note: some of the new features are only available with certain drivers. liGL_ARB_texture_query_levels on nv50, nvc0, llvmpipe, r600, radeonsi, softpipe/li liGL_ARB_texture_query_lod on radeonsi/li liGL_ARB_viewport_array on nvc0/li +liGL_ARB_fragment_layer_viewport on nv50, nvc0, llvmpipe, r600/li /ul diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index e938046..8cd6aa3 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -809,6 +809,7 @@ void st_init_extensions(struct st_context *st) ctx-Const.ViewportBounds.Min = -16384.0; ctx-Const.ViewportBounds.Max = 16384.0; ctx-Extensions.ARB_viewport_array = GL_TRUE; + ctx-Extensions.ARB_fragment_layer_viewport = GL_TRUE; } } if (ctx-Const.MaxProgramTextureGatherComponents 0) -- 1.8.5.5 ___ mesa-dev mailing list
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 17:18, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com wrote: Am 23.06.2014 16:43, schrieb Ilia Mirkin: On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu wrote: If multiple viewports are supported, that implies the presence of a GS and layered rendering, so we can enable ARB_fragment_layer_viewport as well. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing. Grr... actually llvmpipe fails for viewport, but works for layer. But... it draws all black instead of red, which means it's probably either my or llvmpipe's understanding of default viewport state that's wrong. I assumed that by default viewports were initialized s.t. they would Just Work without having to be touched. Or... it's not clamping the viewport index properly. Will investigate later. Hmm I'm not sure. This was tested with d3d10 rules which of course doesn't have the commands to set all viewports at once. But this is handled by the state tracker. Well, the tests don't set viewports at all. I was under the (potentially incorrect) assumption that the default state was good enough. Yes it should be - the viewport should be set somewhere (I'm not exactly sure where it gets set) and since in GL the old commands just set all viewports this should work. This is the first time I'm looking at llvmpipe in detail, so forgive the potential stupidity... It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the viewport index. Should it be? [Or is there some non-obvious place where it's actually being clamped?] It seems like the layer is clamped explicitly in lp_setup_tri and lp_setup_point. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
Am 23.06.2014 21:14, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 23.06.2014 17:18, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com
wrote:
Am 23.06.2014 16:43, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
If multiple viewports are supported, that implies the presence of a GS
and layered rendering, so we can enable ARB_fragment_layer_viewport as
well.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing.
Grr... actually llvmpipe fails for viewport, but works for layer.
But... it draws all black instead of red, which means it's probably
either my or llvmpipe's understanding of default viewport state that's
wrong. I assumed that by default viewports were initialized s.t. they
would Just Work without having to be touched. Or... it's not
clamping the viewport index properly. Will investigate later.
Hmm I'm not sure. This was tested with d3d10 rules which of course
doesn't have the commands to set all viewports at once. But this is
handled by the state tracker.
Well, the tests don't set viewports at all. I was under the
(potentially incorrect) assumption that the default state was good
enough.
Yes it should be - the viewport should be set somewhere (I'm not exactly
sure where it gets set) and since in GL the old commands just set all
viewports this should work.
This is the first time I'm looking at llvmpipe in detail, so forgive
the potential stupidity...
It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the
viewport index. Should it be? [Or is there some non-obvious place
where it's actually being clamped?] It seems like the layer is clamped
explicitly in lp_setup_tri and lp_setup_point.
This is sort of complicated.
Note that for ordinary fs input handling, you don't see viewport index
handling anywhere in llvmpipe - this is just handled like any other
ordinary attribute (through the interpolation stuff).
The code in lp_state_fs for viewport handling is just to get the correct
depth range, so you are right the viewport index must be clamped. The
clamping is done in lp_setup_tri() however (watch out for
viewport_index), the value then gets passed to rasterization (via
tri-inputs) and there written into the thread_data (in
lp_rast_shade_tile / lp_rast_shade_quads_mask). This is the value the
code in lp_state_fs.c will then pick up to fetch the correct depthrange
values (for depth clamping).
Though now that I look at it, this looks wrong in draw:
draw_clamp_viewport_idx(int idx)
{
return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0);
}
The same clamping in llvmpipe looks like this:
lp_clamp_viewport_idx(int idx)
{
return (PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0;
}
Would only make a difference for negative viewport indices though (and
don't ask me what would happen but draw might indeed fetch the viewport
values from random memory locations so the result might be quite
unpredictable...).
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/3] mesa/st: enable ARB_fragment_layer_viewport
On Mon, Jun 23, 2014 at 3:50 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 23.06.2014 21:14, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 23.06.2014 17:18, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger srol...@vmware.com
wrote:
Am 23.06.2014 16:43, schrieb Ilia Mirkin:
On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin imir...@alum.mit.edu
wrote:
If multiple viewports are supported, that implies the presence of a GS
and layered rendering, so we can enable ARB_fragment_layer_viewport as
well.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Untested on r600, but nv50/nvc0/llvmpipe seem to pass basic testing.
Grr... actually llvmpipe fails for viewport, but works for layer.
But... it draws all black instead of red, which means it's probably
either my or llvmpipe's understanding of default viewport state that's
wrong. I assumed that by default viewports were initialized s.t. they
would Just Work without having to be touched. Or... it's not
clamping the viewport index properly. Will investigate later.
Hmm I'm not sure. This was tested with d3d10 rules which of course
doesn't have the commands to set all viewports at once. But this is
handled by the state tracker.
Well, the tests don't set viewports at all. I was under the
(potentially incorrect) assumption that the default state was good
enough.
Yes it should be - the viewport should be set somewhere (I'm not exactly
sure where it gets set) and since in GL the old commands just set all
viewports this should work.
This is the first time I'm looking at llvmpipe in detail, so forgive
the potential stupidity...
It seems like lp_state_fs.c:lp_llvm_viewport isn't clamping the
viewport index. Should it be? [Or is there some non-obvious place
where it's actually being clamped?] It seems like the layer is clamped
explicitly in lp_setup_tri and lp_setup_point.
This is sort of complicated.
Note that for ordinary fs input handling, you don't see viewport index
handling anywhere in llvmpipe - this is just handled like any other
ordinary attribute (through the interpolation stuff).
The code in lp_state_fs for viewport handling is just to get the correct
depth range, so you are right the viewport index must be clamped. The
clamping is done in lp_setup_tri() however (watch out for
viewport_index), the value then gets passed to rasterization (via
tri-inputs) and there written into the thread_data (in
lp_rast_shade_tile / lp_rast_shade_quads_mask). This is the value the
code in lp_state_fs.c will then pick up to fetch the correct depthrange
values (for depth clamping).
Though now that I look at it, this looks wrong in draw:
draw_clamp_viewport_idx(int idx)
{
return ((PIPE_MAX_VIEWPORTS idx || idx 0) ? idx : 0);
}
The same clamping in llvmpipe looks like this:
lp_clamp_viewport_idx(int idx)
{
return (PIPE_MAX_VIEWPORTS idx idx = 0) ? idx : 0;
}
Would only make a difference for negative viewport indices though (and
don't ask me what would happen but draw might indeed fetch the viewport
values from random memory locations so the result might be quite
unpredictable...).
Roland
And a viewport index of -1 was one of my test cases. That's probably it!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
