[Mesa-dev] [PATCH 1/2] softpipe: implement some support for multiple viewports
Roland Scheidegger
sroland at vmware.com
Fri Dec 11 21:20:49 PST 2015
I think it actually works like this: llvmpipe has a single vertex
layout, which it tells draw about, which will then emit the vertices in
this format.
However, softpipe will always tell draw to emit the vertices as-is (via
its first layout). Its second layout has draw written all over it but
draw doesn't know anything about it at all. Therefore, the slots as
indicated by draw_find_shader_output indeed must be used (I believe
things don't actually work if position isn't at output 0 because sp
setup will assume it's at 0 but we didn't tell draw to reorder the
outputs, but probably noone cared).
This actually sounds like softpipe is more clever here than llvmpipe
because it can emit vertices as-is (clearly, it ought to be possible
that we don't depend on a specific vertex format in llvmpipe), but given
how this works (this will use the translate code) I doubt that buys us
anything. Albeit translate is quite the black box to me...
I think it is a mistake that softpipe is using vertex_info for its
second layout. The fields used are nearly fully disjoint in any case
(draw doesn't care about interp_mode as the vertex_info is just used for
emit, albeit most drivers try to faithfully fill in all information just
in case, softpipe doesn't care about hwfmt, emit, it doesn't even care
about the size calculations in the end... Should probably use its own
thing with just number of elements, interp, and index in it...).
Roland
Am 12.12.2015 um 03:29 schrieb Roland Scheidegger:
> Hmm actually there were some piglit regressions.
> I don't mind the ones from the arb_fragment_layer_viewport group from
> skip to pass (up to today they failed in llvmpipe too and we don't have
> a cap bit for this functionality separately).
> However, this broke some more basic stuff like vs point size output and
> and layer output in some cases.
>
> But there's others, like
> ./piglit/bin/glsl-vs-point-size -auto -fbo
> ./piglit/bin/gl-3.2-layered-rendering-gl-layer-cube-map -auto -fbo
> I'm pretty sure they are due to the code changes below:
>
>>> @@ -135,17 +136,35 @@ softpipe_get_vertex_info(struct
> softpipe_context *softpipe)
>>> draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src);
>>> }
>>>
>>> - softpipe->psize_slot = draw_find_shader_output(softpipe->draw,
>>> - TGSI_SEMANTIC_PSIZE, 0);
>>> - if (softpipe->psize_slot >= 0) {
>>> - draw_emit_vertex_attr(vinfo, EMIT_4F, INTERP_CONSTANT,
>>> - softpipe->psize_slot);
>>> + /* Figure out if we need pointsize as well. */
>>> + vs_index = draw_find_shader_output(softpipe->draw,
>>> + TGSI_SEMANTIC_PSIZE, 0);
>>> +
>>> + if (vs_index >= 0) {
>>> + softpipe->psize_slot = vinfo->num_attribs;
>>> + draw_emit_vertex_attr(vinfo, EMIT_4F, INTERP_CONSTANT, vs_index);
>>> + }
>>> +
>>> + /* Figure out if we need viewport index */
>>> + vs_index = draw_find_shader_output(softpipe->draw,
>>> + TGSI_SEMANTIC_VIEWPORT_INDEX,
>>> + 0);
>>> + if (vs_index >= 0) {
>>> + softpipe->viewport_index_slot = vinfo->num_attribs;
>>> + draw_emit_vertex_attr(vinfo, EMIT_4F, INTERP_CONSTANT, vs_index);
>>> + } else {
>>> + softpipe->viewport_index_slot = 0;
>>> }
>>>
>>> - softpipe->layer_slot = draw_find_shader_output(softpipe->draw,
>>> - TGSI_SEMANTIC_LAYER, 0);
>>> - if (softpipe->layer_slot >= 0) {
>>> - draw_emit_vertex_attr(vinfo, EMIT_4F, INTERP_CONSTANT, softpipe->layer_slot);
>>> + /* Figure out if we need layer */
>>> + vs_index = draw_find_shader_output(softpipe->draw,
>>> + TGSI_SEMANTIC_LAYER,
>>> + 0);
>>> + if (vs_index >= 0) {
>>> + softpipe->layer_slot = vinfo->num_attribs;
>>> + draw_emit_vertex_attr(vinfo, EMIT_4F, INTERP_CONSTANT, vs_index);
>>> + } else {
>>> + softpipe->layer_slot = 0;
>>> }
>
> This switches from assigning psize_slot (and layer) the result of
> draw_find_shader_output() to assigning vinfo->num_attribs. It is true
> that llvmpipe does the latter too, but apparently this doesn't work for
> softpipe. Albeit I can't quite tell you how this works with softpipe.
> Maybe it doesn't use the post-mapped indices at all for some reason
> though I don't quite see how this interacts with draw (fwiw this would
> actually also mean that those slots can be zero and still valid since
> output doesn't need to be at 0 as it has to if you use
> vinfo->num_attribs, albeit I believe you're unlikely to hit such a case
> with piglit, but it would be better to use -1 to indicate invalid slots
> in this case).
>
> Can you take a look at that?
>
> Roland
>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list