We're going to want the full vtn_type available to us anyway at which
point glsl_type isn't really buying us anything.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
This adds a vtn concept of base_type as well as a couple of other
fields. This lets us be a tiny bit more efficient in some cases but,
more importantly, it will eventually let us express things the GLSL type
system can't.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Now that we have a pointer wrapper class, we can create offsets for UBOs
and SSBOs up-front instead of waiting until we have the full access
chain. For push constants, we still use the old mechanism because it
provides us with some nice range information.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Everyone now calls it with stop_at_matrix = false. Since we're now
always walking all the way to the end of the access chain, the type
returned is just the same as ptr->type;
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
The vtn_pointer structure provides a bit better abstraction than passing
access chains around directly. For one thing, if the pointer just
points to a variable, we don't need the access chain at all. Also,
pointers know what their dereferenced type is so we can avoid passing
the type in a bunch of places. Finally, pointers can, in theory, be
extended to the case where you don't actually know what variable is
being referenced.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
We're about to add a vtn_pointer data structure and this will prevent
some rename churn in the next commit.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Doom shipped with a broken version of GLSLang which handles samplers as
function arguments in a way that isn't spec-compliant. In particular,
it creates a temporary local sampler variable and copies the sampler
into it. While Dave has had a hack patch out for a while that gets it
working, we've never landed it because we've been hoping that a game
update would come out with fixed shaders. Unfortunately, no game update
appears on to be on the horizon and I've found this issue in yet another
application so I think we're stuck working around it. Hopefully, we can
delete this code one day.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99467
Cc: "17.1" <mesa-stable@lists.freedesktop.org>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We need to:
- handle the extra array level for per-vertex varyings
- handle the patch qualifier correctly
- assign varying locations
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
SPIR-V does not have special opcodes for DF conversions. We need to identify
them by checking the bit size of the operand and the result.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I expect over time the struct contents will change as all
drivers support stuff etc, but for now this should be a good
starting point.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Previously, we were saving off the last nir_block in a vtn_block before
moving on so that we could find the nir_block again when it came time to
handle phi sources. Unfortunately, NIR's control flow modification code is
inconsistent when it comes to how it splits blocks so the block pointer we
saved off may point to a block somewhere else in the shader by the time we
get around to handling phi sources. In order to get around this, we insert
a nop instruction and use that as the logical end of our block. Since the
control flow manipulation code respects instructions, the nop will keeps
its place like any other instruction and we can easily find the end of our
block when we need it.
This fixes a bug triggered by a couple of vkQuake shaders.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97233
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Tested-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This isn't allowed by Vulkan, but might be useful someday for
SPIR-V in OpenGL (if that ever becomes a thing). It's easy enough
to hook up, and as precedent, we already do so for OriginLowerLeft.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
While it does rely on NIR, it's not really part of the NIR core. At the
moment, it still builds as part of libnir but that can be changed later if
desired.
2016-04-14 10:28:47 -07:00
Renamed from src/compiler/nir/spirv/vtn_private.h (Browse further)