Explicit locations are only used with uniform variables.
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>
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>
Fixes assertion failure with new piglit
arb_draw_buffers_blend-state_set_get test.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
src/mesa/drivers/dri/i965/brw_program.c:94:39:
warning: passing argument 1 of ‘_mesa_init_gl_program’ from incompatible
pointer type [-Wincompatible-pointer-types]
return _mesa_init_gl_program(&prog->program, target, id);
^
Runtime was unaffected as brw_geometry_program is subclassed from
gl_geometry_program, thus the address passed was the same.
Fixes: bcb56c2c69 (program: convert _mesa_init_gl_program() to take
struct gl_program *)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This avoids a serious r600g bug leading to a GPU hang.
The chances this bug will get fixed are pretty low now.
I deeply regret listening to others and not pushing this patch, leaving
other users with a GPU-crashing driver. Yes, it should be fixed
in the compiler and it's ugly, but users couldn't care less about that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86720
Cc: 11.0 10.6 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
This exposes more information to NIR's optimization, and should be
particularly useful when we do range-based optimization.
total uniforms in shared programs: 32066 -> 32065 (-0.00%)
uniforms in affected programs: 21 -> 20 (-4.76%)
total instructions in shared programs: 93104 -> 92630 (-0.51%)
instructions in affected programs: 31901 -> 31427 (-1.49%)
The TGSI usage mask can't be used, because these are declared as an output
array of 2 elements.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
The "current" shader pointer is moved from the CSO to the context, so that
the CSO is mostly immutable.
The only drawback is that the "current" pointer isn't saved when unbinding
a shader and it must be looked up when the shader is bound again.
This is also a prerequisite for multithreaded shader compilation.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
All tests pass. We don't need to do much - just set CUBE if the view
target is CUBE or CUBE_ARRAY, otherwise set the resource target.
The reason this can be so simple is that texture instructions
have a greater effect on the target than the sampler view.
Thanks Glenn for the piglit test.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This also removes the validation from the parser as it is not required
and once arb_enhanced_layouts comes along we wont be able to do validation
on the stream qualifier in the parser anyway as it adds constant expression
support to the stream qualifier.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: 11.0 <mesa-stable@lists.freedesktop.org>
Fixes regression cased by bb5aeb8549
We don't care about the swizzle when building the name so just skip over it.
Tested-by: Markus Wick <markus@selfnet.de>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
NIR considers bcsel to produce and consume unsigned types, leading to
SEL instructions operating on unsigned types when the data is really
floating-point. Previous to this patch, saturate propagation would
happily transform
(+f0) sel g20:UD, g30:UD, g40:UD
mov.sat g50:F, g20:F
into
(+f0) sel.sat g20:UD, g30:UD, g40:UD
mov g50:F, g20:F
But since the meaning of .sat is dependent on the type of the
destination register, this is not valid.
Instead, allow saturate propagation to change the types of dest/source
on instructions that are simply copying data in order to propagate the
saturate modifier.
Fixes bad code gen in 158 programs.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Make them members of fs_inst/vec4_instruction for use elsewhere.
Also fix the fs version to check that dst.type == src[1].type and for
!saturate.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Tapani Pälli
Brian Paul
Anuj Phogat
Emil Velikov
Marek Olšák
Eric Anholt
Boyan Ding
Timothy Arceri
Leo Liu
Matt Turner