This fixes assigning explicit locations in the CTS test:
ES31-CTS.explicit_uniform_location.uniform-loc-arrays-of-arrays
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
process_parameters() will now be called earlier because we need
actual_parameters processed earlier so we can use it with
match_subroutine_by_name() to get the subroutine variable, we need
to do this inside the recursive function generate_array_index() because
we can't create the ir_dereference_array() until we have gotten to the
outermost array.
For the remainder of the array dimensions the type doesn't matter so we
can just use the existing _mesa_ast_array_index_to_hir() function to
process the ast.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Check current_var directly instead of using the passed in record_type.
This fixes following failing CTS test:
ES31-CTS.explicit_uniform_location.uniform-loc-types-structs
No Piglit regressions.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
UniformRemapTable is used only for remapping user specified uniform
locations to driver internally used ones, shader storage buffer
variables should not utilize uniform locations.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
A third instance of this was needed but missed in the previous commit.
Return 32 as for the two other cases.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
When the draw module splits long line loops, the sections are emitted
as line strips. But the primitive type wasn't set correctly so each
section was being drawn as a loop, introducing extra line segments.
To fix this, we pass a new DRAW_LINE_LOOP_AS_STRIP flag to the run()
function. The linear/elt_run() functions have to check for this flag
and set their primitive type accordingly.
No piglit regressions. Fixes piglit's lineloop with -count 4097 or
higher.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Patch just does some refactoring to make the code look better. No
functional changes in here.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Now that we have a decent interface in upstream mesa, we can get rid of all
our hacks. As of this commit, we no longer use any fake GL state objects
and all of shader compilation is moved into anv_pipeline.c. This should
make way for actually implementing a shader cache one of these days.
As a nice side-benifit, this commit also gains us an extra 300 passing CTS
tests because we're actually filling out the texture swizzle information
for vertex shaders.
The geometry shader support is currently completely untested. As I go
through and re-factor the compiler, I'd rather not refactor dead code that
I don't have a way to know if I broke. Let's just remove it for now. We
can put it back in easily enough later and then we'll do it properly.
When a long GL_LINE_LOOP prim was split across primitives we drew
stray lines. See previous commit for details.
This patch converts GL_LINE_LOOP prims into GL_LINE_STRIP prims so
that drivers don't have to worry about the _mesa_prim::begin/end flags.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Acked-by: Sinclair Yeh <syeh@vmware.com>
When long GL_LINE_LOOP primitives don't fit in one vertex buffer they
have to be split across buffers. The code to do this was basically correct
but drivers had to pay special attention to the _mesa_prim::begin,end flags
in order to draw the sections of the line loop properly. Apparently, the
only drivers to do this were those using the old 'tnl' module for software
vertex processing.
Now we convert the split pieces of GL_LINE_LOOP prims into GL_LINE_STRIP
primitives so that drivers don't have to worry about the special begin/end
flags. The only time a driver will get a GL_LINE_LOOP prim is when the
whole thing fits in one vertex buffer.
Mostly fixes bug 81174, but not completely. There's another bug somewhere
in the src/gallium/auxiliary/draw/ code. If the piglit lineloop test is
run with -count 4096, rendering is correct, but with -count 4097 there are
stray lines. 4096 is a magic number in the draw code (search for "4096").
Also note that this does not fix long line loops in display lists. The
next patch fixes that.
v2: fix incorrect -1 in vbo_compute_max_verts(), per Charmaine. Remove
incorrect assertion which was added in vbo_copy_vertices().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49779
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28130
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
As before, use a new 'last_prim' pointer to simplify things. Plus, add
some const qualifiers.
v2: use 'sz' in another place, per Sinclair. And update subject line.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Use a new 'last_prim' pointer to simplify things.
v2: remove unneeded assert(exec->vtx.prim_count > 0)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Whenever we got a glColor, glNormal, glTexCoord, etc. call outside a
glBegin/End pair, we'd immediately map a vertex buffer to begin
accumulating vertex data. In some cases, such as with display lists,
this led to excessive vertex buffer mapping. For example, if we have
a display list such as:
glNewList(42, GL_COMPILE);
glBegin(prim);
glVertex2f();
...
glVertex2f();
glEnd();
glEndList();
Then did:
glColor3f();
glCallList(42);
We'd map a vertex buffer as soon as we saw glColor3f but we'd never
actually write anything to it. Note that the vertex position data
was put into a vertex buffer during display list compilation.
With this change, we delay mapping the vertex buffer until we actually
have a vertex to write to it (triggered by a glVertex() call). In the
above case, we no longer map a vertex buffer when setting the color and
calling the list.
For drivers such as VMware's, reducing buffer mappings gives improved
performance.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
If we didn't find a gallium surface format that exactly matched the
glDrawPixels format/type combination, we used some other 32-bit packed
RGBA format and swizzled the whole image in the mesa texstore/format code.
That slow path can be avoided in some common cases by using the
pipe_samper_view's swizzle terms to do the swizzling at texture sampling
time instead.
For now, only GL_RGBA/ubyte and GL_BGRA/ubyte combinations are supported.
In the future other formats and types like GL_UNSIGNED_INT_8_8_8_8 could
be added.
v2: fix incorrect swizzle setup (need to invert the tex format's swizzle)
Reviewed by: Jose Fonseca <jfonseca@vmware.com>
So that we can use it directly from the mesa/gallium state tracker.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Before, if make_texture() or st_create_texture_sampler_view() failed
we silently no-op'd the glDrawPixels. Now, set GL_OUT_OF_MEMORY.
This also allows us to un-nest a bunch of code.
v2: also check if allocation of sv[1] fails, per Jose.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Prefix all anv_cmd_state dirty bit tokens with ANV_CMD_DIRTY. For
example:
old -> new
ANV_DYNAMIC_VIEWPORT_DIRTY -> ANV_CMD_DIRTY_DYNAMIC_VIEWPORT
ANV_CMD_BUFFER_PIPELINE_DIRTY -> ANV_CMD_DIRTY_PIPELINE
Change type of anv_cmd_state::dirty and ::compute_dirty from uint32_t to
the self-documenting type anv_cmd_dirty_mask_t.
The Vulkan spec allows VkGraphicsPipelineCreateInfo::pDepthStencilState
to be NULL when the pipeline's subpass contains no depthstencil
attachment (see spec quote below). anv_pipeline_init_dynamic_state()
required it unconditionally.
This path fixes anv_pipeline_init_dynamic_state() to access
pDepthStencilState only when there is a depthstencil attachment.
From the Vulkan spec (20 Oct 2015, git-aa308cb)
pDepthStencilState [...] may only be NULL if renderPass and subpass
specify a subpass that has no depth/stencil attachment.
The Vulkan spec (20 Oct 2015, git-aa308cb) states that some fields of
VkGraphicsPipelineCreateInfo are required under certain conditions.
Add a new function, anv_pipeline_validate_create_info() that asserts the
requirements hold.
The assertions helped me discover bugs in Crucible and anv_meta.c.
The Vulkan spec (20 Oct 2015, git-aa308cb) requires that
VkGraphicsPipelineCreateInfo::renderPass be a valid handle. To satisfy
that, define a static dummy render pass used for all meta operations.
Timothy Arceri