The old logic would let all negative values go through unclamped, with
potentially disastrous results (probably trying to fetch viewport values
from random memory locations). GL has undefined rendering for vp indices
outside valid range but that's a bit too undefined...
(The logic is now the same as in llvmpipe.)
CC: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu>
(cherry picked from commit 604e54de78)
EGL 1.4 Specification says that
eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT)
can be used to release the current thread's ownership on the surfaces
and context.
MESA's egl implementation was only accepting the parameters when the
KHR_surfaceless_context extension is supported.
[chadv] Add quote from the EGL 1.4 spec.
Cc: "10,1, 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 0ca0d5743f)
Prior to GLX 1.3 there was the glxMakeCurrent() function that took a
single drawable handle. The Drawable could be either a bare XID for a
Window or an XID for a glxpixmap.
GLX 1.3 added glxMakeContextCurrent that takes 2 handles: one for
reading, one for writing. Nowadays the old glxMakeCurrent call is
implemented as a call to glxMakeContextCurrent with the single handle
duplicated.
Because of this it is allowed to use a plain-old Window ID as an
argument to glxMakeContextCurrent, although nobody really documents this
sort of thing. The manpage for the NEW call specifies the arguments as
GLXPixmaps, but the actual code accepts Window XIDs too, and handles
them correctly.
Similarly, the glxSelectEvents function can also take a bare Window XID.
The "piglit" tests all use GLXWindows and/or GLXPixmaps. You never
tested swap events with a bare Window XID. That is what my app was
doing.
The swap_events code worked with Window XIDs in mesa 7.x.y. The new code
added in versions 8, 9, and 10 assumes that all buffer swap events have
a GLXPixmap associated with them. Because of the historical quirks
above, this is not true. Swap events for bare Window XIDs do NOT have a
glxpixmap resulting in a segfault.
Any app that uses the old school glxMakeCurrent call with a Window XID
while trying to use swap_events will crash when the libs try to lookup
the nonexistent GLXPixmap associated with the incoming swap event.
I believe that the people who wrote the spec overlooked this, because
the "sbc" field comes from the OML_sync extension that is defined in
terms of glxpixmaps only.
v2 (idr): Formatting changes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 86bd2196b4)
An LLVMContext should only be accessed by a single and using the global
context was causing crashes in multi-threaded environments. Now we use
a separate context for each compile.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
CC: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 4aa128a123)
A drawable size of 0x0 means that we don't have buffers for a drawable yet,
not that we have a zero-sized buffer. Core mesa shouldn't be optimizing out
drawing based on buffer size, since the draw call could be what triggers
the driver to go and get buffers. As discussed in the referenced bug report,
the optimization was added as part of a scatter-shot attempt to fix a
different problem. There's no other example in mesa core of using the
buffer size in this way.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 7928b946ad)
When a multisampled texture is used for sampling the fast clear color value
needs to be programmed into the surface state. This was being left as all
zeroes so if the surface was cleared to a value other than black then it
wouldn't work properly. This doesn't matter for single-sample textures because
in that case the MCS buffer is resolved before it is used as a texture source.
https://bugs.freedesktop.org/show_bug.cgi?id=79729
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 765efeef88)
This fixes:
In file included from
/home/adrian/workspace/mesa/mesa-master.git/src/mesa/vbo/vbo_exec_api.c:445:0:
/home/adrian/workspace/mesa/mesa-master.git/src/mesa/vbo/vbo_attrib_tmp.h:28:38:
fatal error: util/u_format_r11g11b10f.h: No such file or directory
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit 0048483f73)
Fixes linker error:
ld:
.../libmesa_dri_common_intermediates/libmesa_dri_common.a(dri_util.o):
in function globalDriverAPI:dri_util.c(.data.rel+0x0): error:
undefined reference to 'driDriverAPI'
As an example, you can see that mesa_dri_drivers
also uses common/libmegadriver_stub (src/mesa/drivers/dri/Makefile.am)
The _stub part might be confusing, but
it actually provides the dri-driver shared lib constructor,
megadriver_stub_init, which will later on load the real
platform dependent part and call
l __driDriverGetExtensions_<platform>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit aba0f152be)
A recent ApiTrace change, that tries to dump more buffer state
causes Mesa from my distro (10.1.4) to segfaults here.
I haven't actually confirm this fixes it (I can't repro on master),
but it seems a good idea to be defensive here anyway.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit eb58aa9cf0)
Same as b026b6bbfe, but
COLOR_ARRAY_SIZE/SECONDARY_COLOR_ARRAY_SIZE.
Ideally we wouldn't munge the incoming state, so that we wouldn't need
to unmunge it back on glGet*. But the array size state is copied and
referred in many places, many of which couldn't take an GLenum like
GL_BGRA instead of a plain integer. So just hack around on glGet*,
to ensure there is no risk of introducing regressions elsewhere.
This bug causes problems to Apitrace, resulting in wrong traces. See
https://github.com/apitrace/apitrace/issues/261 for details.
Tested with piglit arb_vertex_array_bgra-get, which was created for this
purpose.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit e3e13d6b85)
Framebuffers can have NULL attachments since a while. llvmpipe handled
that properly for lp_rast_shade_quads_mask but it seems the change didn't
make it to lp_rast_shade_tile.
This fixes piglit fbo-drawbuffers-none test (though I need to increase
the FB_SIZE from 32 to 256 so the tris cover some tiles fully).
https://bugs.freedesktop.org/show_bug.cgi?id=79421
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
(cherry picked from commit 576868140b)
The call to get_variable_being_redeclared() may delete 'var' so we
can't reference var->name afterward. We fix that by examining the
var's name before making that call.
Fixes valgrind warnings and possible crash when running the piglit
tests/spec/glsl-1.30/execution/clipping/vs-clip-distance-in-param.shader_test
test (and probably others).
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit f9cecca7a6)
The glGetGraphicsResetStatusARB from ARB_robustness extension always
returns GUILTY_CONTEXT_RESET_ARB and never returns NO_ERROR for guilty
context with LOSE_CONTEXT_ON_RESET_ARB strategy. This is because Mesa
returns GUILTY_CONTEXT_RESET_ARB if batch_active !=0 whereas kernel
driver never reset batch_active and this variable always > 0 for guilty
context. The same behaviour also can be observed for batch_pending and
INNOCENT_CONTEXT_RESET_ARB.
But ARB_robustness spec says:
If a reset status other than NO_ERROR is returned and subsequent calls
return NO_ERROR, the context reset was encountered and completed. If a
reset status is repeatedly returned, the context may be in the process
of resetting.
8. How should the application react to a reset context event?
RESOLVED: For this extension, the application is expected to query the
reset status until NO_ERROR is returned. If a reset is encountered, at
least one *RESET* status will be returned. Once NO_ERROR is
encountered, the application can safely destroy the old context and
create a new one.
The main problem is the context may be in the process of resetting and
in this case a reset status should be repeatedly returned. But looks
like the kernel driver returns nonzero active/pending only if the
context reset has already been encountered and completed. For this
reason the *RESET* status cannot be repeatedly returned and should be
returned only once.
The reset_count and brw->reset_count variables can be used to control
that glGetGraphicsResetStatusARB returns *RESET* status only once for
each context. Note the i915 triggers reset_count twice which allows to
return correct reset count immediately after active/pending have been
incremented.
v2 (idr): Trivial reformatting of comments.
Signed-off-by: Pavel Popov <pavel.e.popov@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 8dc4a98c44)
These instructions can come in either through IMUL_HI/UMUL_HI TGSI
opcodes, or from OP_DIV constant folding.
Also make sure that the constant foldings which delete the original
instruction still get counted as having done something.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
(cherry picked from commit d2a3de19c6)
Retrieving the high 32 bits of a signed multiply is rather annoying. It
appears that the simplest way to do this is to compute the absolute
value of the arguments, and perform a u32 x u32 -> u64 operation. If the
arguments' signs differ, then negate the result. Since there is no u64
support in the cvt instruction, we have the perform the 2's complement
negation "by hand".
This logic can come into use by the IMUL_HI instruction (very unlikely
to be seen), as well as from constant folding of division by a constant.
Fixes dolphin's divisions by 255.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
(cherry picked from commit d3a5cf052c)
UNION appears to expect that all of its sources are conditionally
defined. Otherwise it inserts an unpredicated mov instruction which
overwrites the desired result. This fixes tests that use UMUL_HI, and
much less directly, unsigned integer division by a constant, which uses
this functionality in a peephole pass.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
(cherry picked from commit 5b8f1a0f7c)
The first was apparently not entirely suitable for stable, (and buggy). And
the second existed only to fix a bug in the first. So without the first, we
don't need either.
We allocate dispatch tables for BeginEnd and OutsideBeginEnd. But
when we destroy the context we were freeing the BeginEnd and Exec
tables. If Exec==BeginEnd we did a double-free. This would happen
if the context was destroyed while inside a glBegin/End pair. Now
free the BeginEnd and OutsideBeginEnd pointers.
Cc: "10.1", "10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit ef6b6658f9)
Improves performance of a dolphin emulator trace I had laying around by
3.60131% +/- 0.995887% (n=128).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 9245206cbf)
Different textures may be bound to each slot for each stage. So we need
to be able to upload ms parameters for each one without stages
overwriting each other.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 863573b9cb)
1D array targets store the number of slices in the Height field.
Fixes Piglit's spec/!OpenGL 3.2/layered-rendering/clear-color-all-types
1d_array single_level, at least when used with Meta clears.
Cc: "10.2 10.1 10.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
(cherry picked from commit e6967270c7)
This should have happend around the time of commit 4680d23, but Keith's
DRI3 patches and my GLX_MESA_query_renderer patches crossed in the mail.
I don't have a working DRI3 setup, so I haven't been able to actually
verify this. I'm hoping that someone can piglit this for me on DRI3...
It's also unfortunate the DRI2 and DRI3 can't share more code.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Keith Packard <keithp@keithp.com>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 625bdd64e5)
Conflicts:
src/glx/dri3_glx.c
During the cherry-pick, the following commit was squashed in as well:
glx: Conditionally compile GLX_MESA_query_renderer DRI3 support
Missed out with commit 625bdd64e5.
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 0b307afd57)
Link error conditions added in previous patch are equally applicable
to GL_ARB_fragment_coord_conventions implementation. Extension's spec
says:
"If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that program
that have a static use of gl_FragCoord. All redeclarations of
gl_FragCoord in all fragment shaders in a single program must have
the same set of qualifiers."
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 9bcb0a8532 with some
manual backporting)
GLSL 1.50 spec says:
"If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that
program that have a static use gl_FragCoord. All redeclarations of
gl_FragCoord in all fragment shaders in a single program must
have the same set of qualifiers."
This patch causes the shader link to fail if we have multiple fragment
shaders with conflicting layout qualifiers for gl_FragCoord.
V2: Restructure the code and add conditions to correctly handle the
following case:
fragment shader 1:
layout(origin_upper_left) in vec4 gl_FragCoord;
void main()
{
foo();
gl_FragColor = gl_FragData;
}
fragment shader 2:
layout(pixel_center_integer) in vec4 gl_FragCoord;
void foo()
{
}
V3:
Allow linking in the following case:
fragment shader 1:
void main()
{
foo();
gl_FragColor = gl_FragCoord;
}
fragment shader 2:
in vec4 gl_FragCoord;
void foo()
{
...
}
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 35f11e85cb with some
manual backporting)
This patch was ignored when we saw it causing a piglit test to regress. That
piglit test has been determined to have been incorrect. It has been fixed so
that this patch is now clearly a bug fix, not a regression.
V2: Follow the new naming convention for unpack functions.
Use double precision for converting Z24 to a float.
V3: Unpack stencil value to most significant byte.
Use 'struct z32f_x24s8' type.
V4: Unpack stencil value to least significant byte.
Add a comment to clarify stencil packing.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 29b8e894d1)
Depth-stencil teture targets are allowed to use source data of type
GL_UNSIGNED_INT_24_8_EXT and GL_FLOAT_32_UNSIGNED_INT_24_8_REV.
Fixes few crashes in Khronos OpenGL CTS packed_pixels tests.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit aeb9d4495d)
Section 4.3.8.1, page 39 of GLSL 1.50 spec says:
"Within any shader, the first redeclarations of gl_FragCoord
must appear before any use of gl_FragCoord."
GLSL compiler should generate an error in following case:
vec4 p = gl_FragCoord;
layout(origin_upper_left) in vec4 gl_FragCoord;
void main()
{
}
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit a751adf071)
GLSL 1.50 spec says:
"If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that
program that have a static use gl_FragCoord. All redeclarations of
gl_FragCoord in all fragment shaders in a single program must
have the same set of qualifiers."
This patch makes the glsl compiler to generate an error if we have a
fragment shader defined with conflicting layout qualifier declarations
for gl_FragCoord. For example:
layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;
layout(pixel_center_integer) in vec4 gl_FragCoord;
void main()
{
}
V2: Some code refactoring for better readability.
Add compiler error conditions for redeclarations like:
layout(origin_upper_left) in vec4 gl_FragCoord;
layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;
and
in vec4 gl_FragCoord;
layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;
V3: Simplify function is_conflicting_fragcoord_redeclaration()
V4: Check for null pointer before doing strcmp(var->name, "gl_FragCoord").
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 581e4acb0d)
In OpenGL 3.1 attribute 0 becomes non-magic, just like in
OpenGL ES 2.0. Earlier versions of OpenGL used attribute 0
exclusively for vertex position.
V2: Add a utility function _mesa_attr_zero_aliases_vertex() in
varray.h
Fixes 4 Khronos OpenGL CTS failures:
glGetVertexAttrib
depth24_basic
depth24_precision
rgb8_rgba8_rgb
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 49c71050de)
This patch makes changes to the behavior of glGetAttribLocation(),
glGetFragDataLocation() and glGetFragDataIndex() functions.
Code changes handle a case described in following example:
shader program:
layout(location = 1)in vec4[4] a;
void main()
{
}
Currently, glGetAttribLocation("a") returns 1.
glGetAttribLocation("a[i]"), where i = {0, 1, 2, 3}, returns -1.
But the expected locations for array elements are: 1, 2, 3 and 4
respectively.
This clarification came up with the addition of
ARB_program_interface_query to OpenGL 4.3.
From Page 326 (page 347 of the PDF) of OpenGL 4.3 spec:
"Otherwise, the command is equivalent to
GetProgramResourceLocation(program, PROGRAM_INPUT, name);"
And, From Page 101 (page 122 of the PDF) of OpenGL 4.3 spec:
"A string provided to GetProgramResourceLocation or
GetProgramResourceLocationIndex is considered to match an active
variable if
• the string exactly matches the name of the active variable;
• if the string identifies the base name of an active array, where
the string would exactly match the name of the variable if the
suffix "[0]" were appended to the string; or
• if the string identifies an active element of the array, where
the string ends with the concatenation of the "[" character, an
integer (with no "+" sign, extra leading zeroes, or whitespace)
identifying an array element, and the "]" character, the integer
is less than the number of active elements of the array variable,
and where the string would exactly match the enumerated name of
the array if the decimal integer were replaced with zero."
V2: Simplify get_matching_index() function.
Add relevant text from OpenGL spec in commit message.
Fixes failures in Khronos OpenGL CTS tests:
explicit_attrib_location_room
draw_instanced_max_vertex_attribs
Proprietary linux drivers of NVIDIA (331.49) matches the behavior
expected by OpenGL 4.3 spec.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit dc75479b7a)
Currently overlapping locations of input variables are not allowed for all
the shader types in OpenGL and OpenGL ES.
From OpenGL ES 3.0 spec, page 56:
"Binding more than one attribute name to the same location is referred
to as aliasing, and is not permitted in OpenGL ES Shading Language
3.00 vertex shaders. LinkProgram will fail when this condition exists.
However, aliasing is possible in OpenGL ES Shading Language 1.00 vertex
shaders."
Taking in to account what different versions of OpenGL and OpenGL ES specs
say about aliasing:
- It is allowed only on vertex shader input attributes in OpenGL (2.0 and
above) and OpenGL ES 2.0.
- It is explictly disallowed in OpenGL ES 3.0.
Fixes Khronos CTS failing test:
explicit_attrib_location_vertex_input_aliased.test
See more details about this at below mentioned khronos bug.
V2: Fix the case where location exceeds the maximum allowed attribute
location.
V3: Simplify the condition added in V2.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Bugzilla: Khronos #9609
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 8c61b6a99b)
For platforms using hardware contexts (currently Gen6+), we failed to
emit PIPELINE_SELECT and 3DSTATE_VF_STATISTICS, instead emitting MI_NOOP
for both.
During one of the context initialization reordering patches, we
accidentally moved brw_init_state before we set brw->CMD_PIPELINE_SELECT
and brw->CMD_VF_STATISTICS. So, when brw_init_state uploaded initial
GPU state (brw_init_state -> brw_upload_initial_gpu_state ->
brw_upload_invariant_state), these would be 0 (MI_NOOP).
Storing the commands in the context is not worthwhile. We have many
generation checks in our state upload code, and for platforms with
hardware contexts, this only gets called once per GL context anyway.
The cost is negligable, and it's easy to botch context creation
ordering.
This may fix hangs on Gen6+ when using the media pipeline.
Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
(cherry picked from commit ac30e1adb4)
Conflicts:
src/mesa/drivers/dri/i965/brw_context.h
arekm reported that using Chrome with GPU acceleration enabled on GM45
triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.
We definitely do not want to advertise reset notification support on
Gen4-5 systems, since it needs hardware contexts, and we never even
request a hardware context on those systems.
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75723
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 0380ec467d)
We've had several problems now with FinishRenderTexture not getting called
enough, and we're ready to just give up on it ever doing what we need. In
particular, an upcoming Steam title had rendering bugs that could be fixed
by always_flush_cache=true.
Instead of hoping Mesa core can figure out when we need to flush our
caches, just track what BOs we've rendered to in a set, and when we render
from a BO in that set, emit a flush and clear the set.
There's some overhead to keeping this set, but most of that is just
hashing the pointer -- it turns out our set never even gets very large,
because cache flushes are so common (even on cairo-gl).
No statistically significant performance difference in cairo-gl (n=100),
despite spending ~.5% CPU in these set operations.
v1: (Original patch by Eric Anholt.)
v2: (Changes by Ken Graunke.)
- Rebase forward from May 7th 2013 -> March 4th 2014.
- Drop the FinishRenderTexture hook entirely; after rebasing the
patch, the hook was just an empty function.
- Move the brw_render_cache_set_clear() call from
intel_batchbuffer_emit_flush() to brw_emit_pipe_control_flush().
In theory, this could catch more cases where we've flushed.
- Consider stencil as a possible texturing source.
v3: (changes by anholt):
- Move set_clear() back to emit_mi_flush() -- it means we can drop
more forced flushes from the code. In the previous location, it
wouldn't have been called when we wanted pre-gen6.
- Move the set clear from batch init to reset -- it should be empty at
the start of every batch, since the kernel handled any inter-batch
flush for us.
v4: Drop the debug code in set.c that I accidentally committed.
v5: Back port to 10.1 stable branch (remove reference to stencil texture.)
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Dylan Baker <baker.dylan.c@gmail.com> [v2]
Conflicts:
src/mesa/drivers/dri/i965/brw_draw.c
src/mesa/drivers/dri/i965/intel_fbo.h
This can happen with glamor, which uses EGL_KHR_surfaceless_context and
only explicitly binds GL_READ_FRAMEBUFFER for glReadPixels.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 136c437cea)
It looks like this bit of code is trying to disable the prime capability if
the driver doesn't support createImageFromFds. However the logic looks a bit
broken and what it would actually do is disable all other capabilities apart
from prime. This patch fixes it to actually disable prime.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 63d4661ab2)
Fixes a segmentation fault in conform divzero.c test.
This happens when glTexImage(level, width=0, height=0) is called. We
don't allocate texture memory in that case so the ImageSlices array
was never allocated.
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit 7cc2e2e99d)
Previously this was special-cased for VS and FS; it never got updated
when geometry shaders came along. Generalize using is_varying_var() so
this won't be broken again with tessellation.
Note that there are two copies of the logic for `invariant`: It can be
present as part of a new declaration, and also as a redeclaration of an
existing variable or block member.
Fixes the four new piglits:
spec/glsl-1.50/compiler/invariant-qualifier-*.geom
Note for stable: This won't quite pick cleanly due to whitespace and
state->target -> state->stage renames. Should be straightforward
adjustments though.
Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 0dfa6e7cf5)
Conflicts:
src/glsl/ast_to_hir.cpp
Section 4.3.1, page 220, of OpenGL 3.3 specification explains
the error conditions for glreadPixels():
"If the format is DEPTH_STENCIL, then values are taken from
both the depth buffer and the stencil buffer. If there is
no depth buffer or if there is no stencil buffer, then the
error INVALID_OPERATION occurs. If the type parameter is
not UNSIGNED_INT_24_8 or FLOAT_32_UNSIGNED_INT_24_8_REV,
then the error INVALID_ENUM occurs."
Fixes failing Khronos CTS test packed_depth_stencil_error.test
V2: Avoid code duplication
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit f8ae2a56c6)
From the OpenGL 4.4 spec page 275:
"If pname is FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE, param will
contain the format of components of the specified attachment,
one of FLOAT, INT, UNSIGNED_INT, SIGNED_NORMALIZED, or
UNSIGNED_NORMALIZED for floating-point, signed integer,
unsigned integer, signed normalized fixedpoint, or unsigned
normalized fixed-point components respectively. If no data
storage or texture image has been specified for the attachment,
param will contain NONE. This query cannot be performed for a
combined depth+stencil attachment, since it does not have a
single format."
Fixes Khronos CTS test: packed_depth_stencil_parameters.test
Khronos Bug# 9170
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit bd1880dfe8)
OpenGL 4.0 spec, page 306 suggests an INVALID_OPERATION in glGetTexImage
if :
"format is one of the integer formats in table 3.3 and the internal
format of the texture image is not integer, or format is not one of
the integer formats in table 3.3 and the internal format is integer."
V2: Use helper function _mesa_is_format_integer()
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit cb6566f9df)
gl_ViewportIndex doesn't get its own varying slot. It is stored
in VARYING_SLOT_PSIZ.z. This patch fixes the issue for both gen7
and gen8 because gen7_upload_3dstate_so_decl_list() is shared
between them.
Fixes failures in OpenGL Khronos CTS test transform_feedback_builtins.
Makes new piglit test glsl-1.50-transform-feedback-builtins pass for
'gl_ViewportIndex'.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 48fc2703e5)
gl_Layer doesn't get its own varying slot. It is stored in
VARYING_SLOT_PSIZ.y. This patch fixes the issue for both gen7
and gen8 because gen7_upload_3dstate_so_decl_list() is shared
between them.
Fixes failures in OpenGL Khronos CTS test transform_feedback_builtins.
Makes new piglit test glsl-1.50-transform-feedback-builtins pass for
'gl_Layer'.
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 7928b9c249)
Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource). This is really badness for tiling GPUs
like adreno.
This also appears to fix a rendering error with Motif on vmwgfx.
Why that is is still under investigation.
Based on an idea by Rob Clark.
Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
(cherry picked from commit 09cd376353)
According to the spec:
<renderbuffertarget> must be RENDERBUFFER and <renderbuffer>
should be set to the name of the renderbuffer object to be
attached to the framebuffer. <renderbuffer> must be either
zero or the name of an existing renderbuffer object of type
<renderbuffertarget>, otherwise an INVALID_OPERATION error is
generated.
This patch changes the previous returned GL_INVALID_VALUE to
GL_INVALID_OPERATION.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76894
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
(cherry picked from commit 9927180714)
mesa currently returns 4 when GL_VERTEX_ATTRIB_ARRAY_SIZE is queried
for a vertex array initially set up with size=GL_BGRA. This patch
makes changes to return size=GL_BGRA as required by the spec.
Fixes Khronos OpenGL CTS test: vertex_array_bgra_basic.test
V2: Use array->Format instead of adding a new variable
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
(cherry picked from commit fdd8bebc22)
For graphics, the LLVM compiler backend currently has many shortcomings
compared to the non-LLVM one. E.g. it can't handle geometry shaders yet,
but that's just the tip of the iceberg.
So building Mesa with --enable-r600-llvm-compiler is currently not
recommended for anyone who doesn't want to work on fixing those issues.
However, for protection of users who end up enabling it anyway for some
reason, let's disable the LLVM backend at runtime by default. It can be
enabled with the environment variable R600_DEBUG=llvm.
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
(cherry picked from commit 7286739b9b)
This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in the X
Server. Today we decided that the problem in compositors was equivalent
to a corruption bug we'd noticed recently in resizing MSAA-visual
glxgears, and debugging got a lot easier.
When we allocate our MCS MT, libdrm takes the size we request, aligns it
to Y tile size (blowing it up from 300x300=900000 bytes to 384*320=122880
bytes, 30 pages), then puts it into a power-of-two-sized BO (131072 bytes,
32 pages). Because it's Y tiled, we attach a 384-byte-stride fence to it.
When we memset by the BO size in Mesa, between bytes 122880 and 131072 the
data gets stored to the first 20 or so scanlines of each of the 3 tiled
pages in that row, even though only 2 of those pages were allocated by
libdrm. In the glxgears case, the missing 3rd page happened to
consistently be the static VBO that got mapped right after the first MCS
allocation, so corruption only appeared once window resize made us throw
out the old MCS and then allocate the same BO to back the new MCS.
Instead, just memset the amount of data we actually asked libdrm to
allocate for, which will be smaller (more efficient) and not overrun.
Thanks go to Kenneth for doing most of the hard debugging to eliminate a
lot of the search space for the bug.
Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77207
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 7ae870211d)
Putting NoDDClr and NoDDChk dependency control on instruction
sequences that include math opcodes can cause corruption of channels.
Treat math opcodes like send opcodes and suppress dependency hinting.
Signed-off-by: Mike Stroyan <mike@LunarG.com>
Tested-by: Tony Bertapelli <anthony.p.bertapelli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit 602510395a)
When considering assignment expressions like:
v.x += u.x;
v.x += u.x;
the vectorizer would incorrectly keep going, attempting to find more
instructions to vectorize. It would overwrite the saved assignment
to point at the second one, and increment channels a second time,
resulting in try_vectorize thinking the expression was a vec2 instead of
a float.
Instead, if we see a repeated assignment to a channel, just try to
vectorize everything we've found so far. This clears the saved state
so it will start over.
Fixes Piglit's repeated-channel-assignments.vert.
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit ae2a03b573)
For blocks, gl_shader_program::UniformStorage isn't very useful. The
names stored there are the names of the elements of the block, so
finding blocks with an instance name is hard. There is also only one
entry in ::UniformStorage for each element of a block array, and that is
a deal breaker.
Using ::UniformBlocks is what _mesa_GetUniformBlockIndex does. I
contemplated sharing code between set_block_binding and
_mesa_GetUniformBlockIndex, but building the stand-alone compiler and
the unit tests make this hard. I plan to return to this effort shortly.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit cc42717b50)
As of 943b2d52bf, layout(binding) on an atomic would fail the assertion
here.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 92840aabf7)
Conflicts:
src/glsl/link_uniform_initializers.cpp
In the next patch, we'll see that using
gl_shader_program::UniformStorage is not correct for uniform blocks.
That means we can't use ::UniformStorage to select between the sampler
path and the block path. Instead we want to just use the type of the
variable. That's never passed to set_uniform_binding, and it's easier
to just remove the function (especially for later patches in the series)
than to add another parameter.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76323
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Cc: github@socker.lepus.uberspace.de
(cherry picked from commit 943b2d52bf)
After the loader changes libudev is no longer required for
gbm or the egl drm/wayland platforms. Lets these build/run
on OpenBSD.
v2: preserve the libudev requirement for Linux as suggested
by Emil Velikov.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 81799c82e4)
Add the explicit note about the required version during configure.
Require the same version (151) of udev when building the pipe-loader.
Mention the udev version requirement in GBM Requires.private.
v2: Resolve a couple of silly typos. Spotted by Ilia
v3: Cleanup platfrom/platform typo. Spotten by Stefan
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 118c36adb4)
Linking with LLVM static libraries is easily broken by changes to
the llvm-config program or when LLVM adds, removes, or changes library
components. Keeping up with these changes requires a lot of maintanence
effort to keep the build working on the master and stable branches.
Also, because of issues in the past LLVM static libraries, the release
manager is currently configuring with --with-llvm-shared-libs when
checking the build before release. Enabling shared libraries by
default would allow the release manager to run ./configure with
no arguments, and be reasonably confident that the build would succeed.
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit a4c734297f)
Which would lead to translating
mad vgrf9:F, vgrf3:F, u0:F, vgrf6:F
mov.sat vgrf7:F, -vgrf9:F
into
mad.sat vgrf9:F, vgrf3:F, u0:F, vgrf6:F
mov vgrf7:F, -vgrf9:F
Fixes some lighting effects in Dota2.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 92d03f7f28)
ip needs to be initialized to start_ip - 1, since the first thing in the
main loop is ip++. Otherwise we would incorrectly propagate the saturate
from the mov to the mad:
mad a, b, c, d
mov.sat x, a
add y, z, a
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 86ae6f477d)
* Add HAVE_PTHREAD, we do have pthread support wrappers now for
non-native Haiku threaded applications.
* Viewport changed behavior recently breaking the build.
We fix this by looking at the gl_context ViewportArray
(Thanks Brian for the idea)
Acked-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 7683fce878)
Don't hardcode /dev/dri/card0 but instead use the drm
macros which allows the correct /dev/drm0 device to be
opened on OpenBSD.
v2: use snprintf and fallback to /dev/dri/card0
v3: check for snprintf truncation
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit c973e440d5)
With commit 1f1928db001(glx: Drop _Xglobal_lock while we create and
initialize glx display) we've split the big _Xglobal_lock handling in
a more fine grained manner.
Unfortunatelly we forgot to drop the unlock_mutex on the error paths,
leading to undefined behaviour as the mutex is already unlocked.
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit f9832f960f)
Fixes a crash in svga_context_flush_buffers() if we use the 'draw' module
for AA lines (when the device doesn't support that feature). We need to
initialize this list before we setup the swtnl pieces.
Found/fixed by Charmaine Lee.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
(cherry picked from commit e853ade544)
Conflicts:
src/gallium/drivers/svga/svga_context.c
The "new" fragment shader backend has never supported the necessary
color conversion code for this to work. We began using the new backend
in Mesa 7.10 for GLSL (commit a81d423d93, October 2010),
and for ARB_fragment_program in Mesa 9.1 (commit 97615b2d8c,
August 2012).
I haven't heard any complaints, so I don't think anyone will miss this
feature. I believe mplayer used it at one point, but these days
defaults to other paths anyway.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 26ae030fcc)
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
v2: add more detail comment. Compute limit outside inner loops.
v3: add bugzilla reference
v4: Correct cc syntax in commit log
v5: really grab the right patch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74988
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1, suggested v2-3]
(cherry picked from commit cb4ad13685)
For TEX instructions, the set of samplers and sampler views should
be consistent. The XA state tracker sometimes passes an inconsistent
set of samplers and sampler views. Rather than assert and die, issue
a warning.
v2: add debugging code to detect inconsistent state.
v3: also check for null sampler in svga_state_tss.c
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
(cherry picked from commit 9bb2ec6fd1)
Given
mov vgrf7, vgrf9.xyxz
add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
add vgrf10.x, vgrf6.xyzw, vgrf7.wwww
the last instruction would be wrongly changed to
add vgrf10.x, vgrf6.xyzw, vgrf9.zzzz
during copy propagation.
The issue is that when deciding if a record should be cleared, the old code
checked for
inst->dst.writemask & (1 << ch)
instead of
inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch))
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Cc: Jordan Justen <jljusten@gmail.com>
Cc: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romainck <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "10.1" <mesa-stable@freedesktop.org>
(cherry picked from commit 4ddf51db6a)
ir_binop_ubo_load takes unsigned integer operands. However, the array
index used to compute these offsets may be a signed integer. (For
example, see Piglit's spec/glsl-1.40/uniform_buffer/fs-bvec-array).
For some reason, we were missing an ir_binop_i2u cast, and ir_validator
was failing to catch that.
Without this change, ir_builder's type inference code broke for me when
writing a new optimization pass.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit e14b93371c)
renderer_copy_prepare was setting the first sampler but never telling
the cso code how many samplers were actually used. Fix this.
Cc: "10.1" <mesa-stable@freedesktop.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 47f60cbb71)
Binding a new destination may cause the svga driver to emit draw calls
while propagating the surface. Make sure this doesn't happen in the middle
of sampler state setup where state may be incosistent.
In practice, surface propagation should never happen here and even if it did,
it wouldn't be a valid reason for the svga driver to emit partially set up
state, but to avoid future uncertainties, make sure this doesn't happen
anyway.
Found while auditing the state tracker for inconsistent sampler state /
sampler view setup.
Cc: "10.1" <mesa-stable@freedesktop.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
(cherry picked from commit e5d2c5b899)
Implement guest-backed surface sharing using prime fds. Previously only
legacy surfaces could use this functionality. Also use the vmwgfx 2.6
single-ioctl prime fd reference if available.
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
(cherry picked from commit 2f6fcd65f2)
After the loader changes libudev is no longer required to
build gbm or the egl drm/wayland platforms.
Remove a libudev ifdef which allows the the drm egl driver
to be loaded on OpenBSD.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 0295953c5d)
The pkg-config module was called "EXPAT" instead of "expat" in
PKG_CHECK_EXISTS. This seems to have been wrong because the wrong
argument was copied from PKG_CHECK_MODULES.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 476db98e03)
_GNU_SOURCE is only set/required for linux*|*-gnu*|gnu*) and as the
functionality is available on other systems check for RTLD_DEFAULT instead.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 1cc742d912)
Platforms that lack libudev (OpenBSD and possibly others) need
this change in order to load the correct dri driver.
Under linux we unconditionally require libudev, thus this code
will never get build.
v2: Add commit message (Emil Velikov)
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 380f05ccc3)
We want to call pipe->set_sampler_views() with count being the
maximum of the old number of sampler views and the new number.
This makes sure we null-out any old sampler views.
We already do the same thing for sampler states in single_sampler_done().
Fixes some assertions seen in the VMware driver with XA tracker.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Tested-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
(cherry picked from commit 2355a64414)
This is to avoid running out of query buffer space due to winsys
limitations. Instead of a fixed size per screen pool of query buffers,
use a slab allocator that allocates a new slab if we run out of space
in the first one.
v2: Correct email addresses.
v3: s/8192/VMW_QUERY_POOL_SIZE/. Improve documentation and log message.
Reported-and-tested-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 5dc206525b)
The underlying glDrawArrays() calls weren't getting compiled into
the display list. We simply need to use the current dispatch table
so the CALL_DrawArrays() is routed to the display list save function.
This patch also fixes glMultiModeDrawArraysIBM and
glMultiModeDrawElementsIBM.
Fixes the new piglit gl-1.4-dlist-multidrawarrays test.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit e341856294)
Don't pass null query object pointers into gallium functions.
This avoids segfaulting in the VMware driver (and others?) if the
pipe_context::create_query() call fails and returns NULL.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
(cherry picked from commit 488d4c4826)
Release the references to the sampler views before
destroying the pipe context.
v2: remove TODO and unrelated change
v3: move to st_texture.[ch], rename callback, add comment
v4: fix rebase mess up and add further cleanups
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit d117ddbe31)
With shared glx contexts it is possible that a texture is create and used
in one context and then used in another one resulting in incorrect
sampler view usage.
v2: avoid template copy
v3: add XXX comment
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 92e543c45d)
The nvc0 texfetch instruction expects the sample id to be in the second
source (usually used for the offset) rather than as part of the texture
coordinate.
This fixes all the sampler2DMS/Array tests on nvc0.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 19ba573a57)
This fallback to triangle strips is silly and should be done in drivers
if they need it.
This should fix the case when quad strips are used with flatshading that is
enabled by the "flat" GLSL varying modifier. It also fixes primitive restart
for quad strips.
This fixes piglit:
NV_primitive_restart/primitive-restart-draw-mode-quad_strip
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit e5f6b6d0fe)
In the gallium code, the assert() macro could come from either the
system's assert.h file (via c11/threads.h) or from gallium's u_debug.h.
It looks like all known assert.h files unconditionally #undef assert
before defining their own version. So the assert you get depends on
whether threads.h or u_debug.h was included last.
In the gallium code we really want to use the assert() from u_debug.h
(it behaves better on Windows). In gallium, c11/threads.h is only
included after u_debug.h in the os_thread.h wrapper. So Adding
an #ifndef assert test in the threads*.h files avoids using the system's
assert().
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit eaf9affa5e)
EXT_packed_depth_stencil is supported by all drivers, but
ARB_depth_texture isn't (notably nouveau_vieux). This should avoid
passing unexpected values down to ChooseTextureFormat.
The EXT_packed_depth_stencil spec does not make any explicit references
to requiring ARB_depth_texture in order to allow textures with that
format, however if there is no dependency, ARB_depth_texture would be
practically implied by the extension.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Note for 10.0 backport: This will produce a conflict, the solution is to
move the surrounding if as well.
(cherry picked from commit 18690995a6)
The GL 4.4 spec says it's not color-renderable and not accepted
by RenderBufferStorage. The EXT_texture_shared_exponent spec says
it's not color-renderable but it's accepted by RenderBufferStorageEXT.
This seems to be a bug in the extension spec.
Let's do what GL 4.4 says.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 2e361160ff)
opt_saturate_propagation_local compares scan_inst->dst.reg/reg_offset
with inst->src[0].reg/reg_offset, and ensures that scan_inst->dst.file
is GRF. But nothing ensured that inst->src[0].file was GRF.
In the following program, this resulted in u1:F matching vgrf1:UW,
and a saturate being incorrectly propagated from instruction 8 to
instruction 1.
{ 1} 0: add vgrf0:UW, hw_reg1+8:UW, hw_reg0:V
{ 1} 1: add vgrf1:UW, hw_reg1+10:UW, hw_reg0:V
{ 1} 2: linterp vgrf6:F, hw_reg2:F, hw_reg3:F, hw_reg0:F
{ 2} 3: linterp vgrf27:F, hw_reg2:F, hw_reg3:F, hw_reg0+16:F
{ 4} 4: mov vgrf10+0.0:F, vgrf6:F
{ 3} 5: mov vgrf10+1.0:F, vgrf27:F
{ 6} 6: tex vgrf8+0.0:F, vgrf10+0.0:F
{ 5} 7: mov vgrf32:F, u1:F
{ 5} 8: mov.sat vgrf12:F, u1:F
From shader-db:
total instructions in shared programs: 1841932 -> 1841957 (0.00%)
instructions in affected programs: 5823 -> 5848 (0.43%)
I inspected two of the 25 hurt shaders, and concluded that they were
both hitting this bug, and not legitimately optimized.
This fixes bugs in Left 4 Dead 2 and Team Fortress 2, possibly among
others. The optimization pass didn't exist in 10.0, so this is only
a candidate for 10.1.
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 4d2e79269a)
Commit 3805a864b1d(nv50: assert before trying to out-of-bounds access
samplers) introduced a series of asserts as a precausion of a previous
illegal memory access.
Although it failed to encapsulate loop within nv50_sampler_state_delete
effectively failing to clear the sampler state, apart from exadurating
the illegal memory access issue.
Fixes gcc warning "array subscript is above array bounds" and
"Nesting level does not match indentation" and "Out-of-bounds read"
defects reported by Coverity.
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
(cherry picked from commit c26b488088)
CB_COLORi_VIEW.SLICE_MAX can be at most 2047.
This fixes the maxlayers piglit test.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 4f1f32306a)
Conflicts:
src/gallium/drivers/r600/r600_pipe.c
src/gallium/drivers/radeonsi/si_pipe.c
nouveau_fence_wait has the expectation that an external entity is
holding onto the fence being waited on, not that it is merely held onto
by the current pointer. Fixes a use-after-free in nouveau_fence_wait
when used on the screen's current fence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75279
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 507f0230d4)
Conflicts:
src/gallium/drivers/nouveau/nv30/nv30_screen.c
From OpenGL 3.3 spec, page 141:
"Textures with a base internal format of DEPTH_COMPONENT or DEPTH_STENCIL
require either depth component data or depth/stencil component data.
Textures with other base internal formats require RGBA component data.
The error INVALID_OPERATION is generated if one of the base internal
format and format is DEPTH_COMPONENT or DEPTH_STENCIL, and the other
is neither of these values."
Fixes Khronos OpenGL CTS test failure: proxy_textures_invalid_size
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 079bff5a99)
From OpenGL 4.0 spec, page 398:
"The initial internal format of a texel array is RGBA
instead of 1. TEXTURE_COMPONENTS is deprecated; always
use TEXTURE_INTERNAL_FORMAT."
Fixes Khronos OpenGL CTS test failure: proxy_textures_invalid_size
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 063980151e)
GetCurrentThread() returns a pseudo-handle (a constant which only makes
sense when used within the calling thread) and not a real handle.
DuplicateHandle() will return a real handle, but it will create a new
handle every time we call. Calling DuplicateHandle() here means we will
leak handles, which can cause serious problems.
In short, the Windows implementation of thrd_t needs a thorough make
over, and it won't be pretty. It looks like C11 committee
over-simplified things: it would be much better to have seperate objects
for threads and thread IDs like C++11 does.
For now, just comment out the thrd_current() implementation, so we get
build errors if anybody tries to use it.
Thanks to Brian Paul for spotting and diagnosing this problem.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit a61d859519)
u_thread_self() expects thrd_current() to return a unique numeric ID
for the current thread, but this is not feasible on Windows.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit e8d85034da)
BRW_MAX_TEX_UNIT is the static limit on the number of textures we
support per-stage, not in total.
Core's `Unit` array is sized by MAX_COMBINED_TEXTURE_IMAGE_UNITS, which
is significantly larger, and across the various shader stages, up to
ctx->Const.MaxCombinedTextureImageUnits elements of it may be actually
used.
Fixes invisible bad behavior in piglit's max-samplers test (although
this escalated to an assertion failure on HSW with texture_view, since
non-immutable textures only have _Format set by validation.)
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit befbda56a2)
Fixes glGetTexImage() when converting from MESA_FORMAT_Z32_FLOAT_S8X24_UINT
to GL_UNSIGNED_INT_24_8. Hit by the piglit
ext_packed_depth_stencil-getteximage test.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit a12d4d0398)
Though it won't matter on Linux, use _mesa_align_free to release it.
Since i965 doesn't have sys_buffer, I overlooked this in the
GL_ARB_map_buffer_alignment work a few months ago. Fixes i915 (and
presumably i830) regressions in ARB_map_buffer_range tests and the
failure in arb_map_buffer_alignment-sanity_test.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74960
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit ff2cbf9e0c)
There's no reason to have more vertex texture units than fragment
texture units on this hardware. Since increasing the default maximum
number of texture units from 16 to 32, this has triggered some segfault
in i915 driver. There's probably some array or bitfield that isn't
properly sized now. This really papers over the bug, but I don't think
I'll lose any sleep over that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74071
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit 8ba157006f)
v2: Don't add function parameters, pass the required size in
prog_data->nr_params.
v3:
- Use the name uniform_array_size instead of uniform_param_count.
- Round up when dividing param_count by 4.
- Use MAX2() instead of taking the maximum by hand.
- Don't crash if prog_data passed to vec4_visitor constructor is NULL
v4: Rebase for current master
v5 (idr): Trivial whitespace change.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71254
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 7189fce237)
glGetTexImage(GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8) was just
using memcpy() instead of _mesa_unpack_uint_24_8_depth_stencil_row()
to convert texels from the hardware format to the GL format.
Fixes issue reported by David Meng at Intel. The new piglit
ext_packed_depth_stencil-getteximage test checks for this bug.
Also, add some format/type assertions. We don't yet handle the
GL_FLOAT_32_UNSIGNED_INT_24_8_REV type. That should be fixed in
a follow-on patch.
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 43dee0295e)
Tt's kind of a trap---calling do_common_optimization() after
lower_instructions() may cause opt_algebraic() to reintroduce
ir_triop_lrp expressions that were lowered, effectively defeating the
point. Because of this, nobody uses it.
v2: Delete more code (caught by Ian Romanick).
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit ac0a8b9540)
When the vec4 backend encountered an ir_triop_lrp, it always emitted an
actual LRP instruction, which only exists on Gen6+. Gen4-5 used
lower_instructions() to decompose ir_triop_lrp at the IR level.
Since commit 8d37e9915a ("glsl: Optimize open-coded lrp into lrp."),
we've had an bug where lower_instructions translates ir_triop_lrp into
arithmetic, but opt_algebraic reassembles it back into a lrp.
To avoid this ordering concern, just handle ir_triop_lrp in the backend.
The FS backend already does this, so we may as well do likewise.
v2: Add a comment reminding us that we could emit better assembly if we
implemented the infrastructure necessary to support using MAC.
(Assembly code provided by Eric Anholt).
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75253
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 56879a7ac4)
The linux winsys needs to know whether a surface is shared.
For guest-backed surfaces we need this information to avoid allocating a
mob out of the mob cache for shared surfaces, but instead allocate a shared
mob, that is never put in the mob cache, from the kernel.
Also previously, all surfaces were given the "shareable" attribute when
allocated from the kernel. This is too permissive for client-local surfaces.
Now that we have the needed info, only set the "shareable" attribute if the
client indicates that it needs to share the surface.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 141e39a893)
In some situations, it may be desirable to bypass the cache at buffer
creation but to insert the buffer in the cache at buffer destruction.
One such situation is where we already have a kernel representation of a
buffer that we want to use, but we also want to insert it in the cache when
it's freed up.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 8af358d8bc)
In some situations it's important to restrict the sizes of buffers that the
cached buffer manager is allowed to return
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit c9e9b1862b)
This adds new interface functions for guest-backed surfaces and
adds a mobid parameter to the surface_relocation() function.
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit d993ada50c)
The old svga3d_reg.h file is split into separate header files and we
add new items for guest-backed surfaces.
Plus some minor code fixes because of renamed symbols.
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 2e0c90847f)
If the shader is too large, plug in a dummy shader. This patch also
reworks the existing dummy shader code.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
(cherry picked from commit 97fdace6d7)
Put common code in new svga_shader.c file. Considate separate vertex/
fragment shader ID generation.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
(cherry picked from commit 4686f610b1)
The sort priorites for GLX_SAMPLES and GLX_SAMPLE_BUFFERS are
not defined in GL_ARB_multisample, but they are defined in
the GLX 1.4 specification.
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 3616e862f2)
The default values for GLX_DRAWABLE_TYPE and GLX_RENDER_TYPE are
GLX_WINDOW_BIT and GLX_RGBA_BIT respectively, as specified in
the GLX 1.4 specification.
This fixes the glx-choosefbconfig-defaults piglit test.
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit f41c2f6c33)
Unfortunately there's only one RT_ARRAY_MODE setting for all
attachments, so clears were previously truncated to the minimum number
of layers any attachment had. Instead set the RT_ARRAY_MODE to 512 (the
max number of layers) before doing the clear. This fixes
gl-3.2-layered-rendering-clear-color-mismatched-layer-count.
Also fix clears of individual layered rt/zeta, in case it ever happens.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Cc: 10.1 <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 6152ba0894)
Flush the context when we unmap a buffer, otherwise VDPAU might
start rendering the next frame while we still reference that buffer.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: StrangeNoises (rachel@strangenoises.org)
(cherry picked from commit db54fca9b8)
Bugzilla (bug needs XBMC changes as well):
https://bugs.freedesktop.org/show_bug.cgi?id=73191
When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always
flushes the context in the winsys if the buffer being mapped is busy. Since
I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined
with DISCARD_RANGE and I think the context isn't flushed anywhere else,
so no commands are submitted to the GPU until the IB is full, which takes
a lot of frames.
Using DISCARD_RANGE is not the only way to trigger this bug. The other way
is to reallocate the vertex buffer before every upload.
BTW, I'm not sure if this is the right place for flushing, but it does fix
the bug.
v2 (chk): move the flush to the right place.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: StrangeNoises (rachel@strangenoises.org)
(cherry picked from commit 3f98053fc9)
brw_init_state() calls brw_upload_initial_gpu_state(). If hardware
contexts are enabled (brw->hw_ctx != NULL), this will upload some
initial invariant state for the GPU. Without hardware contexts, we
rely on this state being uploaded via atoms that subscribe to the
BRW_NEW_CONTEXT bit.
Commit 46d3c2bf4d accidentally moved
the call to brw_init_state() before creating a hardware context.
This meant brw_upload_initial_gpu_state would always early return.
Except on Gen6+, we stopped uploading the initial GPU state via
state atoms, so it never happened.
Fixes a regression since 46d3c2bf4d.
Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 3663bbe773)
From page 14 (page 20 of the PDF) of the GLSL 1.10 spec:
"In addition, all identifiers containing two consecutive underscores
(__) are reserved as possible future keywords."
The intention is that names containing __ are reserved for internal use
by the implementation, and names prefixed with GL_ are reserved for use
by Khronos. Names simply containing __ are dangerous to use, but should
be allowed.
Per the Khronos bug mentioned below, a future version of the GLSL
specification will clarify this.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de>
Cc: Tapani Pälli <lemody@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
Bugzilla: Khronos #11702
(cherry picked from commit 2c85fd5a96)
Section 3.3 (Preprocessor) of the GLSL 1.30 spec (and later) and the
GLSL ES spec (all versions) say:
"All macro names containing two consecutive underscores ( __ ) are
reserved for future use as predefined macro names. All macro names
prefixed with "GL_" ("GL" followed by a single underscore) are also
reserved."
The intention is that names containing __ are reserved for internal use
by the implementation, and names prefixed with GL_ are reserved for use
by Khronos. Since every extension adds a name prefixed with GL_ (i.e.,
the name of the extension), that should be an error. Names simply
containing __ are dangerous to use, but should be allowed. In similar
cases, the C++ preprocessor specification says, "no diagnostic is
required."
Per the Khronos bug mentioned below, a future version of the GLSL
specification will clarify this.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de>
Cc: Tapani Pälli <lemody@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
Bugzilla: Khronos #11702
(cherry picked from commit 0bd7892630)
GL_ARB_ES2_compatibility doesn't say anything about shader linking
when one of the shaders (vertex or fragment shader) is absent. So,
the extension shouldn't change the behavior specified in GLSL
specification.
Tested the behavior on proprietary linux drivers of NVIDIA and AMD.
Both of them allow linking a version 100 shader program in OpenGL
context, when one of the shaders is absent.
Makes following Khronos CTS tests to pass:
successfulcompilevert_linkprogram.test
successfulcompilefrag_linkprogram.test
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 03597cf802)
Fixes radeonsi emitting command streams to the kernel even when there
have been no draw calls before a flush, potentially powering up the GPU
needlessly.
Incidentally, this also cuts the runtime of piglit gpu.py in about half
on my Kaveri system, probably because an X11 client going away no longer
always results in a command stream being submitted to the kernel via
glamor.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65761
Cc: "10.1" mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit cf0172d46a)
If built without llvm, the following error occurs with mplayer:
Failed to open VDPAU backend .../libvdpau_r600.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE
[vo/vdpau] Error when calling vdp_device_create_x11: 1
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kusanagi Kouichi <slash@ac.auone-net.jp>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 61f6cddef7)
As documented, the _mesa_free_shader_program_data function:
"Frees all the data that hangs off a shader program object, but not
the object itself."
This means that this function may be called multiple times on the same object,
(and has been observed to). Meanwhile, the shProg->Label field was not being
set to NULL after its free(). This led to a second call to free() of the same
address on the second call to this function.
Fix this by setting this field to NULL after free(), (just as with all other
calls to free() in this function).
Reviewed-by: Brian Paul <brianp@vmware.com>
CC: mesa-stable@lists.freedesktop.org
(cherry picked from commit a92581acf2)
Commit f4ebcd133b ("dri/nouveau: NV17_3D class is not available for
NV1a chipset") fixed this partially by using the correct 3d class.
However there were a lot of checks left over comparing against the
chipset.
Reported-and-tested-by: John F. Godfrey <jfgodfrey@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: 9.2 10.0 10.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
(cherry picked from commit 0c8b165366)
Currently we create a OPENGL_COMPAT context regardless of
what was requested by the program. Correct that by retaining
the program's request and passing it into _mesa_initialize_context.
Based on a similar commit for radeon/r200 by Ian Romanick.
Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 76d9f6d972)
Consider a multithreaded program with two contexts A and B, and the
following scenario:
1. Context A calls initialize(), which allocates mem_ctx and starts
building built-ins.
2. Context B calls initialize(), which sees mem_ctx != NULL and assumes
everything is already set up. It returns.
3. Context B calls find(), which fails to find the built-in since it
hasn't been created yet.
4. Context A finally finishes initializing the built-ins.
This will break at step 3. Adding a lock ensures that subsequent
callers of initialize() will wait until initialization is actually
complete.
Similarly, if any thread calls release while another thread is still
initializing, or calling find(), the mem_ctx/shader would get free'd while
from under it, leading to corruption or use-after-free crashes.
Fixes sporadic failures in Piglit's glx-multithread-shader-compile.
Bugzilla: https://bugs.freedesktop.org/69200
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1 10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit b47d231526)
In commit eeed49f5f2, Mark accidentally
renamed MESA_FORMAT_S8_Z24 to MESA_FORMAT_Z24_UNORM_X8_UINT and
MESA_FORMAT_X8_Z24 to MESA_FORMAT_Z24_UNORM_S8_UINT, reversing their
sense. The commit message was correct, but what sed commands actually
got run didn't match that.
This patch swaps the two enum names, reversing them. This should undo
the damage, but might break things if people have manually fixed a few
instances in the meantime...
Mark's commit also failed to mention renames:
s/MESA_FORMAT_ARGB2101010_UINT\b/MESA_FORMAT_B10G10R10A2_UINT/g
s/MESA_FORMAT_ABGR2101010\b/MESA_FORMAT_R10G10B10A2_UNORM/g
but those seem okay.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit a487ef87fe)
Apparently some players are ill-prepared for us claiming that a decoder
exists only to have creating it fail, and express this poor preparation
with crashes (e.g. flash). Check that firmware is there to increase the
chances of there being a high correlation between reported capabilities
and ability to create a decoder.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: 10.0 10.1 <mesa-stable@lists.freedesktop.org>
Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 40dd777b33)
nvfx_fragprog_assign_generic only allows for up to 10/8 texcoords for
nv40/nv30. This fixes compilation of the varying-packing tests.
Furthermore it appears that the last 2 inputs on nv4x don't seem to
work in those tests, so just report 8 everywhere for now.
Tested on NV42, NV44. NV4B appears to have additional problems.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: 9.1 9.2 10.0 10.1 <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 356aff3a5c)
GLX_ARB_create_context allows making a GLX context current with None
drawable and readables, but this was never implemented correctly in GLX.
We would create a __DRIdrawable for the None GLX drawable and pass that
to the DRI driver and that would somehow work. Now it's somehow broken.
The way this should have worked is that we pass a NULL DRI drawable
to the DRI driver when the GLX user calls glXMakeContextCurrent()
with None for drawable and readables.
https://bugs.freedesktop.org/show_bug.cgi?id=74143
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
(cherry picked from commit f658150639)
The driver is supposed to ensure buffers before any drawing operation, but in
do_blit_drawpixels() and do_blit_copypixels() we inspect the buffer format
before calling intel_prepare_render(). That was covered up by the
unconditional call to intel_prepare_render() in intelMakeCurrent(), but we
now only do this on the initial intelMakeCurrent call for a context
(to get the size for the initial viewport values).
https://bugs.freedesktop.org/show_bug.cgi?id=74083
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Tested-by: Alexander Monakov <amonakov@gmail.com>
(cherry picked from commit 44338cd826)
Mesa fails to retain the precision qualifier when parsing:
#version 300 es
centroid in mediump vec2 v;
Consider how the parser's type_qualifier production is applied.
First, the precision_qualifier rule creates a new ast_type_qualifier:
<precision: mediump>
Then the storage_qualifier rule creates a second one:
<flags: in>
and calls merge_qualifier() to fold in any previous qualifications,
returning:
<flags: in, precision: mediump>
Finally, the auxiliary_storage_qualifier creates one for "centroid":
<flags: centroid>
it then does $$ = $1 and $$.flags |= $2.flags, resulting in:
<flags: centroid, in>
Since precision isn't stored in the flags bitfield, it is lost. We need
to instead call merge_qualifier to combine all the fields.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reported-by: Kevin Rogovin <kevin.rogovin@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 2062f40d81)
If st_GetTexImage() is to decompress the texture, avoid the fallback
path even if prefer_blit_based_texture_transfer = false. For drivers
that returned PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER = 0, we
were always taking the fallback path for texture decompression rather
than rendering a quad. The later is a lot faster.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit f47e596288)
In the tests they were the same so it didn't matter, but indications are
that this is the correct behaviour. Also take this opportunity to
(trivially) support using gl_Layer in fp.
Cc: 10.1 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
(cherry picked from commit 364bdd2419)
From the GLSL 4.40 spec, section 6.4 (Jumps):
The continue jump is used only in loops. It skips the remainder of
the body of the inner most loop of which it is inside. For while
and do-while loops, this jump is to the next evaluation of the
loop condition-expression from which the loop continues as
previously defined.
Previously, we incorrectly treated a "continue" statement as jumping
to the top of a do-while loop.
This patch fixes the problem by replicating the loop condition when
converting the "continue" statement to IR. (We already do a similar
thing in "for" loops, to ensure that "continue" causes the loop
expression to be executed).
Fixes piglit tests:
- glsl-fs-continue-inside-do-while.shader_test
- glsl-vs-continue-inside-do-while.shader_test
- glsl-fs-continue-in-switch-in-do-while.shader_test
- glsl-vs-continue-in-switch-in-do-while.shader_test
Cc: mesa-stable@lists.freedesktop.org
Acked-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit 7f5740899f)
In addition to making it public, we also need to change its first
argument from an ir_loop * to an exec_list *, so that it can be used
to insert the condition anywhere in the IR (rather than just in the
body of the loop).
This will be necessary in order to make continue statements work
properly in do-while loops.
Cc: mesa-stable@lists.freedesktop.org
Acked-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
(cherry picked from commit 56790856b3)
This is really not needed as blorp blit programs already sample
XRGB normally and get alpha channel set to 1.0 automatically by
the sampler engine. This is simply copied directly to the payload
of the render target write message and hence there is no need for
any additional blending support from the pixel processing pipeline.
The blending formula is anyway broken for color components, it
multiplies the color component with itself (blend factor is the
component itself).
Alpha blending in turn would not fix the alpha to one independent
of the source but simply used the source alpha as is instead
(1.0 * src_alpha + 0.0 * dst_alpha).
Quoting Eric:
"If we want to actually make the no-alpha-bits-present thing work,
we need to override the bits in the surface state or in the
generated code. In the normal draw path, it's done for sampling
by the swizzling code in brw_wm_surface_state.c, and the blending
overrides is just to fix up the alpha blending stage which
doesn't pay attention to that for the destination surface."
If one modifies piglit test gl-3.2-layered-rendering-blit to use
color component values other than zero or one, this change will
kick in on IVB. No regressions on IVB.
This is effectively revert of c0554141a9:
i965/blorp: Support overriding destination alpha to 1.0.
Currently, Blorp requires the source and destination formats to be
equal. However, we'd really like to be able to blit between XRGB and
ARGB formats; our BLT engine paths have supported this for a long time.
For ARGB -> XRGB, nothing needs to occur: the missing alpha is already
interpreted as 1.0. For XRGB -> ARGB, we need to smash the alpha
channel to 1.0 when writing the destination colors. This is fairly
straightforward with blending.
For now, this code is never used, as the source and destination formats
still must be equal. The next patch will relax that restriction.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
(cherry picked from commit 933be19cdf)
When we clipped a line weren't copying the provoking vertex
color to the second vertex. We also weren't checking for
first vs. last provoking vertex.
Fixes failures found with the new piglit line-flat-clip-color test.
Cc: "10.0, 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
(cherry picked from commit fc3fcd1e01)
All patches on master below, except max samplers
which was removed on master.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
commit 57c6bb18822ebf88a98b98714c846608ff3ba42b
Author: Dave Airlie <airlied@redhat.com>
Date: Thu Feb 6 00:48:57 2014 +0000
bump max samplers
commit 2e4bd244493bebd41edf725a2c3c4e793282a5bb
Author: Dave Airlie <airlied@redhat.com>
Date: Thu Jan 30 04:19:57 2014 +0000
r600g: add support for geom shaders to r600/r700 chipsets (v2)
This is my first attempt at enabling r600/r700 geometry shaders,
the basic tests pass on both my rv770 and my rv635,
It requires this kernel patch:
http://www.spinics.net/lists/dri-devel/msg52745.html
v2: address Alex comments.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 0ed4f769d77c4db2259befba5fc1707f1cb5cb98
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Jan 29 21:48:09 2014 +0000
r600g: enable GLSL 3.30 on evergreen GPUs
This throws the switch to enable GL 3.3 and GLSL 330.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit aeca8f21dd42b9ecd3932ef028fa8846036c1307
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Feb 4 10:48:42 2014 +1000
r600g: properly propogate clip dist write value
This moves the value from the GS shader to the copy shader so the registers
are setup correctly.
fixes tests/spec/glsl-1.50/execution/geometry/clip-distance-out-values.shader_test
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit e1bc410fe670bb17078a55876f1700a504127fef
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Feb 3 15:31:26 2014 +1000
r600g: calculate a better value for array_size (v2)
attempt to calculate a better value for array size to avoid breaking apps.
v2: use 0xfff like streamout, suggested by Grigori
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 6f2f117dec51eb51c1b09e86e829e176a98e3bfc
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Jan 31 03:35:51 2014 +0000
r600g: fix CAYMAN geometry shader support
cayman has a different end of program bit, so do that properly.
fixes hangs with geom shader tests on cayman.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 305ea22fd517f83406aba3e3930d710fd42a3049
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Jan 29 00:17:15 2014 +0000
r600g: fix up shader out misc stuff for copy shader
set the correct values so the misc out register is setup correctly
for the copy shader.
This also updates the state for the gs copy shader so the hw
gets programmed correctly.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 53630e14c8791a84798a03d74653bf46bd013fc7
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Jan 28 23:15:29 2014 +0000
r600g: port the layered surface rendering patch from radeonsi
This just makes r600 and evergreen do what the radeonsi codepaths do
for layered rendering. This makes the 2d amd_vertex_shader_layer test
pass on evergreen.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit aa4cd3b9bed1ea23468fba4aa5c428153e8cddc1
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Jan 28 13:04:00 2014 +1000
r600g: initial VS output layer support
This just adds support for emitting the proper value in the VS out misc.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 75a93f2e1e0f4d6015cdf63570ec4d3d12478b8d
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Jan 28 12:06:49 2014 +1000
r600g: setup const texture buffers for geom shaders
This just enables the workarounds we have for vertex/pixel shaders
for geom shaders as well.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 88697a860635aae54e56dce2d6a839a06dea0c5a
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Jan 24 17:14:26 2014 +1000
r600g: calculate correct cut value
This selects the cut value depending on the shader selected.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit dfb88bef3e13112a838773e700c35052774f8a63
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Jan 24 14:46:37 2014 +1000
r600g: fix dynamic_input_array_index.shader_test
This follows what fglrx does, it unpacks the input we are
going to indirect into a bunch of registers and indirects
inside them.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit a3c6373f8cf3aab750399654a4b77150ec30bce9
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Jan 24 13:39:36 2014 +1000
r600g: add support for indirect geom ring writes
We need to be able to write to the ring using a base register
for when we emit vertices in a loop, in theory the SB compiler
could collapse these indirect writes to direct writes if the
register value is constant and known, but that is outside my
pay grade.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit dbc6a13adf935b118eaa6b396593f50d7b7e16e6
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Dec 24 05:59:19 2013 +0000
r600g: write proper output prim type
Vadim's code derived it from the info.mode, but it needs
to be takes from the geometry shader output primitive.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit f7f51b0b775f652967e2b972cf7c183482a771be
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Dec 24 05:30:37 2013 +0000
r600g: enable instance cnt register with new enough kernel
The instance cnt register was missing for a few kernels,
with a new enough kernel we can output it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 9e6ce37f66372018ec5398f74c3b43ff5f5bf309
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Dec 23 01:30:03 2013 +0000
r600g: add primitive input support for gs
only enable prim id if gs uses it
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit fa932dfc7df3cf9ff63d08fb0e1db2119fc2ac93
Author: Dave Airlie <airlied@redhat.com>
Date: Thu Dec 19 05:17:00 2013 +0000
r600g: emit streamout from dma copy shader
This enables streamout with GS in the mix, from the
VS dma shader.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 205defb542ac185b7f46508fd51a4077a4702107
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Dec 18 15:55:07 2013 +1000
r600g/gs: fix cases where number of gs inputs != number of gs outputs
this fixes a bunch of the geom shader built-in tests
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit d9e7ab40bc45644194c86f842599c76d0675243c
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Jan 28 10:21:03 2014 +1000
r600g: increase array base for exported parameters
Trivial fix to Vadim's code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 82d67fbd3b96b6b2cc0124a19b6f31b7912ec152
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Jan 24 16:41:32 2014 +1000
r600g: initialise the geom shader loop registers.
As we do for vertex and pixel shaders.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 78be55d98d290d708bd1b3df3ef6cd5fa89865c7
Author: Dave Airlie <airlied@redhat.com>
Date: Sat Nov 30 06:26:13 2013 +0000
r600g: emit NOPs at end of shaders in more cases
If the shader has no CF clauses at all emit an nop
If the last instruction is an ENDLOOP add a NOP for the LOOP to go to
if the last instruction is CALL_FS add a NOP
These fix a bunch of hangs in the geometry shader tests.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 634b2498dc73efa3cca5a6fc3ed35c5bea6bb2e9
Author: Dave Airlie <airlied@redhat.com>
Date: Thu Nov 28 23:38:35 2013 +0000
r600g: don't enable SB for geom shaders
SB needs fixes for three GS instructions it seems to raise
them outside loops etc despite my best efforts.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 5b61dd0e917e54625ac227b8b1c2c82955f51ab1
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Dec 24 04:56:25 2013 +0000
r600g/sb: add MEM_RING support
Although we don't use SB on geom shaders, the VS copy shader will use it
so we might as well implement MEM_RING support in sb.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 0247375aec4681c154ae4d14b8cd637e7a9e0e3e
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Jan 29 04:08:43 2014 +0000
r600g: don't fail if we can't map VS->GS ring entries
This can happen in normal operation, so don't report an error on it,
just continue.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 2c986600fac6cb5692e9e377cb04f9f50389172c
Author: Vadim Girlin <vadimgirlin@gmail.com>
Date: Fri Aug 2 06:38:23 2013 +0400
r600g: initial support for geometry shaders on evergreen (v2)
This is Vadim's initial work with a few regression fixes squashed in.
v2: (airlied)
fix regression in glsl-max-varyings - need to use vs and ps_dirty
fix regression in shader exports from rebasing.
whitespace fixing.
v2.1: squash fix assert
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit ce23c43e2b611f30964afe4d1c02c4d0361ba430
Author: Vadim Girlin <vadimgirlin@gmail.com>
Date: Fri Aug 2 06:32:32 2013 +0400
r600g: add hw register definitions for GS block setup
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit b0ec79c28d6373930ca0dc19168dd504204456b5
Author: Vadim Girlin <vadimgirlin@gmail.com>
Date: Wed Jul 31 23:09:39 2013 +0400
r600g: defer shader variant selection and depending state updates
[airlied: fix dropped streamout line - fix for master]
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit e41cbfb4d15d519f9301699f39d7dd0153f2edf4
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Jan 13 10:19:00 2014 +1000
r600g/bc: add support for indexed memory writes.
It looks like we need these for geom shaders in the future.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
commit 46efb1648e883b2cb231cca38c1540e7e9ec1ecc
Author: Vadim Girlin <vadimgirlin@gmail.com>
Date: Wed Jul 31 20:02:22 2013 +0400
r600g: move barrier and end_of_program bits from output to cf struct (v2)
v2: fix regression on r600 NOP instructions.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
commit 42802d5d8d145f07cf3fca1bb6e8ab0cd1fd5c85
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Jan 29 01:33:14 2014 +0000
r600g: split streamout emit code into a separate function
For geometry shaders we need to call this code from a second place.
Just move it out for now to keep future patches cleaner.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Silences many GCC warnings of the form:
drivers/common/meta.c: In function 'cleanup_temp_texture':
drivers/common/meta.c:1208:41: warning: unused parameter 'ctx' [-Wunused-parameter]
drivers/common/meta.c: In function 'setup_ff_blit_framebuffer':
drivers/common/meta.c:1453:46: warning: unused parameter 'ctx' [-Wunused-parameter]
drivers/common/meta.c: In function 'meta_glsl_blit_cleanup':
drivers/common/meta.c:1998:43: warning: unused parameter 'ctx' [-Wunused-parameter]
drivers/common/meta.c: In function 'meta_glsl_clear_cleanup':
drivers/common/meta.c:2287:44: warning: unused parameter 'ctx' [-Wunused-parameter]
drivers/common/meta.c: In function 'setup_ff_generate_mipmap':
drivers/common/meta.c:3365:45: warning: unused parameter 'ctx' [-Wunused-parameter]
drivers/common/meta.c: In function 'meta_glsl_generate_mipmap_cleanup':
drivers/common/meta.c:3556:54: warning: unused parameter 'ctx' [-Wunused-parameter]
There are a couple other similar warnings, but they are less trivial. I
want to investigate these further before axing them.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Array textures can't be used with fixed-function, so don't. Instead,
just drop the decompress request on the floor. This is no worse than
what was done previously because generating the GL error (in
_mesa_set_enable) broke everything anyway.
A later patch will get GL_TEXTURE_2D_ARRAY targets working.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is no need to use pixel coordinates, and using NDC directly will
simplify the GLSL paths.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
For these objects, meta was already using the non-Apple function to
delete the objects. Everywhere else in the file uses
_mesa_GenVertexArrays and _mesa_BindVertexArrays.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org>
The hardware decompression path isn't even close to being able to handle
this. This converts the crash (assertion failure) in
"EXT_texture_compression_s3tc/getteximage-targets S3TC CUBE_ARRAY" to a
plain old failure.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org>
_mesa_meta_DrawPixels creates a VAO and (potentially) two fragment
programs, but none of them are ever released. Leaking piles of memory
is generally frowned upon.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org>
decompress_texture_image creates an FBO, an RBO, a VBO, a VAO, and a
sampler object, but none of them are ever released. Later patches will
add program objects, exacerbating the problem. Leaking piles of memory
is generally frowned upon.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org>
TEXTURE_BUFFER_INDEX has to be specially called out because it is not
allowed in any of the glTexParameter or glGetTexParameter functions.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The next patch will use this function in another file.
v2: Rename _mesa_target_enum_to_index to _mesa_tex_target_to_index.
Suggested by Brian.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
glTexSubImage(), glCopyTexSubImage() and glCompressedTexSubImage()
only change the texel data, not other state like texture size or format.
If a driver really needs do something special it can hook into the
corresponding driver functions or Map/UnmapTextureImage().
This should avoid some needless state validation effort.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The _mesa_get_current_tex_object() function is now used everywhere that
_mesa_select_tex_object() was formerly used.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
As far as I know, this should be safe. If not, we have to decide whether
to have variable lookup of the functions, or just drop support for .so.0
(which is a year and a half old it looks like)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74127
Reviewed-by: Matt Turner <mattst88@gmail.com>
Updates to non-banked registers, CP_LOAD_STATE, etc, need a WFI if there
is potentially pending rendering. Track this better, and add fd_wfi()
calls everywhere that might potentially need CP_WAIT_FOR_IDLE.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Gallium can leave const buffers bound above what is used by the current
shader. Which can have a couple bad effects:
1) write beyond const space assigned, which can trigger HLSQ lockup
2) double emit of immed consts, first with bound const buffer vals
followed by with actual immed vals. This seems to be a sort of
undefined condition.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Currently lowers the following instructions:
DST, XPD, SCS, LRP, FRC, POW, LIT, EXP, LOG, DP4,
DP3, DPH, DP2
translating these into equivalent simpler TGSI instructions.
This probably should be moved to util so other drivers can use
it, but just adding under freedreno for now so that I can clear
out a lot of the lowering code in a3xx compiler before beginning
to add new compiler.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The ctx should hold ref to dev to avoid problems if screen is destroyed
before ctx. Doesn't really fix the egl/glx issues, but at least it
prevents things from getting much worse.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
In the final revision of my gen8_generator patch, I updated the MATH
instruction's assertion from (dst.hstride == 1) to check that source and
destination hstride matched. Unfortunately, I didn't test this enough,
and many Piglit tests fail this test.
The documentation indicates that "scalar source is also supported",
which we believe means <0,1,0> access mode (hstride == 0). If hstride
is non-zero, then it must match the destination register.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This puts the PCI IDs in place so it's easy to enable support. However,
it doesn't actually enable support since it's very preliminary still,
and a few crucial pieces (such as BLORP) are still missing.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
Eric believes this to be wrong and unnecessary, as the command is
supposed to emit an implicit rectangle primitive. However, empirically
the pixel pipeline is completely unreliable without it. So for now, it
stays until someone comes up with a better solution.
We'll need to do better than this when we implement multisampling, HiZ,
or fast clears...but for now, this will do.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
This is quite similar to the Gen7 code. The main changes:
- 48-bit relocations
- Thread count is specified as U/2-1 instead of U-1.
- An extra DWord (DW9) with clip planes, URB entry output length/offsets
- We need to program the "Expected Vertex Count" (VerticesIn)
v2: Set the number of binding table entries so they can be prefetched
(requested by Eric Anholt).
v3: Add a WARN_ONCE for a missing workaround.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
On previous platforms, 3DSTATE_MULTISAMPLE contained the number of
samples, pixel location, and the positions of each sample within a pixel
for each multisampling mode (4x and 8x). It was also a non-pipelined
command, presumably since changing the sample positions is fairly
drastic.
Broadwell improves upon this by splitting the sample positions out into
a separate non-pipelined state packet, 3DSTATE_SAMPLE_PATTERN. With
that removed, 3DSTATE_MULTISAMPLE becomes a pipelined state packet.
Broadwell also supports 2x and 16x multisampling, in addition to the 4x
and 8x supported by Gen7. This patch, however, does not implement 2x
and 16x.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The amount of cut and paste from Gen7 is rather ugly, and should
probably be cleaned up in the future. Even the Gen7 code is in need of
some tidying though; many of the function parameters aren't used on
platforms that use level/layer rather than tile offsets. Tidying both
can be left to a future patch series. This at least gets things going.
v2: Rebase on Paul's rename of NumLayers -> MaxNumLayers.
v3: Shift QPitch by 2 when storing it in the packet. Bits 14:0 store
bits 16:2 of the actual value. Fixes tests.
v4: Add missing stencil buffer QPitch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
v2: Allow logic ops on all surface types. The UNORM restriction was
lifted with Haswell and I simply hadn't noticed. Also, add missing
BRW_NEW_STATE_BASE_ADDRESS dirty bit. Both caught by Eric Anholt.
v3: Fix swapped per-RT DWord pairs. Eliminates bizarre hacks.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
It has additional fields to support clipping to the viewport even if
guardband clipping is enabled.
v2: Update for viewport array changes.
v3: No, seriously, update for viewport array changes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v1]
v2: Add missing SCS setting in gen8_emit_buffer_surface_state (caught by
Eric Anholt).
v3: Use stored QPitch rather than recomputing it.
v4: Shift QPitch by 2 when setting it in the packet; bits 14:0 store
bits 16:2 of the actual value (fixes myriads of cube and array
texturing tests). Also, only enable cube face bits for cubemaps
(matches Chris Forbes' commit on master). Port to use offset64.
v5: s/gl_format/mesa_format/g
v6: Fix DW5 of renderbuffer state, which neglected to subtract
irb->mt->first_level. Use vertical_alignment() rather than
hardcoding 4. Use ffs for multisample counts rather than a
large switch statement (all caught/suggested by Eric).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Unlike on Gen7, we can directly set the offset via the state packet.
We also -have- to: the kernel SOL reset code won't work anymore.
v2: Fix copy and paste mistake in buffer stride setup; drop stale
comment (caught by Eric Anholt). Add a perf_debug for missing
MOCS setup.
v3: Rebase on Paul Berry's changes to CurrentVertexProgram.
v4: Fix SO Write Offset handling. We need to set bits 20 and 21 so the
hardware both loads and saves the offset. There's also a
restriction that 3DSTATE_SO_BUFFER can only be programmed once per
buffer between primitives, so the "reset to zero" code needed
reworking. Fixes most of the transform feedback Piglit tests.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v2]
v2: Also disable 3DSTATE_WM_CHROMAKEY for safety.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v1]
Broadwell's winding order, polygon fill, and viewport Z test fields have
moved to DWord 1 of 3DSTATE_RASTER.
v2: Add a perf_debug for a future optimization and improve commit
message (both suggested by Eric Anholt).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
v2: Emit a dummy 3DSTATE_VF_SGVS packet when not needed.
v3: Add WARN_ONCE and perf_debugs requested by Eric Anholt.
v4: Program 3DSTATE_SGVS even in the no-elements case so gl_VertexID
continues working. Fix 3DSTATE_VF_INSTANCING to not use an
element index to access the buffers array. Some ARB_draw_indirect
prep work.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
v2: Fix missing "change" bit on instruction state base address
(caught by Haihao Xiang).
v3: Add a perf_debug for missing MOCS setup, requested by Eric.
v4: Fix buffer sizes. The value, specified at bit 12 and up, is
actually measured in 4k pages. We need to round up to the
next multiple of 4k.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v3]
Reviewed-by: Matt Turner <mattst88@gmail.com> [v4]
v2: Fix setting of GEN8_PSX_ATTRIBUTE_ENABLE after rebases.
v3: Add missing binding table entry counts. Don't worry about alpha
testing or alpha to coverage when setting the "Kill Pixel" bit;
those are specified in 3DSTATE_PS_BLEND (caught by Eric Anholt).
Drop unused _NEW_BUFFERS. Tidy comments.
v4: Rebase on Paul Berry's changes to CurrentFragmentProgram.
v5: Re-enable line stippling. It doesn't crash or anything.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v3]
v2: Remove incorrect MOCS shifts; rename urb_entry_write_offset to
urb_entry_output_offset to closer match the documentation.
v3: Only emit a non-zero constant buffer read length when active.
v4: Add missing binding table counts (caught by Eric).
v5: Rebase on Paul Berry's changes to CurrentVertexProgram.
v6: Drop bogus SBE read length/offset field code. We were programming
the wrong values, and our 3DSTATE_SBE code overrides any value we
put here anyway with the correct one.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v4]
v2: Only set GEN8_PS_BLEND_HAS_WRITEABLE_RT if color buffer writes are
enabled (caught by Eric Anholt).
v3: Set non-blending flags (writeable RT, alpha test, alpha to coverage)
for integer formats too. +14 Piglits.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v2]
v2: Use stencil->_WriteEnabled instead of setting
GEN8_WM_DS_STENCIL_BUFFER_WRITE_ENABLE twice (suggested by Eric).
v3: Mask stencil->WriteMask and stencil->ValueMask with 0xff. The field
is only 8-bits, so we'd trip the new SET_FIELD assertion when core
Mesa gave us a value like 0xFFFFFFFF. The Gen7 code uses structure
field widths to implicitly do this truncation. Fixes Piglit tests.
v4: Use uint32_t for dw1/dw2, not uint8_t. Worst. Typo. Ever.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v2]
The attribute override portion of 3DSTATE_SBE was split out into
3DSTATE_SBE_SWIZ; various bits of 3DSTATE_SF were split out into
3DSTATE_RASTER.
v2: Set Force URB Read Offset bit. Eventually the URB read offset
should be set in 3DSTATE_VS, but that will require some refactoring.
v3: Rebase on viewport array changes.
v4: Improve comments about URB read length/offset overrides.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
I haven't investigated whether these are necessary on Broadwell or not,
but for paranoia's sake, we may as well continue doing them for now.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
It's going to diverge significantly. Starting out with a copy allows
future patches to change atoms one by one.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The code re-enabling denorms for small float formats did not recognize
this format due to format handling hacks (mainly, the lp_type doesn't have
the floating bit set).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The -p option we now use when calling bison means that this variable will be
named glcpp_parser_debug not yydebug. This was not caught when the -p option
was added because this variable isn't used in the code as committed. (I prefer
the declaration to remain since it allows a developer to easily find this
variable name to enable debugging.)
This is the innocent-looking but killer test case to verify the bug fixed in
the preceding commit.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In commit 6005e9cb28 a new start state of NEWLINE_CATCHUP was added to the
lexer. This start state is used whenever the lexer is emitting a NEWLINE token
to emit additional NEWLINE tokens for any newline characters that were skipped
by an immediately preceding multi-line comment.
However, that commit erroneously entered the NEWLINE_CATCHUP state for
single-line comments. This is not desired since in the case of a single-line
comment, the lexer is not emitting any NEWLINE token. The result is that the
lexer will remain in the NEWLINE_CATCHUP state and proceed to fail to emit a
NEWLINE token for the subsequent newline character, (since the case to match \n expects only the INITIAL start state).
The fix is quite simple, remove the "BEGIN NEWLINE_CATCHUP" code from the
single-line comment case, (preserving it only in exactly the cases where the
lexer is actually emitting a NEWLINE token).
Many thanks to Petri Latvala for reporting this bug and for providing the
minimal test case to exercise it. The bug showed up only with a multi-line
comment which was followed immediately by a single-line comment (without any
intervening newline), such as:
/*
*/ // Kablam!
Since 6005e9cb28, and before this commit, that very innocent-looking
combination of comments would yield a parse failure in the compiler.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72686
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This automatically adjusts the number of buffers that we want based on
what swapping mode the X server is using and the current swap interval:
swap mode interval buffers
copy > 0 1
copy 0 2
flip > 0 2
flip 0 3
Note that flip with swap interval 0 is currently limited to twice the
underlying refresh rate because of how the kernel manages flipping. Moving
from 3 to 4 buffers would help, but that seems ridiculous.
v2: Just update num_back at the point that the values that change num_back
change. This means we'll have the updated value at the point that the
freeing of old going-to-be-unused backbuffers happens, which might not
have been the case before (change by anholt, acked by keithp).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB8888 and then adds translations *back* to
__IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.
I'll refrain from comments on whether I think having two separate sets of
format defines in dri_interface.h is a good idea or not...
Fixes piglit glx-tfp and glx-visuals-depth
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
XCB doesn't flush the output buffer automatically, so we have to call
xcb_flush ourselves before waiting.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that we're tracking SBC values correctly, and the X server has the
ability to send the GLX swap events from a PresentPixmap request, enable
this extension.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Eric figured out that glXWaitForSbcOML wanted to block until the requested
SBC had been completed, which means to wait until the
PresentCompleteNotify event for that SBC had been received.
This replaces the simple sleep(1) loop (which was bogus) with a loop that
just checks to see if we've seen the specified SBC value come back in a
PresentCompleteNotify event yet.
The change is a bit larger than that as I've broken out a piece of common
code to wait for and process a single Present event for the target
drawable.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number
that we use to pass the SBC value from request to event.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This consolidates how we link the libraries into the build directory.
It works for lib_LTLIBRARIES but not custom shared libraries like DRI
drivers or gallium state trackers which needs special casing (cf dri
mega drivers, for example)
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Spamming the pci id is not beneficial. Make sure it's printed
only when needed.
v2: Change severity to _LOADER_DEBUG, rather than removing
the message.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The former symbol is never defined within mesa. Based on the code
it seems that the original intent was to use NDEBUG.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Makefiles need hard tabs, let's not make that harder than it needs to be.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Every driver supports it. All current and future Gallium drivers always
support it, and all existing classic drivers support it.
v2: Making GL_ARB_map_buffer_alignment a desktop OpenGL extension only.
v3: Squash two commits together.
v4 (idr): MIN_MAP_BUFFER_ALIGNMENT queries don't have any dependencies.
In previous versions of the patch it depended on EXTRA_API_GL which
would prevent the query from working in core profile contexts.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
This driver does not support GL_ARB_map_buffer_range, so no special
treatment is needed for unaligned offsets in the mapping.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These drivers do not support GL_ARB_map_buffer_range, so no special
treatment is needed for unaligned offsets in the mapping.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Ian manually ran the map_buffer_range* tests and the
arb_map_buffer_alignment-* tests, but he did not do a full piglit run.
v2 (idr): Use 64 instead of 4096
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Move parameter loads out of loops, and use the instruction offset
instead of a VGPR for the vertex attribute offset when writing to the
ESGS ring buffer.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Just always bind the current states before drawing.
Besides the simplification, as a bonus this makes sure the VS hardware
shader stage always uses the GS copy shader when a geometry shader is
active, fixing a number of GS related piglit tests.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
It needs to increment at shader runtime, not at shader compile time, as
the geometry shader can emit vertices in loops. LLVM automagically
converts the ID back to an immediate value if its value can be
determined at compile time.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Transforms, for example,
mul vgrf3, vgrf2, vgrf1
mov.sat vgrf4, vgrf3
into
mul.sat vgrf3, vgrf2, vgrf1
mov vgrf4, vgrf3
which gives register_coalescing an opportunity to remove the MOV
instruction.
total instructions in shared programs: 1515039 -> 1504634 (-0.69%)
instructions in affected programs: 798586 -> 788181 (-1.30%)
GAINED: 0
LOST: 4
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OpenGL 3.3 spec expects GL_INVALID_OPERATION:
"For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT AND BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID OPERATION."
But OpenGL 4.0 spec changed the error code to GL_INVALID_ENUM:
"For both the default framebuffer and framebuffer objects, the
constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
valid in the bufs array passed to DrawBuffers, and will result
in the error INVALID_ENUM."
This patch changes the behaviour to match OpenGL 4.0 spec
Fixes Khronos OpenGL CTS draw_buffers_api.test.
V2: Update the comment in code.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I sometimes build without EGL just for speed purposes, however
it no longer finds my drivers when I do due to the HAVE_LIBUDEV
defines being wrong.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes the tests for the depth parameter for TexImage3D calls when the
target type is GL_TEXTURE_2D_ARRAY or GL_TEXTURE_CUBE_MAP_ARRAY
so that a depth value of 0 is accepted. Previously, the check
incorrectly required the depth argument to be atleast 1.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The code depending on the definitions is already wrapped
in the same conditional so go ahead and wrap the include.
Otherwise we'll brake compilation on platforms that are
missing the header. Add assert.h in there as well, as it
is introduced and used in the same fashon.
Cc: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74122
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
We have code generation paths that carry out swizzles of AoS vectors via
bitwise shifts, as these tend to generate more efficient code than
straightforward byte shuffles. But when the input is a constant the
additional bitwise arithmetic operations somehow don't really get
constant propagated properly, evenutally causing assertion failure in
InstCombine pass.
Therefore avoid the bug by using the trivial shuffles for constant
inputs.
Although the sample LLVM IR can cause a crash with any LLVM version,
this was only seen in practice with LLVM 3.2.
Reviewed-by: Matthew McClure <mcclurem@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The check was in the wrong place, such that if a shader incorrectly put
a preprocessor token before the #version declaration, the version would
be resolved twice, leading to a segmentation fault when attempting to
redefine the __VERSION__ macro.
#extension GL_ARB_sample_shading: require
#version 130
void main() {}
Also, rename glcpp_parser_resolve_version to
glcpp_parser_resolve_implicit_version to avoid confusion.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
radeonsi now reports PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE = true if UVD support
isn't available. It's what all the other drivers do.
Also, some #include directives were missing in radeon_uvd.h.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Implemented by the common code. You can now visualize the statistics
with the HUD, see GALLIUM_HUD=help for all available queries. For example:
GALLIUM_HUD=clipper-primitives-generated
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Replace Type A _INT formats names with _SINT to match naming spec,
and update type C formats as follows:
s/MESA_FORMAT_R_INT8\b/MESA_FORMAT_R_SINT8/g
s/MESA_FORMAT_R_INT16\b/MESA_FORMAT_R_SINT16/g
s/MESA_FORMAT_R_INT32\b/MESA_FORMAT_R_SINT32/g
s/MESA_FORMAT_RG_INT8\b/MESA_FORMAT_RG_SINT8/g
s/MESA_FORMAT_RG_INT16\b/MESA_FORMAT_RG_SINT16/g
s/MESA_FORMAT_RG_INT32\b/MESA_FORMAT_RG_SINT32/g
s/MESA_FORMAT_RGB_INT8\b/MESA_FORMAT_RGB_SINT8/g
s/MESA_FORMAT_RGB_INT16\b/MESA_FORMAT_RGB_SINT16/g
s/MESA_FORMAT_RGB_INT32\b/MESA_FORMAT_RGB_SINT32/g
s/MESA_FORMAT_RGBA_INT8\b/MESA_FORMAT_RGBA_SINT8/g
s/MESA_FORMAT_RGBA_INT16\b/MESA_FORMAT_RGBA_SINT16/g
s/MESA_FORMAT_RGBA_INT32\b/MESA_FORMAT_RGBA_SINT32/g
s/\bMESA_FORMAT_RED_RGTC1\b/MESA_FORMAT_R_RGTC1_UNORM/g
s/\bMESA_FORMAT_SIGNED_RED_RGTC1\b/MESA_FORMAT_R_RGTC1_SNORM/g
s/\bMESA_FORMAT_RG_RGTC2\b/MESA_FORMAT_RG_RGTC2_UNORM/g
s/\bMESA_FORMAT_SIGNED_RG_RGTC2\b/MESA_FORMAT_RG_RGTC2_SNORM/g
s/\bMESA_FORMAT_L_LATC1\b/MESA_FORMAT_L_LATC1_UNORM/g
s/\bMESA_FORMAT_SIGNED_L_LATC1\b/MESA_FORMAT_L_LATC1_SNORM/g
s/\bMESA_FORMAT_LA_LATC2\b/MESA_FORMAT_LA_LATC2_UNORM/g
s/\bMESA_FORMAT_SIGNED_LA_LATC2\b/MESA_FORMAT_LA_LATC2_SNORM/g
Update comments. Replace format names containing SIGNED with
SNORM appended w/decoration per the format name spec:
s/MESA_FORMAT_SIGNED_R8\b/MESA_FORMAT_R_SNORM8/g
s/MESA_FORMAT_SIGNED_RG88_REV\b/MESA_FORMAT_R8G8_SNORM/g
s/MESA_FORMAT_SIGNED_RGBX8888\b/MESA_FORMAT_X8B8G8R8_SNORM/g
s/MESA_FORMAT_SIGNED_RGBA8888\b/MESA_FORMAT_A8B8G8R8_SNORM/g
s/MESA_FORMAT_SIGNED_RGBA8888_REV\b/MESA_FORMAT_R8G8B8A8_SNORM/g
s/MESA_FORMAT_SIGNED_R16\b/MESA_FORMAT_R_SNORM16/g
s/MESA_FORMAT_SIGNED_GR1616\b/MESA_FORMAT_R16G16_SNORM/g
s/MESA_FORMAT_SIGNED_RGB_16\b/MESA_FORMAT_RGB_SNORM16/g
s/MESA_FORMAT_SIGNED_RGBA_16\b/MESA_FORMAT_RGBA_SNORM16/g
s/MESA_FORMAT_SIGNED_A8\b/MESA_FORMAT_A_SNORM8/g
s/MESA_FORMAT_SIGNED_I8\b/MESA_FORMAT_I_SNORM8/g
s/MESA_FORMAT_SIGNED_L8\b/MESA_FORMAT_L_SNORM8/g
s/MESA_FORMAT_SIGNED_A16\b/MESA_FORMAT_A_SNORM16/g
s/MESA_FORMAT_SIGNED_I16\b/MESA_FORMAT_I_SNORM16/g
s/MESA_FORMAT_SIGNED_L16\b/MESA_FORMAT_L_SNORM16/g
s/MESA_FORMAT_SIGNED_AL88\b/MESA_FORMAT_L8A8_SNORM/g
s/MESA_FORMAT_SIGNED_RG88\b/MESA_FORMAT_G8R8_SNORM/g
s/MESA_FORMAT_SIGNED_RG1616\b/MESA_FORMAT_G16R16_SNORM/g
Change all 4 color component unsigned byte formats to meet spec for P
Type formats:
s/MESA_FORMAT_RGBA8888\b/MESA_FORMAT_A8B8G8R8_UNORM/g
s/MESA_FORMAT_RGBA8888_REV\b/MESA_FORMAT_R8G8B8A8_UNORM/g
s/MESA_FORMAT_ARGB8888\b/MESA_FORMAT_B8G8R8A8_UNORM/g
s/MESA_FORMAT_ARGB8888_REV\b/MESA_FORMAT_A8R8G8B8_UNORM/g
s/MESA_FORMAT_RGBX8888\b/MESA_FORMAT_X8B8G8R8_UNORM/g
s/MESA_FORMAT_RGBX8888_REV\b/MESA_FORMAT_R8G8B8X8_UNORM/g
s/MESA_FORMAT_XRGB8888\b/MESA_FORMAT_B8G8R8X8_UNORM/g
s/MESA_FORMAT_XRGB8888_REV\b/MESA_FORMAT_X8R8G8B8_UNORM/g
v2: Note that Fredrik Höglund is working on GL_ARB_multi_bind, not
Maxence Le Doré. Suggested by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
The define was only available if
gl_extensions::AMD_shader_trinary_minmax was set, but no driver set it.
Since the extension is advertised by default, remove that field too.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Maxence Le Doré <maxence.ledore@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Every driver supports it. All current and future Gallium drivers always
support it, and all existing classic drivers support it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The dd_function_table::BlitFramebuffer is already initialized to
_mesa_meta_BlitFramebuffer, so it should just work.
Tested on a Radeon 7500 (OpenGL renderer string: Mesa DRI R100 (RV200
5157) TCL DRI2). I couldn't do a full piglit run because it would tank
the system with or without this patch. I just ran all the blit tests
(-t blit to piglit-run.py). Only fbo-sys-sub-blit failed. All of the
other tests that weren't skipped (i.e., all the multisample and sRGB
tests skip) passed.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The dd_function_table::BlitFramebuffer is already initialized to
_mesa_meta_BlitFramebuffer, so it should just work.
Tested on a FireGL 8800 (OpenGL renderer string: Mesa DRI R200 (R200
5148) TCL DRI).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes the glTexStorage3D failure in
ext_packed_depth_stencil-depth-stencil-texture and
oes_packed_depth_stencil-depth-stencil-texture_gles2.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We need almost identical code in the glTexStorage path.
v2: Fix typo in a comment noticed by Topi.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All versions of the OpenGL spec are quite clear that
GL_INVALID_OPERATION should be generated. I added a quotation from the
3.3 core profile spec.
Fixes the glTexImage3D subcases of
ext_packed_depth_stencil-depth-stencil-texture and
oes_packed_depth_stencil-depth-stencil-texture_gles2. The same subtests
of oes_packed_depth_stencil-depth-stencil-texture_gles1 fail, but they
fail with a different wrong error code.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cover both loader and glx/dri_glx
Drop \n from the default loader logger
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Since the loader changes, there has been a compiler warning that the
prototype didn't match. It turns out that if a loader error message was
ever thrown, you'd segfault because of trying to use the warning level as
a format string.
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
This allows Mesa to choose to rename driver .sos (or split drivers),
without needing a flag day with the corresponding 2D driver.
v2: Undo the loader-only-for-dri3 change.
Reviewed-by: Keith Packard <keithp@keithp.com> [v1]
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> [v1]
I want to stop trusting the server for the driver name, and instead decide
on our own based on the fd, so I needed this code motion.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Steam links against libudev.so.0, while we're linking against
libudev.so.1. The result is that the symbol names (which are the same in
the two libraries) end up conflicting, and some of the usage of .so.1
calls the .so.0 bits, which have different internal structures, and
segfaults happen.
By using a dlopen() with RTLD_LOCAL, we can explicitly look for the
symbols we want, while they get the symbols they want.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Tested-by: Alexandre Demers <alexandre.f.demers@gmail.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Some of the hardware support is missing. The NVIDIA-provided driver,
which claims seamless cube map support fails the relevant tests as well.
As this is the last extension before we can have OpenGL 3.2, doing this
allows us to expose geometry shaders without doing the additional
work involved in supporting ARB_geometry_shader4.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Creates two areas in the AUX constbuf:
- Sample offsets for MS textures
- Per-texture MS settings
When executing a texelFetch with a MS sampler, looks up that texture's
settings and adjusts the parameters given to the texfetch instruction.
With this change, all the ARB_texture_multisample piglits pass, so turn
on PIPE_CAP_TEXTURE_MULTISAMPLE.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Each code BO is a heap that allocates at the end first, and so GPs are
allocated at the very end of the allocated space. When executing, we see
PAGE_NOT_PRESENT errors for the next page. Just over-allocate to make
sure that there's something there.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Make sure that we never try to use a 0-sized map. This can happen when
using a gp, so add a dummy mapping when computing vp_gp_mapping in that
case.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Marks gl_Layer as only having one component, and makes sure to keep
track of where it is and emit it in the output map, since it is not an
input to the FP.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Note that the primitive id is stored in a[0x18], while usually the
geometry instructions are of the form a[$a1 + 0x4] which gets mapped to
p[] space. We need to avoid the change from a[] to p[] here, so it's
keyed on whether the access is indirect or not.
Note that there's also a use-case for accessing e.g. a[$r1], however
that's not supported for now. (Could be added by checking the register
file of the indirect parameter.)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Layer output probably doesn't work yet, but other than that everything seems
to be working.
Signed-off-by: Bryan Cain <bryancain3@gmail.com>
[calim: fix up minor bugs, code formatting]
Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Instead of emitting an SHL 4 io an address register on the TGSI ARL and UARL
instructions, emit the shift when the loaded address is actually used. This
is necessary because input vertex and attribute indices in geometry shaders on
nv50 need to be shifted left by 2 instead of 4.
Signed-off-by: Bryan Cain <bryancain3@gmail.com>
[calim: various updates to the indirect address logic]
Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
[imirkin: remove OP_MAD change that calim made, add OP_RESTART handling
same as OP_EMIT for code flow analysis]
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers
as specified by glDrawBuffers).
This implementation is highly based on a larger commit by
Christoph Bumiller <e0425955@student.tuwien.ac.at> in his gallium-nine
branch.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
It doesn't make sense to do an OP_NEG from U32 to U32. This was
manifested on nv50 in glsl-fs-atan-3 which was generating a
UMAD TEMP[0].x, TEMP[0].xxxx, -TEMP[5].xxxx, TEMP[0].xxxx
instruction. (For some reason, nvc0 causes a different shader to be
generated.) This led to a
cvt neg u32 $r1 u32 $r1
Which did not yield the desired result. This changes the final output to
cvt neg s32 $r1 u32 $r1
which produces the desired output and the piglit tests passes. My
assumption is that this is also what we want on nvc0, but could not test
as there was no suitable shader that generated the problem instruction.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
When the min_index is very large (or very negative), the multipliation
can overflow 32 bits and result in an incorrect map pointer
modification.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This was discovered as a result of the draw-elements-base-vertex-neg
piglit test, which passes very negative offsets in, followed up by large
indices. The nouveau code correctly adjusts the pointer, but the
translate code needs to do the proper inverse correction. Similarly fix
up the SSE code to do a 64-bit multiply to compute the proper offset.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Broadwell requires software to specify QPitch in a bunch of packets,
so we decided to store it in the miptree. However, when I did that
refactoring, I missed a subtlety: the hardware expects QPitch to be
"in units of rows in the uncompressed surface".
This is the value we originally compute. However, for compressed
surfaces, we then divided it by 4 (the block height), to obtain the
physical layout. This is no longer the QPitch Broadwell expects.
So, store the original undivided value in mt->qpitch, but continue to
use the divided value in brw_miptree_layout_texture_array(). For
non-Broadwell platforms, this should have no impact at all.
Helps fix Piglit's "getteximage-targets S3TC CUBE" test on Broadwell.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch fixes the NetBSD build.
NetBSD does not have pthread_mutex_timedlock.
CC glapi_dispatch.lo
threads_posix.h: In function 'mtx_timedlock':
threads_posix.h:216:5: error: implicit declaration of function 'pthread_mutex_timedlock'
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
The type of all three parameters are identical, so we don't need to
specify it three times. The predicate is always identical too, so we
don't need to make it a parameter, either.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Simple shaders such as:
void splat(vec2 v, float f) {
v[0] = v[1] = f;
}
failed to compile with the following error:
error: value of type vec2 cannot be assigned to variable of type float
First, we would process v[1] = f, and transform:
LHS: (expression float vector_extract (var_ref v) (constant int (1)))
RHS: (var_ref f)
into:
LHS: (var_ref v)
RHS: (expression vec2 vector_insert (var_ref v) (constant int (1))
(var_ref f))
Note that the LHS type is now vec2, not a float. This is surprising,
but not the real problem.
After emitting assignments, this ultimately becomes:
(declare (temporary) vec2 assignment_tmp)
(assign (xy)
(var_ref assignment_tmp)
(expression vec2 vector_insert (var_ref v) (constant int (1))
(var_ref f)))
(assign (xy) (var_ref v) (var_ref assignment_tmp))
We would then return (var_ref assignment_tmp) as the rvalue, which has
the wrong type---it should be float, but is instead a vec2.
To fix this, we simply return (vector_extract (var_ref assignment_temp)
<the appropriate channel>) to pull out the desired float value.
Fixes Piglit's chained-assignment-with-vector-constant-index.vert and
chained-assignment-with-vector-dynamic-index.vert tests.
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74026
Reported-by: Dan Ginsburg <dang@valvesoftware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Transform feedback may come from either the geometry shader or the
vertex shader, so we can't use
ctx->Shader.CurrentProgram[MESA_SHADER_VERTEX] to find the current
post-link transform feedback information. Fortunately we can use
ctx->TransformFeedback.CurrentObject->shader_program.
Cc: 10.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previous to this patch, the _mesa_{Begin,Resume}TransformFeedback
functions were using ctx->Shader.CurrentProgram[MESA_SHADER_VERTEX] to
find the program that would be the source of transform feedback data.
This isn't correct--if there's a geometry shader present it should be
ctx->Shader.CurrentProgram[MESA_SHADER_GEOMETRY]. (These might be
different if separate shader objects are in use).
This patch creates a function get_xfb_source(), which figures out the
correct program to use based on GL state, and updates
_mesa_{Begin,Resume}TransformFeedback to call it. get_xfb_source() is
written in terms of the gl_shader_stage enum, so it should not need
modification when we add tessellation shaders in the future. It also
creates a new driver flag, NewTransformFeedbackProg, which is flagged
whenever this program changes.
To reduce future confusion, this patch also rewords some comments and
error message text to avoid referring to vertex shaders.
Cc: 10.0 <mesa-stable@lists.freedesktop.org>
v2: make the for loop in get_xfb_source() clearer.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The "shader" field in fs_generator, vec4_generator, and gen8_generator
was only used for one purpose; to figure out if we were compiling an
assembly program or a GLSL shader (shader is NULL for assembly
programs). And it wasn't being used properly: in vec4 shaders we were
always initializing it based on
prog->_LinkedShaders[MESA_SHADER_FRAGMENT], regardless of whether we
were compiling a geometry shader or a vertex shader.
This patch simplifies things by using the "prog" field instead; this
is also NULL for assembly programs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Instead of defining preprocessor macros in glcpp_parser_create based on
the GL API, wait until the shader version has been resolved. Doing this
allows us to correctly set (and not set) preprocessor macros for
extensions allowed by the API but not the shader, as in the case of
ARB_ES3_compatibility.
The shader version has been resolved when the preprocessor encounters
the first preprocessor token, since the GLSL spec says
"The #version directive must occur in a shader before anything else,
except for comments and white space."
Specifically, if a #version token is found the version is known
explicitly, and if any other preprocessor token is found then the GLSL
version is implicitly 1.10.
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71630
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes glean fragProg1 regression caused by commit b9f68d927e
(implement TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS). This bug
only appears when the fragment shader emits fragment.Z before
color outputs. The bug was caused by confusion between register
indexes and semantic indexes.
Also added some comments to better explain register indexing.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Otherwise we pull libudev as a dependency and crash
games/programs that ship their own version of libudev.
Either way we should link the loader lib only when needed.
This fixes a regression caused by
commit eac776cf77
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: Sat Jan 11 02:24:43 2014 +0000
glx: use the loader util lib
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73854
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Leaving it set to zero isn't really correct since every allocation has
at least an alignment of 1 byte. It also caused a problem in the i965
driver after I removed the MAX(64, ...) from the alignment calculation.
That's what I get for changing a patch without retesting it. :(
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73907
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Lu Hua <huax.lu@intel.com>
Sed job:
grep -lr BEGIN_BATCH_NO_AUTOSTATE src/mesa/drivers/dri/ | while read f
do
cat $f | sed 's/BEGIN_BATCH_NO_AUTOSTATE/BEGIN_BATCH/g' > x
mv x $f
done
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Marek Olšák <marek.olsak@amd.com>
This parameter hasn't been used since January 2010 (commit 29e02c7).
Fixes the following warning in both radeon and r200:
radeon_common.c: In function 'r200_rcommonBeginBatch':
radeon_common.c:762:14: warning: unused parameter 'dostate' [-Wunused-parameter]
Note that now BEGIN_BATCH and BEGIN_PATCH_NO_AUTOSTATE are identical.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Marek Olšák <marek.olsak@amd.com>
radeon_common.c: In function 'radeon_draw_buffer':
radeon_common.c:237:3: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Marek Olšák <marek.olsak@amd.com>
When parameters were removed from dd_function_table::Viewport (commit
065bd6ff), radeon_viewport (in both radeon and r200) started generating
a warning.
radeon_common.c: In function 'r200_radeon_viewport':
radeon_common.c:415:15: warning: assignment from incompatible pointer type [enabled by default]
radeon_common.c:419:23: warning: assignment from incompatible pointer type [enabled by default]
I didn't notice this initially, and it's harmless because the function is
never called through the incorrectly typed pointer.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Marek Olšák <marek.olsak@amd.com>
Otherwise they will be NULL when stage destroy is invoked prematurely,
(i.e, on out of memory).
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Use some new helper functions to make the code much more readable.
And fix wrong value for XPD's w result.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
In some cases we were converting generic formats to sized formats
and vice versa. The point is to simply convert sRGB formats to
corresponding linear formats.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Became apparent with the C11 thread changes. Unfortunately I didn't
have all dependencies to build the driver, and only noticed
this issue on build server.
Implementation is based of https://gist.github.com/2223710 with the
following modifications:
- inline implementatation
- retain XP compatability
- add temporary hack for static mutex initializers (as they are not part
of the stack but still widely used internally)
- make TIME_UTC a conditional macro (some system headers already define
it, so this prevents conflict)
- respect HAVE_PTHREAD macro
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
Previously the reason we needed is_array was because we used array_size == NULL to
represent both non-arrays and unsized arrays. Now that we use a non-NULL
array_specifier to represent an unsized array, is_array is redundant.
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We need to insert outermost dimensions in the correct spot otherwise
the dimension order will be backwards
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
array
This change does not help fix or prevent any bugs
it just seems reasonable to do
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
No regressions on IVB (piglit quick + unit tests).
v2 (Paul):
- no need to patch the unit tests anymore. Original logic
was altered and unit tests updated to match the
fs-generator
- lrp emission moves from the blorp compiler core into the
emitter here (previously there was a separate refactoring
patch which is not really needed anymore as the lrp logic
got refactored when the original lrp logic got fixed).
- pass 'BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX' to the
generator in fs_inst::target instead of hardcoding it
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The compiler for blorp programs likes to emit instructions for
the message construction itself meaning that the generator needs
to skip any such when blorp programs are translated for the hw.
In addition, the binding table control is special for blorp
programs and the generator does not need to update the binding
tables associated with the compiler bookkeeping (this in fact
gets thrown away as the blorp compiler sets the program data
in its own way).
v2 (Paul): do not hardcode the binding table index but use
fs_inst::target instead.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Unit tests comparing generated blorp programs to known good need
to have the dump in designated file instead of in default
standard output. The comparison also expects the jump counters
of if-else-instructions to be correctly set and hence the dump
needs to be taken _after_ 'patch_IF_ELSE()' is run (the default
dump of the fs_generator does this before).
v2 (Paul): dropped the redundant 'dump_enabled' argument
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
In addition, the special case requiring explicit execution size
control is wrapped manually.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
In addition, the two special cases requiring explicit execution
size control are wrapped manually.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
v2 (Paul): pass the combining opcode as an argument to emit_combine().
This keeps manual_blend_average() selfcontained
documentation wise.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Resolving of the hardware message type is moved into the
emitter also in preparation for switching to use fs_generator.
The generator wants to translate the high level op-code into
the message type and hence the emitter needs to know the
original op-code.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Prepares for the introduction of non-compressed multi-sampled
lookup used in the blorp programs.
v2: now also taking into account gen8
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The combination of four separate comparison operations and
and the masked "and" require special treatment when moving
to FS LIR.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Prepares for presenting blorp blit programs using FS IR that
allows EU-assembly generation using i965 glsl-compiler
backend (fs_generator).
v2: rebased on top of endif-jump counter fix (moving the
added brw_set_uip_jip() into the emitter)
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The Intel closed source OpenGL driver recently began supporting 32
texture image units on Haswell. This makes the open source driver
support 32 as well.
Earlier generations don't have the message header field required to
support more than 16 sampler states, so we continue to advertise 16
there.
On Haswell, this causes us to advertise:
- GL_MAX_TEXTURE_IMAGE_UNITS = 32
- GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 32
- GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96
instead of the old values of 16, 16, and 48.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
BRW_MAX_TEX_UNIT is about to grow, but only Gen7+ will be able to
support the new larger value. On older platforms, we don't want to
allocate the extra space - it would just be a waste.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Like the scalar backend, we add an offset to the "Sampler State Pointer"
field to select a group of 16 samplers, then use the "Sampler Index"
field to select within that group.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
The next patch adds an additional case where the message header is
necessary. So we want to do the g0 copy if inst->header_present is set,
rather than inst->texture_offset.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
In theory, a shader might use textureOffset() but set all the texel
offsets to zero. In that case, we don't actually need to set up the
message header - zero is the implicit default.
By moving the texture_offset setup before the header_present setup, we
can easily only set header_present when there are non-zero texel offset
values.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
The message descriptor's "Sampler Index" field is only 4 bits (on all
generations of hardware), so it can only represent indices 0 through 15.
Haswell introduced a new field in the message header - "Sampler State
Pointer". Normally, this is copied straight from g0, but we can also
add a byte offset (as long as it's a multiple of 32).
This patch uses a "Sampler State Pointer" offset to select a group of
16 sampler states, and then uses the "Sampler Index" field to select
the state within that group.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Previously, the code to copy g0 to the message header existed in two
places - one for the texture offset case, and one for any other case.
By treating texture_offset as a special case of header_present, we can
remove this duplication and shorten the code. Future patches which add
new header fields also won't have to add additional duplication.
This also clarifies a confusing construct. The old code contained:
} else if (inst->header_present) {
if (brw->gen >= 7) {
...explicit copy from g0 to the message header...
} else {
/* Set up an implied move from g0 to the MRF. */
}
}
This looks like it might set up an implied move on Sandybridge, which
doesn't support those. However, Sandybridge only uses a message header
for texture offsets, so it would never hit this code path. The new code
avoids this implicit knowledge by only setting up an implied move on
Gen4-5.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Use the WINDOW and VPORT scissors for the framebuffer and scissor test,
respectively. The other two scissors are disabled (they cover the max fb size).
We actually have 16 VPORT scissors, which will map well to ARB_viewport_array.
Also, we don't need to write SC_WINDOW_OFFSET with this commit, because it's
disabled everywhere.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Also set the unsynchronized flag if the whole resource was discarded
to avoid doing buffer-busy checks again.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It's unused and shouldn't be used at all in my opinion.
If some driver doesn't support the unsynchronized flag, u_upload_mgr should
avoid the synchronization by other means, e.g. by using the DONTBLOCK flag.
This is the recommended way for streaming vertices. Always use this if you
need to upload vertices every frame.
Reviewed-by: Christian König <christian.koenig@amd.com>
Commit 05da4a7a5e attempts to eliminate the
call to intel_update_renderbuffer() in the case where we already have a
drawbuffer for the drawable. Unfortunately this only checks the
back left renderbuffer, which breaks in case of single buffer drawables.
This means that the initial viewport will not be set in that case. Instead,
we now check whether the initial viewport has not been set, in which case
we call out to intel_update_renderbuffer().
https://bugs.freedesktop.org/show_bug.cgi?id=73862
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Most of the time it is not necessary to perform type inference to
compile GLSL; the type of every expression can be inferred from the
contents of the expression itself (and previous type declarations).
The exception is aggregate initializers: their type is determined by
the LHS of the variable being assigned to. For example, in the
statement:
mat2 foo = { { 1, 2 }, { 3, 4 } };
the type of { 1, 2 } is only known to be vec2 (as opposed to, say,
ivec2, uvec2, int[2], or a struct) because of the fact that the result
is being assigned to a mat2.
Previous to this patch, we handled this situation by doing some type
inference during parsing: when parsing a declaration like the one
above, we would call _mesa_set_aggregate_type(), which would infer the
type of each aggregate initializer and store it in the corresponding
ast_aggregate_initializer::constructor_type field. Since this
happened at parse time, we couldn't do the type inference using
glsl_type objects; we had to use ast_type_specifiers, which are much
more awkward to work with. Things are about to get more complicated
when we add support for ARB_arrays_of_arrays.
This patch simplifies things by postponing the call to
_mesa_set_aggregate_type() until ast-to-hir time, when we have access
to glsl_type objects. As a side benefit, we only need to have one
call to _mesa_set_aggregate_type() now, instead of six.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Specs say "If the argument is a buffer object, the arg_value
pointer can be NULL or point to a NULL value in which case a NULL
value will be used as the value for the argument declared as a
pointer to __global or __constant memory in the kernel."
So don't crash when somebody does that.
v2: Insert NULL into input buffer instead of buffer handle pair
Fix constant_argument too
Drop r600 driver changes
v3: Fix inserting NULL pointer
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
No known bugs fixed but this is now in line with fs-generator.
No regresssions on IVB.
Eric further explained that:
"The endif jump, since it's forward, is just an optimization to
have set right -- otherwise, the GPU will just step forward
instruction by instruction until it hits something else that
updates the per-channel PC."
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is possible now that ctx->Shader.CurrentProgram is an array.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
This is possible now that ctx->Shader.CurrentProgram is an array.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
Now that we have a ctx->Shader.CurrentProgram array, we can just use
it directly.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
Since ctx->Shader.Current{Vertex,Geometry,Fragment}Program is an
array, this allows some meta code to be rolled up into loops.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
These are replaced with
ctx->Shader.CurrentProgram[MESA_SHADER_{VERTEX,FRAGMENT,GEOMETRY}].
In patches to follow, this will allow us to replace a lot of ad-hoc
logic with a variable index into the array.
With the exception of the changes to mtypes.h, this patch was
generated entirely by the command:
find src -type f '(' -iname '*.c' -o -iname '*.cpp' ')' \
-print0 | xargs -0 sed -i \
-e 's/\.CurrentVertexProgram/.CurrentProgram[MESA_SHADER_VERTEX]/g' \
-e 's/\.CurrentGeometryProgram/.CurrentProgram[MESA_SHADER_GEOMETRY]/g' \
-e 's/\.CurrentFragmentProgram/.CurrentProgram[MESA_SHADER_FRAGMENT]/g'
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
Rather than maintain separately named arrays and counts for vertex,
geometry, and fragment shaders, just maintain these as arrays indexed
by the gl_shader_type enum.
v2: When there is neither a vertex nor a geometry shader, set
prog->LastClipDistanceArraySize = 0, and clarify that the values is
not used.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch replaces code in _mesa_new_shader() and delete_shader_cb()
that checks the type of a shader with calls to
_mesa_validate_shader_target(). This has two advantages: it allows
for a more thorough check (since _mesa_validate_shader_target()
doesn't permit shader targets that aren't supported by the back-end),
and it reduces the amount of code that will need to be modified when
adding new shader stages.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
This will allow this function to be used in circumstances where there
is no context available, such as when building built-in GLSL
functions.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
In my recent zeal to refactor Mesa's handling of the gl_shader_stage
enum, I accidentally wound up with two functions that do the same
thing: _mesa_program_index_to_target(), and
_mesa_shader_stage_to_program().
This patch keeps _mesa_shader_stage_to_program(), since its name is
more consistent with other related functions. However, it changes the
signature so that it accepts an unsigned integer instead of a
gl_shader_stage--this avoids awkward casts when the function is called
from C++ code.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
We have to make the functions available to work around a GLEW bug (see
comments already in the code), but if an application calls one of these
functions we should still generate GL_INVALID_OPERATION.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch handles the use of 'centroid' qualifier with 'in' variables
in a fragment shader when persample shading is enabled. Per sample
shading for the whole fragment shader can be enabled by:
glEnable(GL_SAMPLE_SHADING) or using {gl_SamplePosition, gl_SampleID}
builtin variables in fragment shader. Explaining it below in more
detail.
/* Enable sample shading using OpenGL API */
glEnable(GL_SAMPLE_SHADING);
glMinSampleShading(1.0);
Example fragment shader:
in vec4 a;
centroid in vec4 b;
main()
{
...
}
Variable 'a' will be interpolated at sample location. But, what
interpolation should we use for variable 'b' ?
ARB_sample_shading recommends interpolation at sample position for
all the variables. GLSL 400 (and earlier) spec says that:
"When an interpolation qualifier is used, it overrides settings
established through the OpenGL API."
But, this text got deleted in later versions of GLSL.
NVIDIA's and AMD's proprietary linux drivers (at OpenGL 4.3)
interpolates at sample position. This convinces me to use
the similar approach on intel hardware.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Current implementation of arb_sample_shading doesn't set 'Barycentric
Interpolation Mode' correctly. We use pixel barycentric coordinates
for per sample shading. Instead we should select perspective sample
or non-perspective sample barycentric coordinates.
It also enables using sample barycentric coordinates in case of a
fragment shader variable declared with 'sample' qualifier.
e.g. sample in vec4 pos;
A piglit test to verify the implementation has been posted on piglit
mailing list for review.
V2: Do not interpolate all the 'in' variables at sample position
if fragment shader uses 'sample' qualifier with one of them.
For example we have a fragment shader:
#version 330
#extension ARB_gpu_shader5: require
sample in vec4 a;
in vec4 b;
main()
{
...
}
Only 'a' should be sampled at sample location, not 'b'.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
This will be useful in my next patch which depends on a functionality
of _mesa_get_min_invocations_per_fragment() to ignore the sample
qualifier (prog->IsSample) based on a flag passed to it.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reduces vertex shader instruction counts in DOTA2 by 6.42%, L4D2 by
4.61%, and CS:GO by 5.71%.
total instructions in shared programs: 1500153 -> 1498191 (-0.13%)
instructions in affected programs: 59919 -> 57957 (-3.27%)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Only implemented for ir_swizzles currently, but perhaps will be useful
for other IR types in the future.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This flag was really just a proxy for determining whether the backend
was vector (AOS) or scalar (SOA). It will be used to apply a future
optimization only for vector backends.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Dumping the number of live registers at each IP allows us to see
register pressure and identify any local maxima. This should
aid in debugging passes designed to reduce register pressure, as
well as optimizations that suddenly trigger spilling.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Calling it after value numbering (added in the next commit) prevents
some instruction count regressions.
total instructions in shared programs: 1524387 -> 1523905 (-0.03%)
instructions in affected programs: 13112 -> 12630 (-3.68%)
GAINED: 0
LOST: 3
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Previously we simply considered two registers whose live ranges
overlapped to interfere. Cases such as
set A ------
... |
mov B, A -- |
... | B | A
use B -- |
... |
use A ------
would be considered to interfere, even though B is an unmodified copy of
A whose live range fit wholly inside that of A.
If no writes to A or B occur between the mov B, A and the use of B then
we can safely coalesce them.
Instead of removing MOV instructions, we make them NOPs and remove them
at once after the main pass is finished in order to avoid recomputing
live intervals (which are needed to perform the previous step).
total instructions in shared programs: 1543768 -> 1513077 (-1.99%)
instructions in affected programs: 951563 -> 920872 (-3.23%)
GAINED: 46
LOST: 22
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
mov takes only a single source argument. Example instruction
inexplicably changed from add to mov in commit f10f5e49.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Unnamed record types are assigned to separate types per stage, e.g. if
uniform struct { ... } a;
is defined in both vertex and fragment shader, two separate types will
result with different names. When linking the shader, this results in a
type conflict. However, there is no reason why this should not be
allowed according to GLSL specifications. Compare and match record types
when linking shader stages to avoid this conflict.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes several colorbuffer tests, including piglit "fbo-drawbuffers-none"
for "gl_FragColor" and "glDrawPixels" cases.
v2: rework patch to only avoid creating extra shader variants when
TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS is not specified. Per Jose.
Use a write_color0_to_n_cbufs key field to replicate color0 to N
color buffers only when N > 0 and WRITES_ALL_CBUFS is set.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The new TYPE_DOUBLEN_2 type was added in 0e60d850 but the code to
return values of that type wasn't completed.
Fixes conform's default state test. glGetFloatv(GL_DEPTH_RANGE)
wasn't returning anything.
v2: remove stray 'break' statements.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
These messages are in code that is shared between the VS and GS
back-ends, so use the terminology "vec4" to avoid confusion.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Even with depth clipping disabled, vertices which have negative w coords
must be discarded. And since we don't have a proper guardband implementation
yet (relying on driver to handle all values except infs/nans in rasterization
for such points) we need to kill them off manually (as they can end up with
coordinates inside viewport otherwise).
v2: use 0.0f instead of 0 (spotted by Brian).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: Also increment ir->offset in the GS visitor, rather than at the
final assembly generation stage (requested by Paul).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
On Broadwell, PIPE_CONTROL needs an extra DWord to accomodate the
48-bit addressing.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Now that we have a helper function that handles the PIPE_CONTROL
variations between the various platforms, these are basically the same.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
There are a lot of places that use PIPE_CONTROL to write a value to a
buffer (either an immediate write, TIMESTAMP, or PS_DEPTH_COUNT).
Creating a single function to do this seems convenient.
As part of this refactor, we now set the PPGTT/GTT selection bit
correctly on Gen7+. Previously, we set bit 2 of DW2 on all platforms.
This is correct for Sandybridge, but actually part of the address on
Ivybridge and later!
Broadwell will also increase the length of these packets by 1; with the
refactoring, we should have to adjust that in substantially fewer
places, giving us confidence that we've hit them all.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
I believe that PIPE_CONTROL uses the length field to decide whether to
do 32-bit or 64-bit writes. A length of 4 would do a 32-bit write,
while a length of 5 would do a 64-bit write. (I haven't verified this,
though.)
For workaround writes, we don't care what value gets written, or how
much data. We're only writing something because hardware bugs mandate
that do so. So using a 64-bit write should be fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The PIPE_CONTROL packet actually has 5 DWords on Gen6+:
1. Header
2. Flags
3. Address
4. Immediate Data: Lower DWord
5. Immediate Data: Upper DWord
We just never emitted the last one. While it appears to work, it's
probably safer to emit the entire thing.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These days, we need to emit PIPE_CONTROL flushes all over the place.
Being able to do that via a single function call seems convenient.
Broadwell will also increase the length of these packets by 1; with the
refactoring, we should have to do this in substantially fewer places.
v2: Add back forgotten intel_emit_post_sync_nonzero_flush (caught by
Eric Anholt). Drop unlikely() from BLT_RING check.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
and the second DWord is the high 16 bits.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
libdrm 2.4.52 introduces a new 'uint64_t offset64' field, intended to
replace the old 'unsigned long offset' field. To preserve ABI, libdrm
continues to store the presumed offset in both locations.
On Broadwell, a 64-bit kernel may place BOs at "high" (> 4G) addresses.
However, with a 32-bit userspace, the 'unsigned long offset' field will
only be 32-bit, which is not large enough to hold this value. We need
to use a proper uint64_t (like the kernel does).
Technically, a lot of this code doesn't affect Broadwell, so we could
leave it using the old field. But it makes sense to just switch to the
new, properly typed field.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
intel_buffer_objects.c: In function 'old_intel_bufferobj_buffer':
intel_buffer_objects.c:471:17: warning: unused parameter 'flag' [-Wunused-parameter]
The parameter hasn't been used since the i915 and i965 drivers had their
breakup. i965 got the flags, and i915 got to cry itself to sleep.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Not actually tested, but the changes are identical to the i965 changes
that are tested.
v2: Remove MAX2(64, ...). Suggested by Ken (in the i965 version of this
patch).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: Siavash Eliasi <siavashserver@gmail.com>
No piglit regressions on IVB.
With minor tweaks to the arb_map_buffer_alignment-map-invalidate-range
test (disable the extension check, set alignment to 64 instead of
querying), the i965 driver would fail the test without this patch (as
predicted by Eric). With this patch, it passes.
v2: Remove MAX2(64, ...). Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: Siavash Eliasi <siavashserver@gmail.com>
v2 (idr): Only enable the extension on GEN7+ w/core profile because it
requires geometry shaders.
v3 (idr): Add some casting to fix setting of ViewportBounds.Min.
Negating an unsigned value, then casting to float doesn't do what you
might think it does.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
noop_scissor (correctly) only examines the scissor rectangle for
viewport 0. Therefore, it should only be called when that scissor
rectangle is enabled.
v2: Remove spurious change to radeon code. Noticed by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Currently MaxViewports is still 1, so this won't affect any change.
v2: Minor code reformatting suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Drivers that currently use _Xmin and friends to set their scissor
rectangle will need to use this code directly once they are updated for
GL_ARB_viewport_array.
v2: Use different bit-test idiom and fix mixed tabs and spaces. Both
were suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
At various stages the hardware clamps the gl_ViewportIndex to these
values. Setting them to zero effectively makes gl_ViewportIndex be
ignored. This is acutally useful in blorp (so that we don't have to
modify all of the viewport / scissor state).
v2: Use INTEL_MASK to create GEN6_CLIP_MAX_VP_INDEX_MASK. Suggested by
Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Define API connections to extension entry points added in previous
commits. Update entry points to use floating point arguments as
required by the extension.
Add get tokens for ARB_viewport_array state.
v2: Include review feedback.
v3 (idr): Fix 'make check'. Add missing Get infrastructure (some was
culled from other pathces).
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (idr): Use set_viewport_no_notify / set_depth_range_no_notify (and
manually notify the driver) instead of calling _mesa_set_viewporti /
_mesa_set_depthrangei. Refactor bodies of _mesa_ViewportIndexed and
_mesa_ViewportIndexedv into a shared function. Remove spurious CLAMP
calls in _mesa_DepthRangeArrayv and _mesa_DepthRangeIndexed.
v3 (idr): Add some missing return-statements after calls to _mesa_error.
v4 (idr): Only perform the ViewportBounds.Min / ViewportBounds.Max
clamping in set_viewport_no_notify if GL_ARB_viewport_array is enabled.
Otherwise the driver may not have set ViewportBounds, and the clamping
will do bad things.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (idr): Use set_scissor_no_notify (and manually notify the driver)
instead of calling _mesa_set_scissori. Refactory bodies of
_mesa_ScissorIndexed and _mesa_ScissorIndexedv into a shared function.
Perform parameter validation in the same order in all three functions.
Pull MaxViewports comparison fix (in _mesa_ScissorArrayv) from the next
patch to this patch.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Now that the scissor enable state is a bitfield need a custom function
to extract the correct value from gl_context. Modeled
Scissor.EnableFlags after Color.BlendEnabled.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (idr): Fix several "comparison between signed and unsigned integer
expressions" warnings.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This matches the expectations of GL_ARB_viewport_array and the storage
type where the values will land.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously the restore code would enable all scissor rectangles if any
scissor rectangles were enabled on entry to meta. When there is only
one scissor rectangle, this is fine. As soon as a driver supports
multiple viewports, this will be a problem.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In _mesa_Scissor, make sure that ctx->Driver.Scissor is only called once
instead of once per scissor rectangle.
v2: Use MAX_VIEWPORTS instead of ctx->Const.MaxViewports because the
driver may not set ctx->Const.MaxViewports yet.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In _mesa_Viewport and _mesa_DepthRange, make sure that
ctx->Driver.Viewport is only called once instead of once per viewport or
depth range.
v2: Make _mesa_DepthRange actually set all of the depth ranges (instead
of just index 0). Noticed by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Use MAX_VIEWPORTS instead of ctx->Const.MaxViewports because the
driver may not set ctx->Const.MaxViewports yet.
v3: Handle all viewport entries in update_viewport_matrix and
_mesa_copy_context too. This was previously in an earlier patch.
Having the code in the earlier patch could cause _mesa_copy_context to
access a matrix that hadn't been constructed.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v2]
Create an internal function that just writes data into the scissor
rectangle. In future patches this will see more use because we only
want to call dd_function_table::Scissor once after setting all of the
scissor rectangles instead of once per scissor rectangle.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Create an internal function that just writes data into the viewport. In
future patches this will see more use because we only want to call
dd_function_table::Viewport once after setting all of the viewport
instead of once per viewport.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Create an internal function that just writes data into the depth range.
In future patches this will see more use because we only want to call
dd_function_table::DepthRange once after setting all of the depth ranges
instead of once per depth range.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Only element 0 of the array is used anywhere at this time, so there
should be no changes.
v4: Split out from a single megapatch. Suggested by Ken.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v4: Split out from a single megapatch. Suggested by Ken. Also make
meta's save_state::ViewportX, ::ViewportY, ::ViewportW, and ::ViewportH
to match gl_viewport_attrib.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will be used when the viewport near and far plane are stored as
doubles instead of as floats.
v4 (idr): Split out from a single megapatch. Suggested by Ken. Also
drop value_double_4. It's never used anywhere in the patch series.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Update Mesa and drivers to access updated gl_scissor_attrib.
Now have an enable bitfield and array of gl_scissor_rects.
Drivers have been updated to the new scissor enable state
attribute (gl_context.scissor.EnableFlags) but still treat it
as a single boolean which is okay as mesa will only use
bit 0 when communicating with a driver that does not support
ARB_viewport_array.
v2 (idr): Rebase fixes.
v3 (idr): Small code formatting fix suggsted by Ken.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These limits will be queryable by GL_MAX_VIEWPORTS,
GL_VIEWPORT_SUBPIXEL_BITS, and GL_VIEWPORT_BOUNDS_RANGE. Drivers that
actually implement the extension must set values for these constants
that comply with the minimum-maximums from the spec.
Most of these changes were part of other patches. They were separated out
because it make reordering of later patches easier. Also, MaxViewports wasn't
set by that patch, and I completely overlooked it in review. It's now obvious
that it's set. :)
v2 (idr): Split these changes out from the original patches. Keep
MaxViewportWidth and MaxViewportHeight as GLuint.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (idr): Split these changes out from the original patch. Only
advertise GL_ARB_viewport_array in a core profile because it requires
geometry shaders.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were calling draw_total_vs_outputs() too early. The call to
draw_pt_emit_prepare() could result in the vertex size changing.
So call draw_total_vs_outputs() after draw_pt_emit_prepare().
This fix would seem to be needed for the non-LLVM code as well,
but it's not obvious. Instead, I added an assertion there to
try to catch this problem if it were to occur there.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72926
Cc: 10.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Instead of skipping x/y clipping completely if there's point_tri_clip points
use guard band clipping. This should be easier (previously we could not disable
generating the x/y bits in the clip mask for llvm path, hence requiring custom
clip path), and it also allows us to enable this for tris-as-points more easily
too (this would require custom tri clip filtering too otherwise). Moreover,
some unexpected things could have happen if there's a NaN or just a huge number
in some tri-turned-point, as the driver's rasterizer would need to deal with it
and that might well lead to undefined behavior in typical rasterizers (which
need to convert these numbers to fixed point). Using a guardband should hence
be more robust, while "usually" guaranteeing the same results. (Only "usually"
because unlike hw guardbands draw guardband is always just twice the vp size,
hence small vp but large points could still lead to different results.)
Unfortunately because the clipmask generated is completely unaffected by guard
band clipping, we still need a custom clip stage for points (but not for tris,
as the actual clipping there takes guard band into account).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
These are components which were originally developed by Tungsten Graphics,
which was in turn acquired by VMware, but are de facto now being maintained
by third-party contributors of the Mesa open-source community.
This matches what's reported by swrast driver and a few other components.
Suggested by Ian Romanick.
Currently the MSVC build is broken because of conflicting definitions of
'log' function. I didn't investigate thoroughly, but I suspect the
it is conflicting standard math.h's log.
log_ is admittedly not a great name, but it is better than a broken build.
A better one can be used in a follow-on build.
By highlighting these special cases makes it clearer to switch
to the fs-generator as the wider scoped compression control
settings used in the current implementation can be simply
dropped.
No regressions on IVB (piglit quick + unit tests).
v2 (Ian): typo in a comment
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Effectively only the mask control bit gets altered for the single
addition in question and hence there is no real need to use a
fresh state control level for it -- that is more useful when
multiple intructions share the same mask and compression settings.
This is a preparation step for removing the explicit compression
control modifiers in the blit compiler. After this patch there
are no nested state control levels making the constant nature of
the compression settings more apparent.
No regressions on IVB (piglit quick + unit tests).
v2 (Matt, Ian): use temporary variable instead of assigning
directly on the same line with a function call.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We call intel_prepare_render() in intelMakeCurrent() to make sure we have
renderbuffers before calling _mesa_make_current(). The only reason we
do this is so that we can have valid defaults for width and height.
If we already have buffers for the drawable we're making current, we
don't need this step.
In itself, this is a small optimization, but it also avoids a round trip
that could block on the display server in a unexpected place.
https://bugs.freedesktop.org/show_bug.cgi?id=72540https://bugs.freedesktop.org/show_bug.cgi?id=72612
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
NV3x cards don't support NPOT textures. Technically this restriction
could be worked around, but since it also doesn't expose any video
decoding hw, just turn it off entirely.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: 10.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
pipe_loader_drm.c: In function 'pipe_loader_drm_probe_fd':
pipe_loader_drm.c:120:4: error: implicit declaration of function 'loader_get_pci_id_for_fd' [-Werror=implicit-function-declaration]
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Mesa provides the flexibility of building without the
need to have libdrm present on the system. The situation
has regressed with the recent commit
commit 8c2e7fd846
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: Fri Jan 10 23:36:16 2014 +0000
loader: introduce the loader util lib
By isolating libdrm code by #ifndef __NOT_HAVE_DRM_H we
can have libdrm-less builds on across all build systems.
This patch converts Android's _EGL_NO_DRM to __NOT_HAVE_DRM_H
to provide consistency with the other cases within mesa, allows
compilation of libloader on libdrm-less scons and conditionally
links against libdrm if present under automake.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73776
BUgzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73777
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The only difference is that STATE_SIP takes a 48-bit address, so we need
to output two zeroes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This replaces the old fs_generator backend.
v2: Port to the C-based representation of assembly instructions.
Fix texturing after the texture-grf merge.
v3: Add high quality derivative support. Fix SET_SIMD4X2_OFFSET.
v4: Pass brw_context to gen8_instruction functions as required.
v5: Fixes for MRT, as well as zero render targets (alpha test only).
v6: Replace n-wide with SIMDn in comments and messages; port over
Topi's blorp-generator changes; add missing TXF_MCS opcode,
fix missing high quality derivatives for DDX; fix typo (all caught
by Eric). Simplify ADDC/SUBB handling; drop "Used only on Gen6+"
comment (caught by Matt). Emit SIMD16 versions of three source
instructions (caught by both Eric and Matt).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This replaces the old vec4_generator backend.
v2: Port to use the C-based instruction representation. Also, remove
Geometry Shader offset hacks - the visitor will handle those instead
of this code.
v3: Texturing fixes (including adding textureGather support).
v4: Pass brw_context to gen8_instruction functions as required.
v5: Add SHADER_OPCODE_TXF_MCS support; port DUAL_INSTANCED gs fixes
(caught by Eric). Simplify ADDC/SUBB handling; add comments to
gen8_set_dp_message calls (suggested by Matt).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This replaces the brw_eu_emit.c layer for Broadwell. It will be
used by both the vector and scalar shader backends.
v2: Port to use the C-based instruction representation.
v3: Fix destination register type for CMP.
v4: Pass brw to gen8_instruction functions (required by rebase).
v5: Remove bogus assertion on math instructions (caught by Piglit).
v6: Remove more restrictions on math instructions (caught by Eric).
Make ADDC and SUBB helpers set accumulator writes, like MAC and
MACH (caught by Matt).
v7: Don't implicitly force ALU3 operations to SIMD8 (we've been able
to do SIMD16 versions since Haswell, but didn't when I originally
wrote this code).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Heavily based on Keith Packard's existing brw_disasm.c code. I've tried
to go through most of the pieces (like SFIDs) and update the lists to
include features added in recent generations.
v2: Port to use the C-based instruction emitters. This allows us to use
C99 array initializers, which tidies up some of the code.
v3: Improve decoding of render target write messages.
v4: Update for BRW_REGISTER_TYPE becoming an abstraction.
v5: Rebase on Chris Forbes' SFID message defines.
v6: Fix disassembly of UV immediates; remove silly casts.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Broadwell significantly changes the EU instruction encoding. Many of
the fields got moved to different bit positions; some even got split
in two.
With so many changes, it was infeasible to continue using struct
brw_instruction. We needed a new representation.
This new approach is a bit different: rather than a struct, I created a
class that has four DWords, and helper functions that read/write various
bits. This has several advantages:
1. We can create several different names for the same bits. For
example, conditional modifiers, SFID for SEND instructions, and the
MATH instruction's function opcode are all stored in bits 27:24.
In each situation, we can use the appropriate setter function:
set_sfid(), set_math_function(), or set_cond_modifier(). This
is much easier to follow.
2. Since the fields are expressed using the original 128-bit numbers,
the code to create the getter/setter functions follows the table in
the documentation very closely.
To aid in debugging, I've enabled -fkeep-inline-functions when building
gen8_instruction.c. Otherwise, these functions cannot be called by
gdb, making it insanely difficult to print out anything.
Kenneth Graunke wrote most of this code. Damien Lespiau ported it to
C99. Xiang Haihao added media fields. Zhao Yakui added indirect
addressing support. Eric Anholt added an assertion to make sure that
values fit in the alloted number of bits.
v2: Update for brw_reg_type_to_hw_type(), which necessitates passing
brw_context pointers around everywhere.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Matt Turner <mattst88@gmail.com>
While we probably won't ever use these, having them makes it easy to
share disassembler code between intel-gpu-tools and Mesa.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is not observed to actually fix anything, but the PRM says this
field must be zero for other surface types.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Previously this was missing many interesting fields. Having them decoded
makes debugging views much easier.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The index passed to the function is already unsigned, and internally
we threat it as unsigned.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The textures array is defined as a number of NV50_MAX_PIPE_CONSTBUFS
per shader stage. Currently the nv50 driver handles only 3 shader
stages, thus we wreck chaos when accessing array-out-of-bounds.
Cc: 9.1 9.2 10.0 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The textures array is defined as a number of PIPE_MAX_SAMPLERS per shader stage.
Currently nv50 driver handles only 3 shader stages, thus we wreck chaos when
accessing array-out-of-bounds.
Fixes a segfault in piglit/bin/arb_texture_buffer_object-data-sync -fbo -auto
Cc: 9.1 9.2 10.0 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Use the kernel driver name are returned by drmGetVersion() for
non-pci(platform) devices.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
v2 (Emil): Rebased and weaked commit message.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Culled out of the "loader: refactor duplicated code into loader util lib"
patch by Rob Clark.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
As per original approach by Rob, each user of the loader lib should include
loader.h and the pci_id_driver_map.h header will be used exclusively by the
loader.
Add back the include guard __IS_LOADER and remove no longer needed include
folder in the scons build.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Additionally this commit removes the following exported functions
_gbm_udev_device_new_from_fd()
_gbm_fd_get_device_name()
_gbm_log()
All three were erroneously marked as exported since their inception.
Neither of them has ever been a part of the API thus there should be
no users of them.
Cc: Chad Versace <chad.versace@linux.intel.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
All the various window system integration layers duplicate roughly the
same code for figuring out device and driver name, pci-id's, etc. Which
is sad. So extract it out into a loader util lib.
v2 (Emil)
* Separate the introduction of libloader from the code de-duplication.
* Strip out non-pci devices support.
* Add scons + Android build system support.
* Add VISIBILITY_CFLAGS to avoid exporting the loader funcs.
v3 (Emil)
* PIPE_OS_ANDROID is undefined at this scope, use ANDROID
* Make sure we define _EGL_NO_DRM when building only swrast
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Using an unoptimized variant of glamor spending 50% of its CPU time in
brw_draw_prims() (and hitting the cache *very* frequently):
N Min Max Median Avg Stddev
x 200 29200 40500 34900 34750 958.43256
+ 200 31000 40300 34700 34622 916.35941
No difference proven at 95.0% confidence
Similarly, no difference on GLB2.7:
N Min Max Median Avg Stddev
x 63 64.1 71.36 70.69 70.113175 1.6782026
+ 63 63.6 71.18 70.75 70.223651 1.6044186
No difference proven at 95.0% confidence
v2: Rebase on master (by anholt)
v3: Add a missing BEGIN_BATCH(3) to aa_line_parameters -- CACHED_BATCH
didn't have the asserts about batchbuffer usage that ADVANCE_BATCH
does, so we started assertion failing.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Those are the terms used in the docs, and think "n-wide" was something I
just happened to say. Note that shader-db needs updating for the
INTEL_DEBUG=fs parsing.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The original intent was that we'd keep a driver-private copy, and there
would be the normal copy for swrast to make use of without the tuning (or
anything more invasive we might do) specific to i965. Only, we don't
generate swrast code any more, because swrast can't render current shaders
anyway. Thus, our private copy is rather a waste, and we can just do our
backend-specific operations on the linked shader.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tungsten Graphics Inc. was acquired by VMware Inc. in 2008. Leaving the
old copyright name is creating unnecessary confusion, hence this change.
This was the sed script I used:
$ cat tg2vmw.sed
# Run as:
#
# git reset --hard HEAD && find include scons src -type f -not -name 'sed*' -print0 | xargs -0 sed -i -f tg2vmw.sed
#
# Rename copyrights
s/Tungsten Gra\(ph\|hp\)ics,\? [iI]nc\.\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./g
/Copyright/s/Tungsten Graphics\(,\? [iI]nc\.\)\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./
s/TUNGSTEN GRAPHICS/VMWARE/g
# Rename emails
s/alanh@tungstengraphics.com/alanh@vmware.com/
s/jens@tungstengraphics.com/jowen@vmware.com/g
s/jrfonseca-at-tungstengraphics-dot-com/jfonseca-at-vmware-dot-com/
s/jrfonseca\?@tungstengraphics.com/jfonseca@vmware.com/g
s/keithw\?@tungstengraphics.com/keithw@vmware.com/g
s/michel@tungstengraphics.com/daenzer@vmware.com/g
s/thomas-at-tungstengraphics-dot-com/thellstom-at-vmware-dot-com/
s/zack@tungstengraphics.com/zackr@vmware.com/
# Remove dead links
s@Tungsten Graphics (http://www.tungstengraphics.com)@Tungsten Graphics@g
# C string src/gallium/state_trackers/vega/api_misc.c
s/"Tungsten Graphics, Inc"/"VMware, Inc"/
Reviewed-by: Brian Paul <brianp@vmware.com>
Fixes regression since 9baa45f78b
but some of the piglit fbo-drawbuffers-none tests still don't
pass.
v2: use the right pointer type for 'h'
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Fixes regression from 9baa45f78b
v2: incorporate a few small changes suggested by Roland.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The whole round-pointsize-to-int stuff must only be done with GL legacy
rules (no point_quad_rasterization) or all the wrong edges are lit up.
This was previously in a private branch (d3d pointsprite test complains
loudly otherwise) and got lost in a merge. However, it should certainly
apply to GL point sprite rasterization as well.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
OpenGL does whole-point clipping, that is a large point is either fully
clipped or fully unclipped (the latter means it may extend beyond the
viewport as long as the center is inside the viewport). d3d9 (d3d10 has
no large points) however requires points to be clipped after they are
expanded to a rectangle. (Note some IHVs are known to ignore GL rules at
least with some hw/drivers.)
Hence add a rasterizer bit indicating which way points should be clipped
(some drivers probably will always ignore this), and add the draw interaction
this requires. Drivers wanting to support this and using draw must support
large points on their own as draw doesn't implement vp clipping on the
expanded points (it potentially could but the complexity doesn't seem
warranted), and the driver needs to do viewport scissoring on such points.
Conflicts:
src/gallium/drivers/llvmpipe/lp_context.c
src/gallium/drivers/llvmpipe/lp_state_derived.c
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Commit c13970808 (mesa: GL_EXT_secondary_color is not optional) changed
CHECK_EXTENSION2(EXT_secondary_color, ARB_vetex_program, cap)
to
CHECK_EXTENSION(ARB_vertex_program, cap)
However CHECK_EXTENSION2 checks that either extension is available, not
both. Remove the extension check entirely since the intent was for it to
always be enabled.
v2: Fix glGet*(GL_COLOR_SUM) too. Suggested by Ian.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: 9.2 10.0 <mesa-stable@lists.freedesktop.org>
It's possible to bind a smaller buffer as a constant buffer, than
what the shader actually uses/requires. This could cause nasty
crashes. This patch adds the architecture to pass the maximum
allowable constant buffer index to the jit to let it make
sure that the constant buffer indices are always within bounds.
The behavior follows the d3d10 spec, which says the overflow
should always return all zeros, and overflow is only defined
as access beyond the size of the currently bound buffer. Accesses
beyond the declared shader constant register size are not
considered an overflow and expected to return garbage but consistent
garbage (we follow the behavior which some wlk tests expect which
is to return the actual values from the bound buffer).
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Commit 95bf222603 (cso_context: Fix cso_context::sample_mask initial
value.) fixed the cso sample mask to be initialized to ~0. The cso code
is also careful not to needlessly call set_sample_mask, so we ended up
with the ctx->sample_mask never being set. This broke a number of
EXT_framebuffer_multisample piglit tests.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
ctx->DrawIndirectBuffer wasn't being free'd in _mesa_free_buffer_objects
With this patch, "valgrind --leak-check=full glxgears" on evergreen (CEDAR)
now shows:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 70,228 bytes in 651 blocks
suppressed: 0 bytes in 0 blocks
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
The radeonsi code was not cleaning up either of these items leading to
leaked memory.
v2: Move cleanup to r600_common_context_cleanup instead of duplicating
the logic for SI
CC: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The i830 and i915 drivers used them, but they didn't really need to.
They will just be annoying in future patches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
A future patch will rename some of the fields of gl_viewport_attrib, and
I don't want to update dead code that I can't test.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Dave Airlie <airlied@redhat.com>
The ES and desktop GL specs diverge here. Yay!
In desktop OpenGL, the driver can perform online compression of
uncompressed texture data. GL_NUM_COMPRESSED_TEXTURE_FORMATS and
GL_COMPRESSED_TEXTURE_FORMATS give the application a list of formats
that it could ask the driver to compress with some expectation of
quality. The GL_ARB_texture_compression spec calls this "suitable for
general-purpose usage." As noted above, this means
GL_COMPRESSED_RGBA_S3TC_DXT1_EXT is not included in the list.
In OpenGL ES, the driver never performs compression.
GL_NUM_COMPRESSED_TEXTURE_FORMATS and GL_COMPRESSED_TEXTURE_FORMATS give
the application a list of formats that the driver can receive from the
application. It is the *complete* list of formats. The
GL_EXT_texture_compression_s3tc spec says:
"New State for OpenGL ES 2.0.25 and 3.0.2 Specifications
The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
COMPRESSED_TEXTURE_FORMATS include COMPRESSED_RGB_S3TC_DXT1_EXT,
COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT,
and COMPRESSED_RGBA_S3TC_DXT5_EXT."
Note that the addition is only to the OpenGL ES specification!
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
See-also: http://lists.freedesktop.org/archives/mesa-dev/2013-October/047439.html
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Returning a reference is incorrect if the specified pair was a
temporary -- Instead of that, use decltype() to deduce the correct
return type qualifiers. Fixes a crash in clCreateProgramWithBinary().
Reported-and-tested-by: "Dorrington, Albert" <albert.dorrington@lmco.com>
According to the spec it's allowed to call clBuildProgram() on a
program created from a user-specified binary. We don't need to do
anything to build the program in that case.
Reported-and-tested-by: "Dorrington, Albert" <albert.dorrington@lmco.com>
This avoids the inefficient multiple evaluation of the map result in
the code below. It should cause no functional changes.
Tested-by: "Dorrington, Albert" <albert.dorrington@lmco.com>
From ARB_shader_image_load_store:
If a texture object bound to one or more image units is deleted by
DeleteTextures, it is detached from each such image unit, as though
BindImageTexture were called with <unit> identifying the image unit
and <texture> set to zero.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
And uncomment the relevant lines of the dispatch sanity test.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
v2: Name image format classes consistently, fix array and 3D teximage
selection with layered = GL_FALSE, make sure that the
user-specified layer is less than the number of texture layers,
add some asserts.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Including pack/unpack and texstore code. ARB_shader_image_load_store
requires support for the GL_RG8_SNORM and GL_RG16_SNORM formats, which
map to MESA_FORMAT_SIGNED_GR88 and MESA_FORMAT_SIGNED_GR1616 on
little-endian hosts, and MESA_FORMAT_SIGNED_RG88 and
MESA_FORMAT_SIGNED_RG1616 respectively on big-endian hosts -- only the
former were already present, add support for the latter.
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Including pack/unpack and texstore code. This texture format is a
requirement for ARB_shader_image_load_store.
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
v2: Increase MAX_IMAGE_UNITS to what i965 wants and add a separate
MAX_IMAGE_UNIFORMS define, clarify a couple of comments.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
And to check if it can have layers at all. This will be used by the
implementation of ARB_shader_image_load_store.
v2: Fix constness of texobj argument, use assert and return reasonable
default rather than calling unreachable() in default switch case.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The temporary variable used to store _ColorDrawBufferIndexes must be
signed (GLint), otherwise the following conditional will be incorrectly
evaluated. Leading to crashes in the driver/mesa or accessing/writing
to arbitrary memory location. The bug dates back to 2009.
Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
_ColorDrawBufferIndexes is defined as GLint* and using a GLuint*
will result in the first part of the conditional to be evaluated to
true always.
Unintentionally introduced by the following commit, this will result
in a driver segfault if one is using an old version of the piglit test
bin/clearbuffer-mixed-format -auto -fbo
commit 03d848ea10
Author: Marek Olšák <marek.olsak@amd.com>
Date: Wed Dec 4 00:27:20 2013 +0100
mesa: fix interpretation of glClearBuffer(drawbuffer)
This corresponding piglit tests supported this incorrect behavior instead of
pointing at it.
Cc: Marek Olšák <marek.olsak@amd.com>
Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
If it wasn't necessary for Haswell, it's likely not to be necessary for
Broadwell either.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We need to disable HiZ for non-8x4 aligned levels, except for level 0, layer
0. For the very first layer we can adjust Width and Height fields of
3DSTATE_DEPTH_BUFFER to make it aligned.
Specifically, add ILO_TEXTURE_HIZ and set the flag only for properly aligned
levels. ilo_texture_can_enable_hiz() is updated to check for the flag.
In tex_layout_validate(), align the depth bo to 8x4 so that we can adjust
Width/Height of 3DSTATE_DEPTH_BUFFER without introducing out-of-bound access.
Finally in rectlist blitter, add the ability to adjust 3DSTATE_DEPTH_BUFFER.
Add tex_layout_init_hiz() before tex_layout_init_format() to decide whether
HiZ should be enabled.
On GEN6, because of layer offsetting, HiZ is enabled only when the texture is
non-mipmapped and non-array. PIPE_USAGE_STAGING is also taken as a hint to
disable HiZ.
These can't use foreach_list since they want to skip over the first few
list elements. Just doing the ad-hoc list walking isn't too bad.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
When handling function calls, we often want to walk through the list of
formal parameters and list of actual parameters at the same time.
(Both are guaranteed to be the same length.)
Previously, we used a pattern of:
exec_list_iterator 1st_iter = <1st list>.iterator();
foreach_iter(exec_list_iterator, 2nd_iter, <2nd list>) {
...
1st_iter.next();
}
This was awkward, since you had to manually iterate through one of
the two lists.
This patch introduces a foreach_two_lists macro which safely walks
through two lists at the same time, so you can simply do:
foreach_two_lists(1st_node, <1st list>, 2nd_node, <2nd list>) {
...
}
v2: Rename macro from foreach_list2 to foreach_two_lists, as suggested
by Ian Romanick.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Formal function parameters are always ir_variable objects, not an
arbitrary ir_instruction. So there's no need to dynamically cast here.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
A function call's parameters are always rvalues. ir_rvalue may not
always be a subclass of ir_instruction in the future, so we should use
the right one.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
foreach_iter and exec_list_iterators have been deprecated for some time now;
we just hadn't ever bothered to convert code to the newer foreach_list
and foreach_list_safe macros.
In these cases, we aren't editing the list, so we can use foreach_list
rather than foreach_list_safe.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Prior to this patch, if we ran out of aperture space during
brw_try_draw_prims(), we would rewind the batch buffer pointer
(potentially throwing some state that may have been emitted by
brw_upload_state()), flush the batch, and then try again. However, we
wouldn't reset the dirty bits to the state they had before the call to
brw_upload_state(). As a result, when we tried again, there was a
danger that we wouldn't re-emit all the necessary state. (Note: prior
to the introduction of hardware contexts, this wasn't a problem
because flushing the batch forced all state to be re-emitted).
This patch fixes the problem by leaving the dirty bits set at the end
of brw_upload_state(); we only clear them after we have determined
that we don't need to rewind the batch buffer.
Cc: 10.0 9.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
An example why it is required:
Let's say there's a fragment shader writing to gl_FragData[0..1].
The user calls: glDrawBuffers(2, {GL_NONE, GL_COLOR_ATTACHMENT0});
That means gl_FragData[0] is unused and gl_FragData[1] is written
to GL_COLOR_ATTACHMENT0.
st/mesa was skipping the GL_NONE draw buffer, therefore gl_FragData[0]
was written to GL_COLOR_ATTACHMENT0, which was wrong.
This commit fixes it, but drivers must also be fixed not to crash when
binding NULL colorbuffers. There is also a new set of piglit tests for this.
The MSAA state also had to be fixed not to crash when reading fb->cbufs[0].
Reviewed-by: Brian Paul <brianp@vmware.com>
yInverted is used by EGL_NOK_texture_from_pixmap to indicate that
window system rendering is y-inverted compared to OpenGL texture
representation. This extension is only known to be used with X11
window system where sane default is GL_TRUE.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73371
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
dri2_add_config makes decisions based on NOK_texture_from_pixmap so
it needs to be enabled before calling dri2_add_configs_for_visuals.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Piglit was recently changed to expect the correct error code (piglit
commit 271b998), so it started failing on Mesa. This corrects that
failing and adds some spec quotations to justify the errrors set.
The code was rearranged a little bit to match the order listed in the
spec.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
brw_queryobj.c needs a version of write_timestamp that works on all
generations for the QueryCounter() driver hook. So there's no point in
duplicating it in gen6_queryobj.c.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, Mesa enforced the following rule (from
ARB_geometry_shader4's list of criteria for framebuffer completeness):
* If any framebuffer attachment is layered, all attachments must have
the same layer count. For three-dimensional textures, the layer count
is the depth of the attached volume. For cube map textures, the layer
count is always six. For one- and two-dimensional array textures, the
layer count is simply the number of layers in the array texture.
{ FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB }
However, when ARB_geometry_shader4 was adopted into GL 3.2, this rule
was dropped; GL 3.2 permits different attachments to have different
layer counts. This patch brings Mesa in line with GL 3.2.
In order to ensure that layered clears properly clear all layers, we
now have to keep track of the maximum number of layers in a layered
framebuffer.
Fixes the following piglit tests in spec/!OpenGL 3.2/layered-rendering:
- clear-color-all-types 1d_array mipmapped
- clear-color-all-types 1d_array single_level
- clear-color-mismatched-layer-count
- framebuffer-layer-count-mismatch
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
From section 4.4.4 (Framebuffer Completeness) of the GL 3.2 spec:
If any framebuffer attachment is layered, all populated
attachments must be layered. Additionally, all populated color
attachments must be from textures of the same target.
We weren't checking that the attachments were from textures of the
same target.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Commit 1a92881 added extra flushes to fix a HiZ hang in
WebGL Google Maps. With the extra flushes emitted by the previous two
patches, the flushes added by 1a92881 are redundant.
Tested with the same criteria as in 1a92881: by zooming in and out
continuously for 2 hours on Sandybridge Chrome OS (codename
Stumpy) without a hang.
CC: Kenneth Graunke <kenneth@whitecape.org>
CC: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Unconditionally set brw->need_workaround_flush at the top of gen6 blorp
state emission.
The art of emitting workaround flushes on Sandybridge is mysterious and
not fully understood. Ken and I believe that
intel_emit_post_sync_nonzero_flush() may be required when switching from
regular drawing to blorp. This is an extra safety measure to prevent
undiscovered difficult-to-diagnose gpu hangs.
I verified that on ChromeOS, pre-patch, need_workaround_flush was not
set at the top of blorp, as Paul expected. To verify, I inserted the
following debug code at the top of gen6_blorp_exec(), restarted the ui,
and inspected the logs in /var/log/ui. The abort gets triggered so early
that the browser never appears on the display.
static void
gen6_blorp_exec(...)
{
if (!brw->need_workaround_flush) {
fprintf(stderr, "chadv: %s:%d\n", __FILE__, __LINE__);
abort();
}
...
}
CC: Kenneth Graunke <kenneth@whitecape.org>
CC: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This patch makes the workaround code in gen6 blorp follow the pattern
established in the regular draw path. It shouldn't result in any
behavioral change.
On gen6, there are two places where we emit 3D_CMD_PRIM: brw_emit_prim()
and gen6_blorp_emit_primitive(). brw_emit_prim() sets
need_workaround_flush immediately after emitting the primitive, but
blorp does not. Blorp sets need_workaround_flush at the bottom of
brw_blorp_exec().
This patch moves the need_workaround_flush from brw_blorp_exec() to
gen6_blorp_emit_primitive(). There is no need to set
need_workaround_flush in gen7_blorp_emit_primitive() because the
workaround applies only to gen6.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
We weren't handling the LUMINANCE_SNORM, LUMINANCE_ALPHA_SNORM and
INTENSITY_SNORM cases. Note that adding these cases here does not
require a driver to support rendering to these surface types. If
the driver can't do it we'll report an incomplete framebuffer.
NVIDIA doesn't support GL_EXT_texture_snorm but their driver
accepts these formats in glRenderBufferStorage().
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This allows the caller to execute it in a loop rather than
hand-rolling a separate call for each stage.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These are replaced with
ctx->Const.Program[MESA_SHADER_{VERTEX,FRAGMENT,GEOMETRY}]. In
patches to follow, this will allow us to replace a lot of ad-hoc logic
with a variable index into the array.
With the exception of the changes to mtypes.h, this patch was
generated entirely by the command:
find src -type f '(' -iname '*.c' -o -iname '*.cpp' -o -iname '*.py' \
-o -iname '*.y' ')' -print0 | xargs -0 sed -i \
-e 's/Const\.VertexProgram/Const.Program[MESA_SHADER_VERTEX]/g' \
-e 's/Const\.GeometryProgram/Const.Program[MESA_SHADER_GEOMETRY]/g' \
-e 's/Const\.FragmentProgram/Const.Program[MESA_SHADER_FRAGMENT]/g'
Suggested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Commit eda21d2a30 fixed the rasterization
of points for Direct3D but ended up breaking the rasterization of OpenGL
non-sprite points, in particular conform's pntrast.c test.
The only way to get both working is to properly honour
pipe_rasterizer::point_quad_rasterization, and follow the weird OpenGL
rule when it is false.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We definitely want to fall through to the unsynchronized map case, instead
of wasting bandwidth on a copy. Prevents a -43.2407% +/- 1.06113% (n=49)
performance regression on aa10perf when teaching glamor to provide the
GL_INVALIDATE_RANGE_BIT information.
This is a performance fix, which I usually wouldn't cherry-pick to stable.
But this was really was just a bug in the code, its presence would
discourage developers from giving us the best information they can, and I
think we've got fairly high confidence in the unsynchronized map path
already.
Cc: 10.0 9.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
While incorrect, it probably wouldn't affect anyone ever: You'd have to do
an appropriately-formatted readpixels into a PBO, then overwrite the tail
end of the updated area of the PBO with glBufferSubData(), and you
wouldn't get appropriate synchronization.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The earlier assert made sure that our math didn't exceed our bounds, but
this makes sure that we don't overflow from the high bits X into the low
bits of Y. We've already put checks in intel_miptree_blit(), but I've
wanted to expand the type in our protoype from short to uint32_t, and we
could get in trouble with intel_emit_linear_blit() if we did.
v2: Add Ken's comment about the funny language extension used.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> (v1)
This was one of the things we always wanted to do to this, to make it more
useful than just (value << FIELD_MASK).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
With all of the flipping and pitch twiddling and miptree layout involved
in our blits, there are lots of ways for us to scribble outside of a
buffer. Put in a check that we're not about to do so.
This catches a bug that glamor was running into.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This fixes the following compile error:
src\glsl\ir_constant_expression.cpp(1405) : error C2666: 'copysign' : 3
overloads have similar conversions
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Add for now some simple/basic query support (ie. things not actually
requiring the GPU). Might change around a bit when I actually add
GPU queries, but for now this enables some useful performance info
in the GALLIUM_HUD. For example:
GALLIUM_HUD=fps+batches+batches-sysmem+batches-gmem+restores,draw-calls
The driver specific specific queries are:
+ draw-calls
+ batches - number of batches per second, sum of batches-sysmem
plus batches-gmem
+ batches-gmem - render a set of tiles in GMEM, for each tile
(optionally) system mem -> gmem (restore), plus N draws,
plus gmem -> system mem (resolve) per second
+ batches-sysmem - N draws to system memory (GMEM bypass) per
second
+ restores - number of GMEM batches that required restore per
second
Ideally for GMEM rendering, you want batches-gmem to equal fps. If
the app is doing something that triggers multiple passes (ie. requires
extra round trip gmem <-> system memory) then the # of batches per
second will go up relative to fps.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Since we now have the cmdstream patch mechanism needed for hw binning,
might as well also use it for RB_RENDER_CONTROL updates. This avoids
the need to use RMW (and associated WFI) to update RB_RENDER_CONTROL.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The binning pass sorts vertices into which bins/tiles they apply to.
The visibility information generated during the binning pass can be
used to speed up the rendering pass by filtering out vertices which
do not apply to the current tile. See:
https://github.com/freedreno/freedreno/wiki/Adreno-tiling#optimized-approach
This brings a significant fps boost. A rough assortment of tests
(supertuxkart, etracer, tremulous, glmark2 'build' test, etc) seems
to yield a ~35-45% fps improvement.
For now, to be conservative, the binning pass is not enabled yet by
default. To enable it use:
FD_MESA_DEBUG=binning
So far I haven't found anything that breaks with binning enabled,
but I'd like a bit more testing before I enable it as default.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The hardware is broken with nonzero texel offsets and unnormalized
coordinates; instead of doing correct offsetting, we get garbage.
This just extends the existing workaround for ir_txf and
ir_tg4+gsampler2DRect to also consider ir_tex+gsampler2DRect.
Fixes broken rendering in 'tesseract' when 'mesa_texrectoffset_bug' is
not enabled; also fixes the new piglit test
'tests/spec/glsl-1.30/execution/fs-textureOffset-Rect'.
Has been broken ~forever; suggesting including this in only 10.0 because
the lowering pass doesn't exist in 9.2 or earlier so would require quite
a different patch.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Lee Salzman <lsalzman@gmail.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Also rename "shaderType" param of is_varying_var() to "stage".
Reviewed-by: Brian Paul <brianp@vmware.com>
This reduces confusion since gl_shader::Type is sometimes
GL_SHADER_PROGRAM_MESA but is more frequently
GL_SHADER_{VERTEX,GEOMETRY,FRAGMENT}. It also has the advantage that
when switching on gl_shader::Stage, the compiler will alert if one of
the possible enum types is unhandled. Finally, many functions in
src/glsl (especially those dealing with linking) already use
gl_shader_stage to represent pipeline stages; using gl_shader::Stage
in those functions avoids the need for a conversion.
Note: in the process I changed _mesa_write_shader_to_file() so that if
it encounters an unexpected shader stage, it will use a file suffix of
"????" rather than "geom".
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: Split from patch "mesa: Store gl_shader_stage enum in gl_shader objects."
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Also move the related #define MESA_SHADER_STAGES. This will allow
gl_shader_stage to be used in struct gl_shader.
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: Split from patch "mesa: Store gl_shader_stage enum in gl_shader objects."
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: Split from patch "mesa: Store gl_shader_stage enum in gl_shader objects."
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we had an enum called gl_shader_type which represented
pipeline stages in the order they occur in the pipeline
(i.e. MESA_SHADER_VERTEX=0, MESA_SHADER_GEOMETRY=1, etc), and several
inconsistently named functions for converting between it and other
representations:
- _mesa_shader_type_to_string: gl_shader_type -> string
- _mesa_shader_type_to_index: GLenum (GL_*_SHADER) -> gl_shader_type
- _mesa_program_target_to_index: GLenum (GL_*_PROGRAM) -> gl_shader_type
- _mesa_shader_enum_to_string: GLenum (GL_*_{SHADER,PROGRAM}) -> string
This patch tries to clean things up so that we use more consistent
terminology: the enum is now called gl_shader_stage (to emphasize that
it is in the order of pipeline stages), and the conversion functions are:
- _mesa_shader_stage_to_string: gl_shader_stage -> string
- _mesa_shader_enum_to_shader_stage: GLenum (GL_*_SHADER) -> gl_shader_stage
- _mesa_program_enum_to_shader_stage: GLenum (GL_*_PROGRAM) -> gl_shader_stage
- _mesa_progshader_enum_to_string: GLenum (GL_*_{SHADER,PROGRAM}) -> string
In addition, MESA_SHADER_TYPES has been renamed to MESA_SHADER_STAGES,
for consistency with the new name for the enum.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Also rename the "target" field of _mesa_glsl_parse_state and the
"target" parameter of _mesa_shader_stage_to_string to "stage".
Reviewed-by: Brian Paul <brianp@vmware.com>
The adjustment needs to be applied to the y coordinates and not the x
coordinates, just like the equivalent code for lines and triangles in
lp_setup_line.c and lp_setup_tri.c.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
This was inadvertently forgotten when replacing gl_rasterization_rules
with lower_left_origin and half_pixel_center (commit
2737abb44e).
This makes a difference when lower_left_origin != half_pixel_center, e.g,
D3D10.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
When the depth buffer is to be read, perform a Depth Buffer Resolve if it has
been rendered. When the depth buffer is to be rendered, perform a HiZ Buffer
Resolve when the depth buffer is modified externally.
Add blitter functions to perform Depth Buffer Clear, Depth Buffer Resolve, and
Hierarchical Depth Buffer Resolve. Those functions set ilo_blitter up and
pass it to the pipelines to emit the commands.
Allow HiZ op to be specified in 3DSTATE_WM. Pass depth format directly in
gen7_emit_3DSTATE_SF. Use tex->hiz.bo to determine if HiZ exists. Fix
3DSTATE_SF for the case when there is no ilo_rasterizer_state. Fix
3DSTATE_PS for the case when there is no ilo_shader_state.
GEN6 has several requirements regarding the LOD/Depth/Width/Height of the
render targets and the depth buffer. We used to offset to the layers in
question unconditionally to meet the requirements. With this commit,
offseting is done only when the requirements are not met.
On Haswell, POW takes 24 cycles, while EXP2 only takes 14. Plus, using
POW requires putting 2.0 in a register, while EXP2 doesn't.
I believe that EXP2 will be faster than POW on basically all GPUs, so
it makes sense to optimize it.
Looking at the savage2 subset of shader-db:
total instructions in shared programs: 113225 -> 113179 (-0.04%)
instructions in affected programs: 2139 -> 2093 (-2.15%)
instances of 'math pow': 795 -> 749 (-6.14%)
instances of 'math exp': 389 -> 435 (11.8%)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This patch creates a new generic is_value() method, which checks if an
ir_constant has a particular value. (For vectors, it must have the
single value repeated across all components.)
It then rewrites the is_zero/is_one/is_negative_one methods to use this
generic helper. All three were basically identical except for the value
they checked for. The other difference is that is_negative_one rejects
boolean types. The new is_value function maintains this behavior, only
allowing boolean types when checking for 0 or 1.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Using the get_local_param_pointer helper ensures that the LocalParams
arrays have actually been allocated before attempting to use them.
glProgramLocalParameters4fvEXT needs to do a bit of extra checking,
but it can be simplified since the helper has already validated the
target.
Fixes crashes in programs that use Cg (for example, Awesomenauts,
Rocketbirds: Hardboiled Chicken, and Tiny and Big: Grandpa's Leftovers)
since commit e5885c119d
(mesa: Dynamically allocate the storage for program local parameters.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73136
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Laurent Carlier <lordheavym@gmail.com>
We don't support MSAA (ie, number of samples is always one) therefore
sample_mask boils down to a synonym of the rasterizer_discard flag.
Also, this change makes setup actually use the value received in
lp_setup_set_rasterizer_discard instead of reaching out to llvmpipe
upper layers to re-fetch it.
Based on Si Chen's draft.
With this patch `wgf11multisample Coverage passes 100%` on the UMD
D3D10 state tracker.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Si Chen <sichen@vmware.com>
The initial value of cso_context::sample_mask_saved is irrelevant as it
will be overwritten with cso_context::sample_mask in
cso_save_sample_mask. Therefore it is cso_context::sample_mask that
needs to be properly initialized.
This fixes regressions in blits and mipmap generation after adding
support for sample_mask to llvmpipe.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Implement Alpha to Coverage by discarding a fragment alpha component is
less than 0.5. This is a joint work of Jose and Si.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Commit 9119269ca1 moved the texel
buffer allocation to _swrast_texture_span(), however, when compiled
with OpenMP support this code already runs multi-threaded so a
critical section is required to prevent multiple allocations and
rendering errors.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Evidently, there's some other definition of "min" and "max" that
causes MSVC to choke on these function names. Renaming to min2()
and max2() fixes things.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Both brw_defines.h and intel_reg.h defined PIPE_CONTROL fields, which
had similar names, but couldn't be used in the same way. (One had
built-in shifts, and the other didn't...)
Delete the unused set to preserve sanity.
(Eric wrote an almost identical patch back in August, so I believe he
approves.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This patch fixes this build error with gcc <= 4.5 and clang <= 3.1.
CC clientattrib.lo
In file included from ../../include/GL/glx.h:333:0,
from glxclient.h:45,
from clientattrib.c:32:
../../include/GL/glxext.h:275:13: error: redefinition of typedef 'GLXContextID'
../../include/GL/glx.h:171:13: note: previous declaration of 'GLXContextID' was here
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70591
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* The Haiku renderers need to link to libGL to function properly
in all usage contexts. As mesa drivers build before gallium
targets, we couldn't properly link the mesa swrast driver to
the gallium libGL target for Haiku.
* This is likely better as it mimics how glx is laid out ensuring
the Haiku libGL is better understood.
* All renderers properly link in libGL now.
Acked-by: Brian Paul <brianp@vmware.com>
These are just software flag values (not hardware specific values), and
aren't used anywhere. Delete them to avoid confusion.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Add extra null check in auto generated indirect_init.c via
src/mapi/glapi/gen/glX_proto_send.py
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Previously we left the size of this vgrf as 1, which caused register
allocation to be subtly broken. If we were lucky we would explode in
the post-alloc instruction scheduler; if we were unlucky we'd just stomp
on someone else and get broken rendering.
Fixes crash when running `tesseract` with the following settings:
msaa 4
glineardepth 0
Also fixes the piglit test:
arb_sample_shading-builtin-gl-sample-id
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72859
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The preprocessor currently accepts multiple else/elif-groups
per if-section. The GLSL-preprocessor is defined by the C++
specification, which defines the following parse-rule:
if-section:
if-group elif-groups(opt) else-group(opt) endif-line
This clearly only allows a single else-group, that has to come
after any elif-groups.
So let's modify the code to follow the specification. Add test
to prevent regressions.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Carl Worth <cworth@cworth.org>
Cc: 10.0 <mesa-stable@lists.freedesktop.org>
The preprocessor has always replaced multi-line comments with a single space
character, (as required by the specification), but as of commit
bd55ba568b the lexer also emitted a NEWLINE
token for each newline within the comment, (in order to preserve line
numbers).
The emitting of NEWLINE tokens within the comment broke the rule of "replace a
multi-line comment with a single space" as could be exposed by code like the
following:
#define FOO a/*
*/b
FOO
Prior to commit bd55ba568b, this code defined
the macro FOO as "a b" as desired. Since that commit, this code instead
defines FOO as "a" and leaves a stray "b" in the output.
In this commit, we fix this by not emitting the NEWLINE tokens while lexing
the comment, but instead merely counting them in the commented_newlines
variable. Then, when the lexer next encounters a non-commented newline it
switches to a NEWLINE_CATCHUP state to emit as many NEWLINE tokens as
necessary (so that subsequent parsing stages still generate correct line
numbers).
Of course, it would have been more clear if we could have written a loop to
emit all the newlines, but flex conventions prevent that, (we must use
"return" for each token we emit).
It similarly would have been clear to have a new rule restricted to the
<NEWLINE_CATCHUP> state with an action much like the body of this if
condition. The problem with that is that this rule must not consume any
characters. It might be possible to write a rule that matches a single
lookahead of any character, but then we would also need an additional rule to
ensure for the <EOF> case where there are no additional characters available
for the lookahead to match.
Given those considerations, and given that the SKIP-state manipulation already
involves a code block at the top of the lexer function, before any rules, it
seems best to me to go with the implementation here which adds a similar
pre-rule code block for the NEWLINE_CATCHUP.
Finally, this commit also changes the expected output of a few, existing glcpp
tests. The change here is that the space character resulting from the
multi-line comment is now emitted before the newlines corresponding to that
comment. (Previously, the newlines were emitted first, and the space character
afterward.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72686
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Two things make this code confusing:
1. The uncharacteristic manipulation of lexer start state outside of
flex rules.
2. The confusing semantics of the skip_stack (including the
"lexing_if" override and the SKIP_NO_SKIP state).
This new comment is intended to bring a bit more clarity for any readers.
There is no intended beahvioral change to the code here. The actual code
changes include better indentation to avoid an excessively-long line, and
using the more descriptive INITIAL rather than 0.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Support all levels of a supported texture format.
Using 1024x1024, RGBA 8888 source, mipmap
internal-format Before (MB/sec) mipmap (MB/sec)
GL_RGBA 627.15 615.90
GL_RGB 456.35 611.53
512x512
GL_RGBA 597.00 619.95
GL_RGB 440.62 611.28
256x256
GL_RGBA 487.80 587.42
GL_RGB 376.63 585.00
Benchmark has been sent to mesa-dev list: teximage_enh
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
MESA_FORMAT_XRGB8888 is equivalent to MESA_FORMAT_ARGB8888 in terms
of storage on the device, so okay to use this optimized copy routine.
This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_8888 and full miptrees where were found to be common activities
in the Smokin' Guns game. The issue was found while profiling the app
but that part is not benchmarked. Smokin-Guns uses mipmap textures with
an internal format of GL_RGB (MESA_XRGB_8888 in the driver).
These changes need a performance tool to run against to show how they
improve execution performance for specific texture formats. Using this
benchmark I've measured the following improvement on my Ivybridge
Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.
1024x1024 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 628.15 627.15
GL_RGB 265.95 456.35
512x512 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 600.23 597.00
GL_RGB 255.50 440.62
256x256 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 489.08 487.80
GL_RGB 229.03 376.63
Benchmark has been sent to mesa-dev list: teximage
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Only a Mesa bug could cause this function to be called with an
out-of-range index, so raise an assertion if that ever happens.
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch replaces the following pattern:
foo bar[MESA_SHADER_TYPES] = {
...
};
With:
foo bar[] = {
...
};
STATIC_ASSERT(Elements(bar) == MESA_SHADER_TYPES);
This way, when a new shader type is added in a future version of Mesa,
we will get a compile error to remind us that the array needs to be
updated.
Reviewed-by: Brian Paul <brianp@vmware.com>
This argument was carrying the name of the shader target (as a
string). We can get this just as easily by calling
_mesa_shader_enum_to_string().
Reviewed-by: Brian Paul <brianp@vmware.com>
Previously, _mesa_glsl_shader_target_name() had an overload for GLenum
and an overload for the gl_shader_type enum, each of which behaved
differently. However, since GLenum is a synonym for unsigned int, and
unsigned ints are often used in place of gl_shader_type (e.g. in loop
indices), there was a big risk of calling the wrong overload by
mistake. This patch gives the two overloads different names so that
it's always clear which one we mean to call.
Reviewed-by: Brian Paul <brianp@vmware.com>
This reverts commit 136a12ac98.
According to belak51 on IRC, this commit broke Allegro, which would no
longer compile. Applications apparently expect the GLXContextID typedef
to exist in glx.h; removing it breaks them. A bit of searching around
the internet revealed other complaints since upgrading to Mesa 10.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
According to git blame, this hasn't been used in over two years:
commit d2235b0f46
Author: Eric Anholt <eric@anholt.net>
Date: Thu Nov 17 17:01:58 2011 -0800
i965: Always handle GL_DEPTH_TEXTURE_MODE through the shader.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
instead of ignoring the argument and always dumping to
standard output.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Using RMW on banked context registers is not safe. The value read
could be the wrong one. So if there has been a DRAW_IDX launched,
the RMW must be preceded by a WAIT_FOR_IDLE to ensure the read part
of RMW sees the correct value.
To avoid unnecessary WFI's, keep track if there is a need for WFI,
and only emit one if needed. Furthermore, keep track if we even
need to update the register in the first place.
And to cut down on the amount of RMW to avoid excessive WFI's, at the
tiling/GMEM level we can always overwrite RB_RENDER_CONTROL, as the
state at beginning of draw/clear cmds (which we IB to) is always
undefined. In the draw/clear commands, we always still use RMW (with
WFI if needed), but only if the register value actually changes. (At
points where the current value cannot be known, the saved value is
reset to ~0, which includes bits outside of RBRC_DRAW_STATE, so there
never is chance for confusion.)
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Actually assign VSC_PIPE's properly, which will be needed for tiling.
And introduce fd_tile for per-tile state (including the assignment of
tile to VSC_PIPE). This gives us the proper pipe setup that we'll
need for hw binning pass, and also cleans things up a bit by not having
to pass so many parameters around. And will also make it easier to
introduce different tiling patterns (since we may no longer render
tiles in a simple left-to-right top-to-bottom pattern).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Previously we were creating a new LLVMContext every time that we called
radeon_llvm_parse_bitcode, which caused us to leak the context every time
that we compiled a CL program.
Sadly, we can't dispose of the LLVMContext at the point that it was being
created because evergreen_launch_grid (and possibly the SI equivalent) was
assuming that the context used to compile the kernels was still available.
Now, we'll create a new LLVMContext when creating EG/SI compute state, store
it there, and pass it to all of the places that need it.
The LLVM Context gets destroyed when we delete the EG/SI compute state.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
CC: "10.0" <mesa-stable@lists.freedesktop.org>
This fixes a crash where old_view->context was already freed in the
pipe_sampler_view_reference function contained in
src/gallium/auxiliary/utils/u_inlines.h. As a result, the
sampler_view_destroy function pointer contained 0xfeeefeee indicating
freed heap memory.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Every driver supports it. All current and future Gallium drivers always
support it, and all existing classic drivers support it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Useful in its own right, but also needed for adaptive vsync.
No regressions in the piglit glx-oml-sync-control-getmscrate test.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
It is the maximum number of back buffers, but the name is confusing and is
easily read as the maximum back buffer index. Chage to DRI3_NUM_BACK to make
the intended usage a bit clearer.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Just copying code from the dri2 path to set up the fast color clear state.
This also removes a couple of bogus intel_region_reference calls.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Move the depth field up with width and height.
Remove unused previous_time and frames fields.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
works when the fence is a linux futex. However, version 1.1
changes the exported datatype to 'struct xshmfence *'
Require libxshmfence version 1.1 and switch the API around.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
While looking through the documentation, I found this in the Sandybridge
PRM (Volume 4, Part 1, Page 140):
"Use of sample_c with SURFTYPE_CUBE surfaces is undefined with the
following surface formats: I24X8_UNORM, L24X8_UNORM, A24X8_UNORM,
I32_FLOAT, L32_FLOAT, A32_FLOAT."
I haven't observed this to be true, but it suggests that we may want to
use other formats.
We already perform DEPTH_TEXTURE_MODE swizzling in the shaders, and
don't rely on the surface format to splat things appropriately. So
using RED should work just as well as INTENSITY.
A few notes about the formats:
- R24_UNORM_X8_TYPELESS has the exact same properties as I24X8_UNORM.
- R16_UNORM and R32_FLOAT are additionally supported as a render target,
while the old I16_UNORM/I32_FLOAT formats are not.
- R32_FLOAT_X8X24_TYPELESS is not supported as a render target, while
the old format (R32G32_FLOAT) was. However, it shares the same
properties as the formats we use for Z24, so it should suffice.
This makes translate_tex_format and brw_blorp_surface_info::set
a bit more similar.
No Piglit changes on Sandybridge or Ivybridge. No oglconform changes on
Sandybridge.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Emitting flushes before depth and hiz resolves at the top of blorp's
state emission fixes the hang. Marchesin and I found the fix
experimentally, as opposed to adhering to a documented hardware
workaround. A more minimal fix likely exists, but this gets the job
done.
Fixes HiZ hangs in the new WebGL Google maps on Sandybridge Chrome OS.
Tested by zooming in and out continuously for 2 hours.
This patch is based on
8bc07bb701
CC: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70740
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Broadwell allows us to specify an arbitrary value for QPitch, rather
than baking a specific formula into the hardware and requiring software
to lay things out to match. The only restriction is that the software
provided QPitch needs to be large enough so successive array slices do
not overlap.
In order to support this flexibility, software needs to specify QPitch
in a bunch of packets. Storing QPitch makes that easy, and allows us to
adjust it in a single place should we wish to change it in the future.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Broadwell introduces support for Q, UQ, and HF types. It also extends
DF support to allow immediate values.
Irritatingly, although HF and DF both support immediates, they're
represented by a different value depending on the register file.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Ivybridge, Baytrail, and Haswell support double float register types,
but do not support them as immediate values.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
On released hardware, values 4-6 are overloaded. For normal registers,
they mean UB/B/DF. But for immediates, they mean UV/VF/V.
Previously, we just created #defines for each name, reusing the same
value. This meant we could directly splat the brw_reg::type field into
the assembly encoding, which was fairly nice, and worked well.
Unfortunately, Broadwell makes this infeasible: the HF and DF types are
represented as different numeric values depending on whether the
source register is an immediate or not.
To preserve sanity, I decided to simply convert BRW_REGISTER_TYPE_* to
an abstract enum that has a unique value for each register type, and
write translation functions. One nice benefit is that we can add
assertions about register files and generations.
I've chosen not to convert brw_reg::type to the enum, since converting
it caused a lot of trouble due to C++ enum rules (even though it's
defined in an extern "C" block...).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Three-source instructions use a different encoding for register types
(and have a much more limited set to choose from).
Previously, we translated those into BRW_REGISTER_TYPE_* values, then
reused the existing reg_encoding mapping.
Doing it directly is more straightforward and actually less code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
UB types have never been supported as immediates. On Gen4-5, register
encoding 4 is "Reserved." On Gen6+, it means UV.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Calling the local variables flat_enable and point_sprite_enable is
clearer than dw16 and such. It also matches the names used in
calculate_attr_overrides, which computes them.
v2: Add /* dw16 */ and /* dw10 */ comments, requested by Jordan.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
calculate_attr_overrides is responsible for computing the point sprite
and flat-shading enable bitfields. It does so by OR'ing in a bunch of
bits. However, it relied on the caller to set the initial value to
zero. This is pretty fragile - if the caller neglects to zero out those
variables, then the enable bitfields end up full of garbage, which shows
up as random things being flat-shaded.
This patch moves the zero-initialization into calculate_attr_overrides,
so that the computation is completely in one place.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git blame ascribes this to the initial commit of the driver.
No released hardware has ever supported half float, according to the
documentation for SrcType in the ISA reference.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
If no function signature is found for a function name, report that the
function is not found instead of printing an empty list of candidates.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch changes the error reporting behavior for incorrect function
invocation (triggered by match_function_by_name() unable to find a
matching function call) from using the line number information
associated to the function name term to using the line number
information of the entire function expression. Fixes bug #72264.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72264
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
For GLSL 1.50 we can get frag shaders with primitive id as an
input, add support to the translator for this.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In load_texunit_bumpmap tc_array is asserted so lets assert
rot_mat_0 and rot_mat_1 also which are coming from same path.
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Check for malloc() returning null to fix Klocwork warnings.
Minor clean-ups by BrianP.
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The GL_RGB32F, GL_RGB32UI and GL_RGB32I texture buffer formats are
only supposed to be allowed if the GL_ARB_texture_buffer_object_rgb32
extension is supported. Note that the texture buffer extensions
require a core profile. This patch adds those checks.
Fixes the soon-to-be-added
arb_clear_buffer_object-negative-bad-internalformat piglit test.
Add function to test if the buffer is already mapped and if so,
if the mapped range overlaps the given range.
Modify the _mesa_InvalidateBufferSubData function to use
the new function.
Enable buffer_object_subdata_range_good() to use bufferobj_range_mapped
Reviewed-by: Brian Paul <brianp@vmware.com>
alpha, lumincance and intensity formats are illegal in a core context.
Add a check to return MESA_FORMAT_NONE if one of those is requested within
a core context.
Reviewed-by: Brian Paul <brianp@vmware.com>
- change storage class from static to extern
- rename validate_texbuffer_format to _mesa_validate_texbuffer_format
Reviewed-by: Brian Paul <brianp@vmware.com>
- add xml file for extension
- add reference in gl_API.xml
- add pointer to device driver function table (dd.h)
- update dispatch_sanity.cpp
Reviewed-by: Brian Paul <brianp@vmware.com>
Specs say it's legal for implementations to use internal copies, and
the write synchronization seems to work. Fixes clCreateBuffer
(together with previous patches) and buffer-flags piglits.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Acked-by: Francisco Jerez <currojerez@riseup.net>
v2: Use fewer if statements and functional tricks instead of single-use method,
suggested by Francisco Jerez.
Squash two small patches into one.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
When LLVM is build with Clang, "llvm-config --cxxflags" contains the
-fcolor-diagnostics flag. It is not recognized by gcc and the build
fails. Fix by removing the flag.
Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Brian Paul <brianp@vmware.com>
The dri2 state tracker is checking for driver support before enabling
dri2ImageExtension version 7. This commit adds a check that also the
kernel driver supports fd sharing through prime.
Note that this adds a libdrm dependency on dri2.c.
v2: Removed unnecessary clamping of bool expression
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
This will avoid compiler warnings in the patch that follows. There
should be no user-visible effect because the change only affects the
behaviour when an invalid enum is passed to
_mesa_shader_type_to_index(), and that can only happen if there is a
bug elsewhere in Mesa.
Reviewed-by: Brian Paul <brianp@vmware.com>
All this cruft was ported from r600g and isn't needed on SI and later
according to hw docs. If we implemented HiS, we would set it to 0.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Replicate some of the gallium pipe transfer functionality.
Also bump minor to signal availability of this feature.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
* These make up the base of what C++ GL Haiku applications
use for 3D rendering.
* Not placed in includes/GL to prevent Haiku headers from
getting installed on non-Haiku systems.
Acked-by: Brian Paul <brianp@vmware.com>
This fixes MSAA resolving for 32-bit integer colorbuffers, which isn't
implemented by the hardware.
It also fixes VM protection faults when resolving MSAA 2D array textures.
This may be a CB bug, because shader-based resolving works fine.
It may also be faster for upside-down and scaled blits.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
For scaled resolve. The filter is only good for magnification.
If somebody has an idea how to implement a good filter for minification,
I'm all ears. I'd have to use derivatives probably.
Reviewed-by: Brian Paul <brianp@vmware.com>
We need this for integer formats and upside-down blits, which Radeons don't
support for MSAA resolving.
It can be used by calling util_blitter_blit.
Reviewed-by: Brian Paul <brianp@vmware.com>
The argument is a i8 pointer not a i32 pointer (even though the value actually
stored/loaded IS i32). Older llvm versions didn't care but 3.2 and newer do
leading to crashes.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Didn't really work as well as hoped (in particular it was not generally
more accurate), will solve this differently.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This code was always problematic, and with 64bit rasterization we no longer
need it at all.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The target parameter to _mesa_get_tex_image() is a target enum, not an index.
When we're setting up faces for a cubemap, it should be
CUBE_MAP_POSITIVE_X .. CUBE_MAP_NEGATIVE_Z; for all other targets it
should be the same as the texobj's target.
Fixes broken cubemaps [had only +X face but claimed to have all] produced by
glTextureView, which then caused various crashes in the driver when we
tried to use them.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: - add assert so we don't run into trouble on Gen6.
- adjust for Tapani's rearrangement of ir_variable
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The GL_ARB_shadow spec says the shadow compare mode should have no
effect when sampling a color texture. As it was, it was up to
drivers to check for that (softpipe, llvmpipe, svga and probably
the rest don't do that). Note: it looks like DX10 allows shadow
compare with some non-depth formats, so this case really should be
handled in the state tracker.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Depending on the depth texture format, we may or may not have to
emit explicit fs code to do the shadow comparison. Before, we
were emitting it more often than needed.
v2: check the actual texture format rather than the screen->depth.z16
field. The screen->depth.z16, x8z24, s8z24 fields may not all be set
to a consistent set of depth formats.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Call TextureView helper function to set TextureView state
appropriately for the TexStorage calls.
Misc updates from review feedback.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Add helper function to set texture_view state from TexStorage calls.
Include review feedback.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Add Mesa TextureView logic.
Incorporate feedback on ARB_texture_view:
- Add S3TC VIEW_CLASSes to compatibility table
- Use existing _mesa_get_tex_image
- Clean up error strings
- Use bool instead of GLboolean for internal functions
- Split compound level & layer test into individual tests
- eliminate helper macro for VIEW_CLASS table
- do not call driver if ptr null.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Refactor to make next_mipmap_level_size defined in mipmap.c a
_mesa_ helper function that can then be used by texture_view
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Add support for ARB_texture_view get parameters:
GL_TEXTURE_VIEW_MIN_LEVEL
GL_TEXTURE_VIEW_NUM_LEVELS
GL_TEXTURE_VIEW_MIN_LAYER
GL_TEXTURE_VIEW_NUM_LAYERS
Incorporate feedback regarding when to allow query of
GL_TEXTURE_IMMUTABLE_LEVELS.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Add state needed by glTextureView to the gl_texture_object.
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Stub in glTextureView API call to go with the
glTextureView API xml definition.
Includes dispatch test for glTextureView
Signed-off-by: Courtney Goeltzenleuchter <courtney@LunarG.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch changes the error condition to satisfy below statement
from OpenGL 4.3 core specification:
"An INVALID_OPERATION error is generated if id is the name of a query
object with a target other SAMPLES_PASSED, ANY_SAMPLES_PASSED, or
ANY_SAMPLES_PASSED_CONSERVATIVE, or if id is the name of a query
currently in progress."
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
I'm not sure why this change is necessary. When I've built previous tar files
(such as 9.2.4) with the "make tarballs" target, they include the
bin/test-driver file. But at my first attempt to build the tar files for the
10.0.1 release this file was not being included and the build failed.
(cherry picked from commit d573899b93)
[The cherry pick is because I original applied this on the 10.0 branch while
working on the 10.0.1 release. But if we don't have this on master as well,
this issue will trip us up again the next time we make a new major-release
branch off of master.]
The driverPrivate pointer is opaque to the driver and we can't assume
it's a struct gl_context in dri_util.c. Instead provide a helper function
to set the struct gl_context flags from the incoming DRI context flags.
v2 (idr): Modify the other classic drivers to also use
driContextSetFlags. I ran all the piglit GLX_ARB_create_context tests
with i965 and classic swrast without regressions.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu> [v1 on Gallium nouveau]
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
This patches add MESA_copy_sub_buffer support to the dri sw loader and
then to gallium state tracker, llvmpipe, softpipe and other bits.
It reuses the dri1 driver extension interface, and it updates the swrast
loader interface for a new putimage which can take a stride.
I've tested this with gnome-shell with a cogl hacked to reenable sub copies
for llvmpipe and the one piglit test.
I could probably split this patch up as well.
v2: pass a pipe_box, to reduce the entrypoints, as per Jose's review,
add to p_screen doc comments.
v3: finish off winsys interfaces, add swrast classic support as well.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
swrast: add support for copy_sub_buffer
Required for glClearBuffer, which only clears one colorbuffer attachment.
Example:
If the first colorbuffer is float and the second one is int:
pipe->clear(pipe, PIPE_CLEAR_COLOR0, float_clear_color, ...);
pipe->clear(pipe, PIPE_CLEAR_COLOR1, int_clear_color, ...);
This doesn't need any driver changes yet, because all drivers just use:
if (flags & PIPE_CLEAR_COLOR) ..
The drivers which support GL 3.0 will have to implement it properly though.
This adds 2 optimizations for radeonsi:
- handling of DISCARD_RANGE
- mapping an uninitialized buffer range is automatically UNSYNCHRONIZED
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christoph Brill <egore911@gmail.com>
v2: Renamed r600_buffer.c to r600_buffer_common.c. The stupid build system
doesn't allow 2 files of the same name in different directories.
If we assume that all buffers allocated by the DDX are scanout, a new flag
that says "this is not scanout" has to be added to support the non-scanout
buffers and maintain backward compatibility.
This fixes bad rendering on Wayland.
The flag is defined as:
#define RADEON_TILING_R600_NO_SCANOUT RADEON_TILING_SWAP_16BIT
AFAIK, RADEON_TILING_SWAP_16BIT is not used on SI.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Patch copies the whole data structure at once instead of
assigning individual variables.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This patch moves following bitfields and variables to the data
structure:
explicit_location, explicit_index, explicit_binding, has_initializer,
is_unmatched_generic_inout, location_frac, from_named_ifc_block_nonarray,
from_named_ifc_block_array, depth_layout, location, index, binding,
max_array_access, atomic
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This patch moves following bitfields in to the data structure:
used, assigned, how_declared, mode, interpolation,
origin_upper_left, pixel_center_integer
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Data section helps serialization and cloning of a ir_variable. This
patch includes the helper bits used for read only ir_variables.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Newer virtual HW versions support smooth/stipple/wide lines.
Use that instead of 'draw' fallbacks when possible.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
With this patch llvmpipe will adhere to the ARB_depth_clamp enabled state when
clamping the fragment's zw value. To support this, the variant key now includes
the depth_clamp state. key->depth_clamp is derived from pipe_rasterizer_state's
(depth_clip == 0), thus depth clamp is only enabled when depth clip is disabled.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
On evergreen we have to reserve 1 stack element in some additional cases
besides the ones mentioned in the docs, but stack size computation was
recently reimplemented exactly as described in the docs by the patch that
added workarounds for stack issues on EG/CM, resulting in regressions
with some apps (Serious Sam 3).
This patch fixes it by restoring previous behavior.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=72369
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Tested-by: Andre Heider <a.heider@gmail.com>
Caching in the vbuf module meant that once a vertex has been
emitted it was cached, but it's possible for a vertex at the
same location to be emitted again, but this time with a different
front-face semantic. Caching was causing the first version of the
vertex to be emitted, which resulted in the renderer getting
incorrect front-face attributes. By reseting the vertex_id (which
is used for caching) we make sure that once a front-face info
has been injected the vertex will endup getting emitted.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The fact that we flush denorms to zero breaks our half-float
conversion and blending. This patches enables denorms for
blending. It's a little tricky due to the llvm bug that makes
it incorrectly reorder the mxcsr intrinsics:
http://llvm.org/bugs/show_bug.cgi?id=6393
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Zack Rusin <zackr@vmware.com>
v2: Fix up queryImage return for ATTRIB_FD
Use driver_descriptor.configuration to determine whether the driver
supports DMA-BUF import/export.
v3: Really, truly, fix up queryImage return for ATTRIB_FD
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
First off, nv50_program only has 16 in/out varyings. However reporting
16 makes 'm' become 68 in nv50_fp_linkage_validate with the
varying-packing-simple piglit test. (Subverting the assert makes it
compile but fail.) With this patch, varying-packing-simple passes.
See: https://bugs.freedesktop.org/show_bug.cgi?id=69155
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 10.0" <mesa-stable@lists.freedesktop.org>
To help the transition period when DRI loaders are being updated
to support the newer __driDriverExtensions_foo mechanism,
we populate __driDriverExtensions with the extensions returned
by __driDriverExtensions_foo during a library contructor
function.
We find the driver foo's name by using the dladdr function
which gives the path of the dynamic library's name that
was being loaded.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
The _EGLSurface struct which is embedded into dri2_egl_surface also contains a
swap interval member so the other member is redundant. Nothing was using it as
far as I can tell.
On Gen4+, OUT_RELOC_FENCED is equivalent to OUT_RELOC; libdrm silently
ignores the fenced flag:
/* We never use HW fences for rendering on 965+ */
if (bufmgr_gem->gen >= 4)
need_fence = false;
Thanks to Eric for noticing this.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that loop_controls no longer creates normatively bound loops,
there is no need for ir_loop::normative_bound or the
lower_bounded_loops pass.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, when loop_controls analyzed a loop and found that it had a
fixed bound (known at compile time), it would remove all of the loop
terminators and instead set the loop's normative_bound field to force
the loop to execute the correct number of times.
This made loop unrolling easy, but it had a serious disadvantage.
Since most GPU's don't have a native mechanism for executing a loop a
fixed number of times, in order to implement the normative bound, the
back-ends would have to synthesize a new loop induction variable. As
a result, many loops wound up having two induction variables instead
of one. This caused extra register pressure and unnecessary
instructions.
This patch modifies loop_controls so that it doesn't set the loop's
normative_bound anymore. Instead it leaves one of the terminators in
the loop (the limiting terminator), so the back-end doesn't have to go
to any extra work to ensure the loop terminates at the right time.
This complicates loop unrolling slightly: when deciding whether a loop
can be unrolled, we have to account for the presence of the limiting
terminator. And when we do unroll the loop, we have to remove the
limiting terminator first.
For an example of how this results in more efficient back end code,
consider the loop:
for (int i = 0; i < 100; i++) {
total += i;
}
Previous to this patch, on i965, this loop would compile down to this
(vec4) native code:
mov(8) g4<1>.xD 0D
mov(8) g8<1>.xD 0D
loop:
cmp.ge.f0(8) null g8<4;4,1>.xD 100D
(+f0) if(8)
break(8)
endif(8)
add(8) g5<1>.xD g5<4;4,1>.xD g4<4;4,1>.xD
add(8) g8<1>.xD g8<4;4,1>.xD 1D
add(8) g4<1>.xD g4<4;4,1>.xD 1D
while(8) loop
(notice that both g8 and g4 are loop induction variables; one is used
to terminate the loop, and the other is used to accumulate the total).
After this patch, the same loop compiles to:
mov(8) g4<1>.xD 0D
loop:
cmp.ge.f0(8) null g4<4;4,1>.xD 100D
(+f0) if(8)
break(8)
endif(8)
add(8) g5<1>.xD g5<4;4,1>.xD g4<4;4,1>.xD
add(8) g4<1>.xD g4<4;4,1>.xD 1D
while(8) loop
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This value is now redundant with
loop_variable_state::limiting_terminator->iterations and
ir_loop::normative_bound.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The old logic of loop_unroll_visitor::visit_leave(ir_loop *) was:
heuristics to skip unrolling in various circumstances;
if (loop contains more than one jump)
return;
else if (loop contains one jump) {
if (the jump is an unconditional "break" at the end of the loop) {
remove the break and set iteration count to 1;
fall through to simple loop unrolling code;
} else {
for (each "if" statement in the loop body)
see if the jump is a "break" at the end of one of its forks;
if (the "break" wasn't found)
return;
splice the remainder of the loop into the other fork of the "if";
remove the "break";
complex loop unrolling code;
return;
}
}
simple loop unrolling code;
return;
These tasks have been moved to their own functions:
- splice the remainder of the loop into the other fork of the "if"
- simple loop unrolling code
- complex loop unrolling code
And the logic has been flattened to:
heuristics to skip unrolling in various circumstances;
if (loop contains more than one jump)
return;
if (loop contains no jumps) {
simple loop unroll;
return;
}
if (the jump is an unconditional "break" at the end of the loop) {
remove the break;
simple loop unroll with iteration count of 1;
return;
}
for (each "if" statement in the loop body) {
if (the jump is a "break" at the end of one of its forks) {
splice the remainder of the loop into the other fork of the "if";
remove the "break";
complex loop unroll;
return;
}
}
This will make it easier to modify the loop unrolling algorithm in a
future patch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, the sole responsibility of loop_analysis was to find all
the variables referenced in the loop that are either loop constant or
induction variables, and find all of the simple if statements that
might terminate the loop. The remainder of the analysis necessary to
determine how many times a loop executed was performed by
loop_controls.
This patch makes loop_analysis also responsible for determining the
number of iterations after which each loop terminator will terminate
the loop, and for figuring out which terminator will terminate the
loop first (I'm calling this the "limiting terminator").
This will allow loop unrolling to make use of information that was
previously only visible from loop_controls, namely the identity of the
limiting terminator.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Patches to follow will introduce code into the loop_terminator
constructor. Allocating loop_terminator using new(mem_ctx) syntax
will ensure that the constructor runs.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
When loop_control_visitor::visit_leave(ir_loop *) is analyzing a loop
terminator that acts on a certain ir_variable, it doesn't need to walk
the list of induction variables to find the loop_variable entry
corresponding to the variable. It can just look it up in the
loop_variable_state hashtable and verify that the loop_variable entry
represents an induction variable.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These fields were part of some planned optimizations that never
materialized. Remove them for now to simplify things; if we ever get
round to adding the optimizations that would require them, we can
always re-introduce them.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch replaces the ir_loop fields "from", "to", "increment",
"counter", and "cmp" with a single integer ("normative_bound") that
serves the same purpose.
I've used the name "normative_bound" to emphasize the fact that the
back-end is required to emit code to prevent the loop from running
more than normative_bound times. (By contrast, an "informative" bound
would be a bound that is informational only).
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, all of the back-ends (ir_to_mesa, st_glsl_to_tgsi, and the
i965 fs and vec4 visitors) had nearly identical logic for handling
bounded loops. This replaces the duplicate logic with an equivalent
lowering pass that is used by all the back-ends.
Note: on i965, there is a slight increase in instruction count. For
example, a loop like this:
for (int i = 0; i < 100; i++) {
total += i;
}
would previously compile down to this (vec4) native code:
mov(8) g4<1>.xD 0D
mov(8) g8<1>.xD 0D
loop:
cmp.ge.f0(8) null g8<4;4,1>.xD 100D
(+f0) break(8)
add(8) g5<1>.xD g5<4;4,1>.xD g4<4;4,1>.xD
add(8) g8<1>.xD g8<4;4,1>.xD 1D
add(8) g4<1>.xD g4<4;4,1>.xD 1D
while(8) loop
After this patch, the "(+f0) break(8)" turns into:
(+f0) if(8)
break(8)
endif(8)
because the back-end isn't smart enough to recognize that "if
(condition) break;" can be done using a conditional break instruction.
However, it should be relatively easy for a future peephole
optimization to properly optimize this.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, loop analysis would set
this->conditional_or_nested_assignment based on the most recently
visited assignment to the variable. As a result, if a vaiable was
assigned to more than once in a loop, the flag might be set
incorrectly. For example, in a loop like this:
int x;
for (int i = 0; i < 3; i++) {
if (i == 0)
x = 10;
...
x = 20;
...
}
loop analysis would have incorrectly concluded that all assignments to
x were unconditional.
In practice this was a benign bug, because
conditional_or_nested_assignment is only used to disqualify variables
from being considered as loop induction variables or loop constant
variables, and having multiple assignments also disqualifies a
variable from being considered as either of those things.
Still, we should get the analysis correct to avoid future confusion.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, when visiting an ir_call, loop analysis would only mark
the innermost enclosing loop as containing a call. As a result, when
encountering a loop like this:
for (i = 0; i < 3; i++) {
for (int j = 0; j < 3; j++) {
foo();
}
}
it would incorrectly conclude that the outer loop ran three times.
(This is not certain; if foo() modifies i, then the outer loop might
run more or fewer times).
Fixes piglit test "vs-call-in-nested-loop.shader_test".
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, when visiting a variable dereference, loop analysis would
only consider its effect on the innermost enclosing loop. As a
result, when encountering a loop like this:
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 3; j++) {
...
i = 2;
}
}
it would incorrectly conclude that the outer loop ran three times.
Fixes piglit test "vs-inner-loop-modifies-outer-loop-var.shader_test".
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fast color clears of MSAA buffers work just like fast color clears
with non-MSAA buffers, except that the alignment and scaledown
requirements are different.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This will make it easier to add fast color clear support to MSAA
buffers, since they have different alignment and scaling requirements.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we didn't do multisample blorp clears because we couldn't
figure out how to get them to work. The reason for this was because
we weren't setting the brw_blorp_params num_samples field consistently
with dst.num_samples. Now that those two fields have been collapsed
down into one, we can do multisample blorp clears.
However, we need to do a few other pieces of bookkeeping to make them
work correctly in all circumstances:
- Since blorp clears may now operate on multisampled window system
framebuffers, they need to call
intel_renderbuffer_set_needs_downsample() to ensure that a
downsample happens before buffer swap (or glReadPixels()).
- When clearing a layered multisample buffer attachment using UMS or
CMS layout, we need to advance layer by multiples of num_samples
(since each logical layer is associated with num_samples physical
layers).
Note: we still don't do multisample fast color clears; more work needs
to be done to enable those.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, brw_blorp_params contained two fields for determining
sample count: num_samples (which determined the multisample
configuration of the rendering pipeline) and dst.num_samples (which
determined the multisample configuration of the render target
surface). This was redundant, since both fields had to be set to the
same value to avoid rendering errors.
This patch eliminates num_samples to avoid future confusion.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch renames the enum that's used to keep track of fast clear
state from "mcs_state" to "fast_clear_state", and it removes the enum
value INTEL_MCS_STATE_MSAA (which previously meant, "this is an MSAA
buffer, so we're not keeping track of fast clear state"). The only
real purpose that enum value was serving was to prevent us from trying
to do fast clear resolves on MSAA buffers, and it's just as easy to
prevent that by checking the buffer's msaa_layout.
This paves the way for implementing fast clears of MSAA buffers.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The "layer" parameters used in blorp, and the
intel_renderbuffer::mt_layer field, represent a physical layer rather
than a logical layer. This is important for 2D multisample arrays on
Gen7+ because the UMS and CMS multisample layouts use N physical
layers to represent each logical layer, where N is the number of
samples.
Also add an assertion to blorp to help catch bugs if we fail to follow
these conventions.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Clarify the fact that we only optimize full buffer clears using fast
color clear, and why.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Create the ref_bo without any storage type flags set for now. The issue
probably arises from our use of the additional buffer space at the end
of the ref_bo. It should probably be split up in the future.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Martin Peres <martin.peres@labri.fr>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
With this patch, generate_fs_loop will clamp any fragment shader depth writes
to the viewport's min and max depth values. Viewport selection is determined
by the geometry shader output for the viewport array index. If no index is
specified, then the default viewport index is zero. Semantics for this path
can be found in draw_clamp_viewport_idx and lp_clamp_viewport_idx.
lp_jit_viewport was created to store viewport information visible to JIT code,
and is validated when the LP_NEW_VIEWPORT dirty flag is set.
lp_rast_shader_inputs is responsible for passing the viewport_index through
the rasterizer stage to fragment stage (via lp_jit_thread_data).
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The Wayland EGL platform now respects the eglSwapInterval value. The value is
clamped to either 0 or 1 because it is difficult (and probably not useful) to
sync to more than 1 redraw.
The main change is that if the swap interval is 0 then Mesa won't install a
frame callback so that eglSwapBuffers can be executed as often as necessary.
Instead it will do a sync request after the swap buffers. It will block for
sync complete event in get_back_bo instead of the frame callback. The
compositor is likely to send a release event while processing the new buffer
attach and this makes sure we will receive that before deciding whether to
allocate a new buffer.
If there are no buffers available then instead of returning with an error,
get_back_bo will now poll the compositor by repeatedly sending sync requests
every 10ms. This is a last resort and in theory this shouldn't happen because
there should be no reason for the compositor to hold on to more than three
buffers. That means whenever we attach the fourth buffer we should always get
an immediate release event which should come in with the notification for the
first sync request that we are throttled to.
When the compositor is directly scanning out from the application's buffer it
may end up holding on to three buffers. These are the one that is is currently
scanning out from, one that has been given to DRM as the next buffer to flip
to, and one that has been attached and will be given to DRM as soon as the
previous flip completes. When we attach a fourth buffer to the compositor it
should replace that third buffer so we should get a release event immediately
after that. This patch therefore also changes the number of buffer slots to 4
so that we can accomodate that situation.
If DRM eventually gets a way to cancel a pending page flip then the compositors
can be changed to only need to hold on to two buffers and this value can be
put back to 3.
This also moves the vblank configuration defines from platform_x11.c to the
common egl_dri2.h header so they can be shared by both platforms.
Consider a typical game-style main loop which might be like this:
while (1) {
draw_something();
eglSwapBuffers();
}
In this case the game is relying on eglSwapBuffers to throttle to a sensible
frame rate. Previously this game would end up using three buffers even though
it should only need two. This is because Mesa decides whether to allocate a
new buffer in get_back_bo which would be before it has tried to read any
events from the compositor so it wouldn't have seen any buffer release events
yet.
This patch just moves the block for the frame callback to get_back_bo.
Typically the compositor will send a release event immediately after one of
the attaches so if we block for the frame callback here then we can be sure to
have completed at least one roundtrip and received that release event after
attaching the previous buffer before deciding whether to allocate a new one.
dri2_swap_buffers always calls get_back_bo so even if the client doesn't
render anything we will still be sure to block to the frame callback. The code
to create the new frame callback has been moved to after this call so that we
can be sure to have cleared the previous frame callback before requesting a
new one.
This patch fixes this MinGW build error.
CC glapi_gentable.lo
glapi_gentable.c:47:19: fatal error: dlfcn.h: No such file or directory
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Drivers will need to look at this to decide if they need to do
per-sample fragment shader dispatch.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
My understanding is that Broadwell retains the same SCS mechanism
that Haswell has, so even if the underlying issue with this format
is not fixed, the w/a will be applied in SCS rather than needing
shader code.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Now that all the pieces are in place, this should provide
a nice performance boost for apps using multisample textures.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We need to emit extra shader code in this case to sample the
MCS surface first; we can't just blindly do this all the time
since IVB will sometimes try to access the MCS surface even if
disabled.
V3: Use actual MSAA layout from the texture's mt, rather
then computing what would have been used based on the format.
This is simpler and less fragile - there's at least one case where
we might want to have a texture's MSAA layout change based on what
the app does (CMS SINT falling back to UMS if the app ever attempts
to render to it with a channel disabled.)
This also obsoletes V2's 1/10 -- compute_msaa_layout can now remain
an implementation detail of the miptree code.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This gives us correct behavior for both renderbuffers (which previously
worked) and multisample textures (which would never get an MCS surface
allocated, even if CMS layout was selected)
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The bspec says:
"SW must program the sample mask value in this field so that it matches
with 3DSTATE_SAMPLE_MASK"
I haven't observed this to actually fix anything, but stumbled across it
while adding the rest of the support for CMS layout for multisample
textures.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For some reason this was left out when the version was changed...
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Before this patch, the following code would not be optimized even though
the first two instructions were common to the then and else blocks:
(+f0) IF
MOV dst0 ...
MOV dst1 ...
MOV dst2 ...
ELSE
MOV dst0 ...
MOV dst1 ...
MOV dst3 ...
ENDIF
This commit extends the peephole to handle this case.
No shader-db changes.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
fs_visitor::try_replace_with_sel optimizes only if statements whose
"then" and "else" bodies contain a single MOV instruction. It also
could not handle constant arguments, since they cause an extra MOV
immediate to be generated (since we haven't run constant propagation,
there are more than the single MOV).
This peephole fixes both of these and operates as a normal optimization
pass.
fs_visitor::try_replace_with_sel is still arguably necessary, since it
runs before pull constant loads are lowered.
total instructions in shared programs: 1559129 -> 1545833 (-0.85%)
instructions in affected programs: 167120 -> 153824 (-7.96%)
GAINED: 13
LOST: 6
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This is the last thing that register_coalesce() still handled.
total instructions in shared programs: 1561060 -> 1560908 (-0.01%)
instructions in affected programs: 15758 -> 15606 (-0.96%)
Reviewed-by: Eric Anholt <eric@anholt.net>
parent_mem_ctx was unused since db47074a, so remove the two wrappers
around create() and make create() the constructor.
Reviewed-by: Eric Anholt <eric@anholt.net>
make_list is just a one-line wrapper and was confusingly called by
NULL objects. E.g., cur_if == NULL; cur_if->make_list(mem_ctx).
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously we made the basic block following an ENDIF instruction a
successor of the basic blocks ending with IF and ELSE. The PRM says that
IF and ELSE instructions jump *to* the ENDIF, rather than over it.
This should be immaterial to dataflow analysis, except for if, break,
endif sequences:
START B1 <-B0 <-B9
0x00000100: cmp.g.f0(8) null g15<8,8,1>F g4<0,1,0>F
0x00000110: (+f0) if(8) 0 0 null 0x00000000UD
END B1 ->B2 ->B4
START B2 <-B1
break
0x00000120: break(8) 0 0 null 0D
END B2 ->B10
START B3
0x00000130: endif(8) 2 null 0x00000002UD
END B3 ->B4
The ENDIF block would have no parents, so dataflow analysis would
generate incorrect results, preventing copy propagation from eliminating
some instructions.
This patch changes the CFG to make ENDIF start rather than end basic
blocks, so that it can be the jump target of the IF and ELSE
instructions.
It helps three programs (including two fs8/fs16 pairs).
total instructions in shared programs: 1561126 -> 1561060 (-0.00%)
instructions in affected programs: 837 -> 771 (-7.89%)
More importantly, it allows copy propagation to handle more cases.
Disabling the register_coalesce() pass before this patch hurts 58
programs, while afterward it only hurts 11 programs.
Reviewed-by: Eric Anholt <eric@anholt.net>
This extension enabled the use of texture array with fixed-function and
assembly fragment shaders. No applications are known to use this
extension.
NOTE: This patch regresses GL_TEXTURE_1D_ARRAY and GL_TEXTURE_2D_ARRAY
cases of the copyteximage piglit test. The test is incorrectly using
texture arrays with fixed function while only requiring the
GL_EXT_texture_array extension. A fix for the test has been posted to
the piglit mailing list.
http://lists.freedesktop.org/archives/piglit/2013-November/008639.html
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Every driver that enables one also enables the other. The difference
between the two is MESA adds support for fixed-function and assembly
fragment shaders, but EXT only adds support for GLSL. The MESA
extension was created back when Mesa did not support GLSL.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
main/texobj.c: In function 'count_tex_size':
main/texobj.c:886:23: warning: unused parameter 'key' [-Wunused-parameter]
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
main/texobj.c: In function '_mesa_test_texobj_completeness':
main/texobj.c:553:34: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
main/texobj.c:553:193: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
main/texobj.c:553:254: warning: signed and unsigned type in conditional expression [-Wsign-compare]
main/texobj.c:553:148: warning: signed and unsigned type in conditional expression [-Wsign-compare]
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
That enum requires GL_ARB_texture_cube_map_array, and it is only
available on desktop GL. It looks like this has been an un-noticed
issue since GL_ARB_texture_cube_map_array support was added in commit
e0e7e295.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This adds an extension called EGL_WL_create_wayland_buffer_from_image
which adds the following single function:
struct wl_buffer *
eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, EGLImageKHR image);
The function creates a wl_buffer which shares its contents with the given
EGLImage. The expected use case for this is in a nested Wayland compositor
which is using subsurfaces to present buffers from its clients. Using this
extension it can attach the client buffers directly to the subsurface without
having to blit the contents into an intermediate buffer. The compositing can
then be done in the parent compositor.
The extension is only implemented in the Wayland EGL platform because of
course it wouldn't make sense anywhere else.
If we're not using EGL_EXT_swap_buffers_with_damage, we have to
damage the full extent. EGL operates on buffer coordinates, but
wl_surface.damage takes surface coordinates. EGL doesn't know the
buffer transformation (rotated or scaled) and can't post accurate
damage in surface coordinates. The damage event however is clipped to
the surface extents so we can just damage the maximum rectangle.
In case of EGL_EXT_swap_buffers_with_damage, the application knows
the buffer transform and is expected to pass in rectangles in
surface space.
https://bugs.freedesktop.org/show_bug.cgi?id=70250
Cc: "10.0" mesa-stable@lists.freedesktop.org
flush_with_flags, when available, allows the driver to throttle.
Using this suppress input lag issues that can be observed in heavy
rendering situations on non-intel cards.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Cc: "10.0" mesa-stable@lists.freedesktop.org
This typically won't make a difference, since we only send the requests at
wl_display_flush() time. There might be a small race
with another thread calling wl_display_flush() after our commit request,
but before we flush the DRI driver. Moving the commit below the DRI
driver flush call looks more natural and eliminates the small race.
Cc: "10.0" mesa-stable@lists.freedesktop.org
We would like the compositor to receive the commited buffer
as soon as possible, so it has the time to treat it, and
release old ones. We shouldn't rely on the client
to flush the queue for us.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Cc: "10.0" mesa-stable@lists.freedesktop.org
Display lists allocate memory in chunks of 256 tokens (1KB) at a time.
If an app creates many short display lists or uses glXUseXFont() this
can waste quite a bit of memory.
This patch uses realloc() to trim short lists and reduce the memory
used.
Also, null/zero-out some list construction fields in _mesa_EndList().
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now, sizeof(gl_dlist_node)==4 even on 64-bit systems. This can
halve the memory used by some display lists on 64-bit systems.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is a first step in reducing memory used by display lists on
64-bit systems. On 64-bit systems, the gl_dlist_node union type
is 8 bytes because of the 'data' and 'next' fields. This causes
every display list node/token to occupy 8 bytes instead of 4 as
originally designed. This basically doubles the memory used by
some display lists on 64-bit systems.
The fix is to remove the 64-bit 'data' and 'next' pointer fields
from the union and instead store them as a pair of 32-bit values.
Easily done with a few helper functions.
The next patch will take care of the 'next' field.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This fixes a memory leak in some situations. Also avoids emitting an
extra fence if the kick handler does the call to nouveau_fence_next
itself.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 10.0" <mesa-stable@lists.freedesktop.org>
So that it acts like ordinary free(). This lets us remove a bunch of
if statements where the function is called.
v2:
- Avoiding compile error on MSVC and possible warnings on other compilers.
- Added comment regards passing NULL pointer being safe.
Reviewed-by: Brian Paul <brianp@vmware.com>
I missed this in the boolean -> enum conversion. C cheerfully casts
false -> 0 -> UNKNOWN_RING. On Gen4-5, this causes the render ring
prelude hook to get called in the middle of the batch, which is crazy.
BRW_BATCH_STRUCT is not used on Gen6+.
Fixes regressions since 395a32717d
("i965: Introduce an UNKNOWN_RING state.").
Fixes "fips -v glxgears" on Ironlake.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This reverts commit a4bf7f6b6e.
It breaks occlusion queries on Gen4-5. Doing this right will likely
require larger changes, which should be done at a future date.
Some Piglit tests still passed due to other bugs; fixing those revealed
this problem.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
I guarded half of the callers to start/stop_oa_counters with generation
checks, but missed the other half (which were added later). OACONTROL
doesn't exist on Ironlake, so we better not write it. Also, there's no
need---Ironlake's performance counters are always running.
This patch moves the generation checks into start/stop_oa_counters,
rather than requiring the caller to do them.
Fixes assertion failures in Piglit's AMD_performance_monitor/measure.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
One can select if they want to fallback to softpipe.
Current approach makes this not possible, whereas other
targets (dri-swrast) handle this approapriately.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The BSpec states that the aligment for the non-msrt clear rectangle must
be doubled; the BSpec does not restricit the workaround to specific
hardware.
Commit 9a1a67b applied the workaround to Haswell GT3. Commit 8b659ce
expanded the workaround to all Haswell variants. This commit expands it
to all hardware.
No Piglit regressions on Ivybridge 0x0166. No fixes either.
I know no Ivybridge nor Baytrail bug related to this workaround.
However, the BSpec says the extra alignment is required, so let's do it.
v2: Apply to all hardware, not just gen7.
CC: "9.2, 10.0" <mesa-stable@lists.freedesktop.org>
CC: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
All bound layers (from first_layer to last_layer) should be cleared.
This uses a vertex shader which outputs gl_Layer = gl_InstanceID, so each
instance goes to a different layer. By rendering a quad and setting
the instance count to the number of layers, it will trivially clear all
layers.
This requires AMD_vertex_shader_layer (or PIPE_CAP_TGSI_VS_LAYER), which only
radeonsi supports at the moment. r600 could do this too. Standard DX11
hardware will have to use a geometry shader though, which has higher overhead.
This is a subset of geometry shaders. It's all about setting first_layer and
last_layer correctly.
Also some code between st_render_texture and update_framebuffer_state is
consolidated. It doesn't use rtt_level and derives the level from dimensions
instead as the code in st_atom_framebuffer.c did.
Commit a594cec broke EGL X11 backend by adding dependency between
X11 and DRM backends requiring HAVE_EGL_PLATFORM_DRM defined for X11.
This patch fixes the issue by adding additional define for libdrm
detection independent of which backend is being compiled. Tested by
compiling Mesa with '--with-egl-platforms=x11' and running es2gears_x11
+ glbenchmark2.7 successfully.
v2: return true for dri2_auth if running without libdrm (Samuel)
v3: check libdrm when building EGL drm platform + AM_CFLAGS fix (Emil)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72062
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: mesa-stable@lists.freedesktop.org
MI_STORE_REGISTER_MEM has to take a 48-bit address, so the existing code
doesn't work. But supposedly Broadwell has a register whitelist and
just works out of the box anyway, so there's no need to check.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The Gen7 sampler state code still works. Increasing the alignment to
64 bytes makes bit 5 zero, which is good because it's now reserved.
Since we don't use the new filter bits, we can leave those as zero too,
which means we don't need to update the code to update the pointer.
(We probably should anyway, for clarity, but alas, another day.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The documentation is really hard to follow, but apparently a 32-bit x
32-bit multiply just works without the MACH macro. The macro apparently
is only necessary to get the full 64-bit value.
Fixes Piglit tests [vf]s-op-mult-int-int.shader_test.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Like Haswell, we do this in SURFACE_STATE rather than shader
workarounds.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Broadwell doesn't support a surface vertical alignment of 2. It only
supports VALIGN_4, VALIGN_8, or VALIGN_16. I chose 4 since it's the
least wasteful.
v2: Replace my comment with a better one from Eric. Move Broadwell
checks earlier so it's more obvious that "return 2" won't be hit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We need to SEND from a GRF, and we can only obtain those prior to
register allocation.
This allows us to do pull constant loads without the MRF hack.
v2: Reword comments (suggested by Paul).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
SEND can't deal with swizzles, source modifiers, and so on. This should
avoid problems with VS pull constant loads on Broadwell.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Pre-patch, the workaround was applied to only HSW GT3. However, the
workaround also fixes render corruption on the HSW GT1 Chromebook,
codenamed Falco.
Also, update the BSpec quote that discusses the workaround to reflect
the latest BSpec.
The BSpec states that the workaround is required for Ivybridge and
Baytrail as well as Haswell. But, we apply the workaround to only
Haswell because (a) we suspect that is the only hardware where it is
actually required and (b) we haven't yet validated the workaround for
the other hardware.
CC: "9.2, 10.0" <mesa-stable@lists.freedesktop.org>
CC: Anuj Phogat <anuj.phogat@gmail.com>
OTC-Tracker: CHRMOS-812
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Previously, we stored an array of up to 16 additional shaders to link,
as well as a count of how many each shader actually needed.
Since the built-in functions rewrite, all the built-ins are stored in a
single shader. So all we need is a boolean indicating whether a shader
needs to link against built-ins or not.
During linking, we can avoid creating the temporary array if none of the
shaders being linked need built-ins. Otherwise, it's simply a copy of
the array that has one additional element. This is much simpler.
This patch saves approximately 128 bytes of memory per gl_shader object.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since the built-in functions rewrite, num_builtins_to_link is always either
0 or 1, so we don't need tho crazy loop starting at -1 with a special
case.
All we need to do is print the prototypes from the current shader, and
the single built-in function shader (if present).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, when we hit a "no matching function" error, it looked like:
0:0(0): error: no matching function for call to `cos()'
0:0(0): error: candidates are: float cos(float)
0:0(0): error: vec2 cos(vec2)
0:0(0): error: vec3 cos(vec3)
0:0(0): error: vec4 cos(vec4)
Now it looks like:
0:0(0): error: no matching function for call to `cos()'; candidates are:
0:0(0): error: float cos(float)
0:0(0): error: vec2 cos(vec2)
0:0(0): error: vec3 cos(vec3)
0:0(0): error: vec4 cos(vec4)
This is not really any worse and removes the need for the prefix variable.
It will also help with the next commit's refactoring.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
There's no need to loop through the "parameters" list and remove every
element; move_nodes_to(¶meters) already throws away all elements of
the destination list.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
make[5]: Entering directory `/jhbuild/build/mesa/mesa/src/mapi/glapi/tests'
CXX check_table.o
/jhbuild/checkout/mesa/mesa/src/mapi/glapi/tests/check_table.cpp:29:30: fatal error: glapi/glapitable.h: No such file or directory
We should look for the generated file glapi/glapitable.h in builddir, not srcdir
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel. For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.
To work around this problem, sample from the source surface using
R32_FLOAT. This shouldn't affect rendering correctness, because when
doing these resolve blits, the destination format is R32_FLOAT, so the
channel replication done by L32_FLOAT and I32_FLOAT is unnecessary.
Fixes piglit tests on Sandy Bridge:
- spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float
- spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float
No piglit regressions on Sandy Bridge.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70601
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
for some time. Thanks to the preceding patch, the compiler front-end
no longer breaks this assumption.
This patch adds code to validate the assumption so that if we have
future bugs, we'll be able to catch them earlier.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
ir_loop::counter is non-null, it points to a fresh ir_variable that
should be used as the loop counter (as opposed to an ir_variable that
exists elsewhere in the instruction stream).
However, previous to this patch:
(1) loop_control_visitor did not create a new variable for
ir_loop::counter; instead it re-used the existing ir_variable.
This caused the loop counter to be double-incremented (once
explicitly by the body of the loop, and once implicitly by
ir_loop::increment).
(2) ir_clone did not clone ir_loop::counter properly, resulting in the
cloned ir_loop pointing to the source ir_loop's counter.
(3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting
in the ir_variable being missed by reparenting.
Additionally, most optimization passes (e.g. loop unrolling) assume
that the variable mentioned by ir_loop::counter is not accessed in the
body of the loop (an assumption which (1) violates).
The combination of these factors caused a perfect storm in which the
code worked properly nearly all of the time: for loops that got
unrolled, (1) would introduce a double-increment, but loop unrolling
would fail to notice it (since it assumes that ir_loop::counter is not
accessed in the body of the loop), so it would unroll the loop the
correct number of times. For loops that didn't get unrolled, (1)
would introduce a double-increment, but then later when the IR was
cloned for linking, (2) would prevent the loop counter from being
cloned properly, so it would look to further analysis stages like an
independent variable (and hence the double-increment would stop
occurring). At the end of linking, (3) would prevent the loop counter
from being reparented, so it would still belong to the shader object
rather than the linked program object. Provided that the client
program didn't delete the shader object, the memory would never get
reclaimed, and so the shader would function properly.
However, for loops that didn't get unrolled, if the client program did
delete the shader object, and the memory belonging to the loop counter
got re-used, this could cause a use-after-free bug, leading to a
crash.
This patch fixes loop_control_visitor, ir_clone, and
ir_hierarchical_visitor to treat ir_loop::counter the same way the
back-ends treat it: as a freshly allocated ir_variable that needs to
be visited and cloned independently of other ir_variables.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If an ir_loop has a non-null "counter" field, the variable referred to
by this field is implicitly read and written by the loop. We need to
account for this in ir_variable_refcount, otherwise there is a danger
we will try to dead-code-eliminate the loop counter variable.
Note: at the moment the dead code elimination bug doesn't occur due to
a bug in ir_hierarchical_visitor: it doesn't visit the "counter"
field, so dead code elimination doesn't treat it as a candidate for
elimination. But the patch to follow will fix that bug, so we need to
fix ir_variable_refcount first in order to avoid breaking dead code
elimination.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The flags value is a bitfield so use the union's 'bf' field, not 'e'
(enum) field. There's no actual change in behavior here since both
fields of the union are the same size.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Trying to compile any of these functions into a display list
now just generates a GL_INVALID_OPERATION error.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now that it is possible to query drivers for the max sampler view it should
be safe to increase this without crashing.
Not entirely convinced this really works correctly though if state trackers
using non-linked sampler / sampler_views use this.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Ever since introducing separate sampler and sampler view max this was really
missing.
Every driver but llvmpipe reports the same number as number of samplers for
now, so nothing should break.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This adds support for this to more drivers, in particular for all the "special"
ones useful for debugging.
HW drivers are left alone, some should be able to support it if they want but
they may not be interested at this point.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
GLX_ARB_create_context).
This fixes a regression in the piglit test
"glx/GLX_ARB_create_context/invalid flag"
v2: Remove commented debug code. Noticed by Jordan.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reported-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
This patch fixes this build error with Oracle Solaris Studio.
libtool: link: /opt/solarisstudio12.3/bin/cc -g -o glcpp/glcpp glcpp.o prog_hash_table.o ./.libs/libglcpp.a
Undefined first referenced
symbol in file
sqrt prog_hash_table.o
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
In brw_update_renderbuffer_surfaces(), if there are no color draw
buffers, we always set up a null render target at surface index 0 so we
have something to use with the FB write marking the end of thread.
However, when we recently began computing surface indexes dynamically,
we failed to reserve space for it. This meant that the first texture
would be assigned surface index 0, and our closing FB write would
clobber the texture.
Fixes Piglit's EXT_packed_depth_stencil/fbo-blit-d24s8 test on Gen4-5,
which regressed as of commit 4e5306453d
("i965/fs: Dynamically set up the WM binding table offsets.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70605
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Tested-by: lu hua <huax.lu@intel.com>
Cc: "10.0" mesa-stable@lists.freedesktop.org
Now that we have dynamic binding tables there's no good reason anymore
to expose so few atomic counter buffers. Increase it to 16.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If reparent_ir() is called on invalid IR, then there's a danger that
it will fail to reparent all of the necessary nodes. For example, if
the IR contains an ir_dereference_variable which refers to an
ir_variable that's not in the tree, that ir_variable won't get
reparented, resulting in subtle use-after-free bugs once the
non-reparented nodes are freed. (This is exactly what happened in the
bug fixed by the previous commit).
This patch makes this kind of bug far easier to track down, by
transforming it from a use-after-free bug into an explicit IR
validation error.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an
ir_rvalue_visitor), we failed to notice that since
lower_clip_distance_visitor overrides visit_leave(ir_assignment *),
ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called.
As a result, clip distance dereferences appearing directly on the
right hand side of an assignment (not in a subexpression) weren't
getting properly lowered. This caused an ir_dereference_variable node
to be left in the IR that referred to the old gl_ClipDistance
variable. However, since the lowering pass replaces gl_ClipDistance
with gl_ClipDistanceMESA, this turned into a dangling pointer when the
IR got reparented.
Prior to the introduction of geometry shaders, this bug was unlikely
to arise, because (a) reading from gl_ClipDistance[i] in the fragment
shader was rare, and (b) when it happened, it was likely that it would
either appear in a subexpression, or be hoisted into a subexpression
by tree grafting.
However, in a geometry shader, we're likely to see a statement like
this, which would trigger the bug:
gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i];
This patch causes
lower_clip_distance_visitor::visit_leave(ir_assignment *) to call the
base class visitor, so that the right hand side of the assignment is
properly lowered.
Fixes piglit test:
- spec/glsl-1.50/execution/geometry/clip-distance-itemized-copy
Cc: Ian Romanick <idr@freedesktop.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The previous commit fixes a bug wherein we would incorrectly refer to
stale geometry shader prog_data when no geometry shader was active.
This patch reduces the likelihood of that sort of bug occurring in the
future by setting prog_data to NULL whenever there is no GS program.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, in brw_gs_upload_binding_table(), we checked whether
brw->gs.prog_data was NULL in order to determine whether a geometry
shader was active. This didn't work: brw->gs.prog_data starts off as
NULL, but it is set to non-NULL when a geometry shader program is
built, and then never set to NULL again. As a result, if we called
brw_gs_upload_binding_table() while there was no geometry shader
active, but a geometry shader had previously been active, it would
refer to a stale (and possibly freed) prog_data structure.
This patch fixes the problem by modifying
brw_gs_upload_binding_table() to use the proper technique to determine
whether a geometry shader is active: by checking whether
brw->geometry_program is NULL.
This fixes the crash reported in comment 2 of bug 71870 (the incorrect
rendering remains, however).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Rather than always advertising the extension but failing to create a
context with reset notifiction, just don't advertise it. I don't know
why it didn't occur to me to do it this way in the first place.
NOTE: Kristian requested that I provide a follow-up for master that
dynamically generates the list of DRI extensions instead of selected
between two hardcoded lists.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Suggested-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Replace all occurences of the macro with its expansion.
It seems that the macro intended to provide cross-platform static mutex
intialization. However, it had the same definition in all pre-processor
paths:
#define _EGL_DECLARE_MUTEX(m) _EGLMutex m = _EGL_MUTEX_INITIALIZER
Therefore this abstraction obscured rather than helped.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Insert two fields into _egl_global to hold the client extensions and
statically initialize them:
ClientExtensions // a struct of bools
ClientExtensionString
Post-patch, Mesa supports exactly one client extension,
EGL_EXT_client_extensions.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The fast tiled texture upload code does not compile with GCC 4.8's -Og
optimization flag.
memcpy() has the always_inline attribute set. This poses a problem,
since {x,y}tile_copy_faster calls it indirectly via {x,y}tile_copy,
and {x,y}tile_copy normally aren't inlined at -Og.
Using __attribute__((flatten)) tells GCC to inline every function call
inside the function, which I believe was the author's intent.
Fix suggested by Alexander Monakov.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: mesa-stable@lists.freedesktop.org
8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
from the llvmpipe-rast-64 branch.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
.. and mark them off on the extensions list as done.
V2: Enable only if pipelined register writes work.
V3: Also update relnotes
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Just prior to emitting the 3DPRIMITIVE command, we load each of the
indirect registers. The values loaded are either from offsets into the
current indirect BO, or constant zero if the parameter is not used for
this draw.
Enabling use of the indirect registers is done by turning on a bit in
the first dword of the 3DPRIMITIVE command itself.
V3: - Deduplicate the common part of both indexed and nonindexed indirect
setup.
- Just refer to the indirect bo out of the context directly.
V4: - Fix bo reference to specify the range we care about.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
- MMIO registers for draw parameters
- New bit in 3DPRIMITIVE command to enable indirection
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
V3: - Disallow primcount==0 for DrawMulti*Indirect. The spec is unclear
on this, but it's silly. We might go back on this later if it
turns out to be a problem.
- Make it clear that the caller has dealt with stride==0
V4: - Allow primcount==0 again.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We will reuse the same extension flag for ARB_multi_draw_indirect since
it can always be supported by looping.
Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Split from patch implementing ARB_draw_indirect.
v2: Const-qualify the struct gl_buffer_object *indirect argument.
v3: Fix up some more draw calls for new argument.
v4: Fix up rebase conflicts in i965.
v5: Undo const-qualification
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
V2: drop description of `fall` and `wm`, which have been removed by the
previous patch; describe `stats`.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
DEBUG_IOCTL comes from i965, and is about to be removed. Both defines
have the same value (4).
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Limit the max glsl version level to what the state tracker supports.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
V2: Return after error to avoid cascading error messages and
removed redundant "to" from error message
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I recently made us try two different things that tried to reduce register
pressure so that we would be more likely to allocate successfully. But
now that we have the logic for trying two, we can make the first thing we
try be the normal, not-prioritizing-register-pressure heuristic.
This means one less scheduling pass in the common case of that heuristic
not producing spills, plus the best schedule we know how to produce, if
that one happens to succeed. This is important, because our register
allocation produces a lot of possibly avoidable dependencies for the
post-register-allocation schedule, despite ra_set_allocate_round_robin().
GLB2.7: 1.04127% +/- 0.732461% fps improvement (n=31)
nexuiz: No difference (n=5)
lightsmark: 0.838512% +/- 0.300147% fps improvement (n=86)
minecraft apitrace: No difference (n=15)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The canary is basically just to give a better debugging message when you
ralloc_free() something that wasn't rallocated. Reduces maximum memory
usage of apitrace replay of the dota2 demo by 60MB on my 64-bit system (so
half that on a real 32-bit dota2 environment).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I think I was thinking of the batch command packet cache when I pasted
this in, but this counter is only used for dumping out streamed state for
INTEL_DEBUG=batch and for putting annotations in our aub files.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Commit 2f89662 added the driconf option 'clamp_max_samples'. In that
commit, the option did not alter the context version. The neglect to
alter the context version is a fatal issue for some apps.
For example, consider running Chromium with clamp_max_samples=0.
Pre-patch, Mesa creates a GL 3.0 context but clamps GL_MAX_SAMPLES to
0. This violates the GL 3.0 spec, which requires GL_MAX_SAMPLES >= 4.
The spec violation causes WebGL context creation to fail in many
scenarios because Chromium correctly assumes that a GL 3.0 context
supports at least 4 samples.
Since the driconf option was introduced largely for Chromium, the issue
really needs fixing.
This patch fixes calculation of the context version to respect the
post-clamped value of GL_MAX_SAMPLES. This in turn fixes WebGL on
Chromium when clamp_max_samples=0.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
clamp_max_samples() and intel_quantize_num_samples() each maintained
their own list of which MSAA modes the hardware supports. This patch
removes the duplication by making intel_quantize_num_samples() use the
same list as clamp_max_samples(), the list maintained in
brw_supported_msaa_modes().
By removing the duplication, we prevent the scenario where someone
updates one list but forgets to update the other.
Move function `brw_context.c:static brw_supported_msaa_modes()` to
`intel_screen.c:(non-static) intel_supported_msaa_modes()` and patch
intel_quantize_num_samples() to use the list returned by that function.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This simplifies the loop logic in a subsqequent patch that refactors
intel_quantize_num_samples() to use brw_supported_msaa_modes().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
Reviewed-by: Brian Paul <brianp@vmware.com>
Several of links the were contributed by Keith Whitwell and Roland Scheidegger.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
From section 6.1.18 (Renderbuffer Object Queries) of the GL 3.2 spec,
under the heading "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE
is TEXTURE, then":
If pname is FRAMEBUFFER_ATTACHMENT_LAYERED, then params will
contain TRUE if an entire level of a three-dimesional texture,
cube map texture, or one-or two-dimensional array texture is
attached. Otherwise, params will contain FALSE.
Fixes piglit tests:
- spec/!OpenGL 3.2/layered-rendering/framebuffer-layered-attachments
- spec/!OpenGL 3.2/layered-rendering/framebuffertexture-defaults
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
v2: Don't include "EXT" in the error message, since this query only
makes sensen in context versions that have adopted
glGetFramebufferAttachmentParameteriv().
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously we were using the code path for validating
glFramebufferTextureLayer(). But glFramebufferTexture() allows
additional texture types.
Fixes piglit tests:
- spec/!OpenGL 3.2/layered-rendering/gl-layer-cube-map
- spec/!OpenGL 3.2/layered-rendering/framebuffertexture
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
v2: Clarify comment above framebuffer_texture().
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes the fast depth clear path.
Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-depth".
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes the blorp clear path for color buffers.
Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-color".
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:
When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.
This patch fixes meta clears to properly clear all layers of a layered
framebuffer attachment. We accomplish this by adding a geometry
shader to the meta clear program which sets gl_Layer to a uniform
value. When clearing a layered framebuffer, we execute in a loop,
setting the uniform to point to each layer in turn.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In order to properly clear layered framebuffers, we need to know how
many layers they have. The easiest way to do this is to record it in
the gl_framebuffer struct when we check framebuffer completeness.
This patch replaces the gl_framebuffer::Layered boolean with a
gl_framebuffer::NumLayers integer, which is 0 if the framebuffer is
not layered, and equal to the number of layers otherwise.
v2: Remove gl_framebuffer::Layered and make gl_framebuffer::NumLayers
always have a defined value. Fix factor of 6 error in the number of
layers in a cube map array.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Prevents a GPU page fault if somehow the uniform bo gets evicted
before the screen_create pushbuf has been submitted.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Previously, we checked for interstage uniform interface block link
errors in validate_interstage_interface_blocks(), which is only called
on pairs of adjacent shader stages. Therefore, we failed to detect
uniform interface block mismatches between non-adjacent shader stages.
Before the introduction of geometry shaders, this wasn't a problem,
because the only supported shader stages were vertex and fragment
shaders, therefore they were always adjacent. However, now that we
allow a program to contain vertex, geometry, and fragment shaders,
that is no longer the case.
Fixes piglit test "skip-stage-uniform-block-array-size-mismatch".
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
v2: Rename validate_interstage_interface_blocks() to
validate_interstage_inout_blocks() to reflect the fact that it no
longer validates uniform blocks.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
v3: Make validate_interstage_inout_blocks() skip uniform blocks.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, when attempting to link a vertex shader and a geometry
shader that use different GLSL versions, we would sometimes generate a
link error due to the implicit declaration of gl_PerVertex being
different between the two GLSL versions.
This patch fixes that problem by only requiring interface block
definitions to match when they are explicitly declared.
Fixes piglit test "shaders/version-mixing vs-gs".
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
v2: In the interface_block_definition constructor, move the assignment
to explicitly_declared after the existing if block.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From section 7.1 (Built-In Language Variables) of the GLSL 4.10
spec:
Also, if a built-in interface block is redeclared, no member of
the built-in declaration can be redeclared outside the block
redeclaration.
We have been regarding this text as a clarification to the behaviour
established for gl_PerVertex by GLSL 1.50, so we apply it regardless
of GLSL version.
This patch enforces the rule by adding an enum to ir_variable to track
how the variable was declared: implicitly, normally, or in an
interface block.
Fixes piglit tests:
- gs-redeclares-pervertex-out-after-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-global-redeclaration.vert
- gs-redeclares-pervertex-out-after-other-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-other-global-redeclaration.vert
- gs-redeclares-pervertex-out-before-global-redeclaration
- vs-redeclares-pervertex-out-before-global-redeclaration
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
v2: Don't set "how_declared" redundantly in builtin_variables.cpp.
Properly clone "how_declared".
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Unfortunately, our hardware only has one set of aggregating performance
counters shared between all 3D programs, and their values are not saved
or restored by hardware contexts. Also, at least on Sandybridge and
Ivybridge, the counters lose their values if the GPU goes to sleep.
To work around both of these problems, we have to snapshot the
performance counters at the beginning and end of each batch, similar to
how we handle query objects on platforms that don't support hardware
contexts. I call these "bookend" snapshots.
Since there can be multiple performance monitors active at a time, we
store the bookend snapshots in a global BO, shared by all monitors.
For monitors that span multiple batches, acquiring results involves
adding up three segments:
BeginPerfMonitor --> End of Batch 1 ("head")
Start of Batch 2 --> End of Batch 2
... ("middle")
Start of Batch N-1 --> End of Batch N-1
Start of Batch N --> EndPerfMonitor ("tail")
Monitors that refer to bookend BO snapshots are considered "unresolved".
We delay resolving them (and adding up deltas to obtain the results) as
long as possible to avoid blocking on mapping monitor->oa_bo.
We can also run out of space in the bookend BO, at which point we have
to resolve all unresolved monitors. Then we can throw away the
snapshots and begin writing at the beginning of the buffer.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
In order to use the Observability Architecture effectively, we'll need
to take snapshots of the OA counters via MI_REPORT_PERF_COUNT at the
start and end of each batch.
Experimentation reveals that we need to flush before and after each
MI_REPORT_PERF_COUNT to get working values. For simplicitly, I chose to
use intel_batchbuffer_emit_mi_flush(), which unfortunately expands to
triple pipe controls on Sandybridge.
We may want to start computing per-generation reserved batch space to
avoid the insanity of Sandybridge's PIPE_CONTROL cost. That said, much
of this cost existed before I rewrote the query object support to use
hardware contexts, so it's at least not entirely new.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Currently, this only considers the monitor start and end snapshots.
This is woefully insufficient, but allows me to add a bunch of the
infrastructure now and flesh it out later.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We need to start OA at the beginning of each batch where monitors are
active. OACONTROL isn't part of the hardware context, so to avoid
leaving counters enabled for other applications, we turn them off at the
end of the batch too.
We also need to start them at BeginPerfMonitor time (unless they've
already been started). We stop them when the monitor last ends as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We'll need to write this register to start/stop performance counters.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
MI_REPORT_PERF_COUNT writes a snapshot of the Observability Architecture
counters to a buffer. Exactly how it works varies between generations:
Ironlake requires two packets, Sandybridge has to use GGTT, and Ivybridge
and later use PPGTT.
v2: Assert that we didn't use more space than we reserved (suggested
by Eric Anholt).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Using the OA counters requires some per-batch work. When starting and
ending a batch, it's useful to know whether any monitors are actually
interested in OA data.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
In addition to listing the counter names, we include several "remap"
tables. Confusingly, counters are documented with names like "A23",
are written to some buffer offset other than 23, and exposed by core
Mesa under a counter ID that is different still.
The first is inevitable; MI_REPORT_PERF_COUNT writes certain counters to
fixed locations in the buffer. The latter could be avoided, but core
Mesa uses the "Counters" array index as the ID for a counter. We could
do remapping there, but it would just complicate the core Mesa code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is fairly simple:
- At BeginPerfMonitor time, take an opening snapshot.
- At EndPerfMonitor time, take a closing snapshot.
- The first time the application asks for results, subtract the two and
store that value. Then free the BO containing the snapshots.
- On subsequent requests for the results, just return the saved value.
- On reset, throw away the results.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
For now, we only support these on Gen6+, since that's what currently
uses hardware contexts. When we add Ironlake hardware context support,
we can add pipeline statistics register support for that as well.
In theory, we could support pipeline statistics counters even without
hardware contexts, but it would be annoyingly painful.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Since we don't support any counters, there are zero groups.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The Observability Architecture counters are 32-bit unsigned values, and
the Pipeline Statistics Register counters are 64-bit unsigned values.
These convenience macros make it easy to create those types of counters.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
It's useful to see the state of all outstanding monitors; the start
of a new batch seems like a reasonable time to print them out.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
These stub functions will be filled out in later patches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This will enable debugging printfs for the AMD_performance_monitor code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Without hardware contexts, the pipeline statistics registers are
free-running and include data from every 3D application running.
In order to find out the contributions of one particular context, we
need to take a snapshot at the start and end of each batch.
Previously, we emitted the PIPE_CONTROL necessary to capture
PS_DEPTH_COUNT when drawing primitives. Special tracking ensured it
happened only on the first draw of the batch, rather than on every draw.
Moving this to brw_new_batch increases symmetry, since the final
snapshot has always been in brw_finish_batch, which is just a few lines
below. It should be basically equivalent.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The new intel_batchbuffer_emit_render_ring_prelude() hook will be called
when switching from BLT or UNKNOWN_RING to RENDER_RING. This provides a
place to emit state that should go at the start of each render ring
batch, with minimal overhead.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
When we first create a batch buffer, it's empty. We don't actually
know what ring it will be targeted at until the first BEGIN_BATCH or
BEGIN_BATCH_BLT macro.
Previously, one could determine the state of the batch by checking
brw->batch.ring (blit vs. render) and brw->batch.used != 0 (known vs.
unknown).
This should be functionally equivalent, but the tri-state enum is a bit
clearer.
v2: Catch three explicit require_space callers (thanks to Carl and Eric).
v3: Split the boolean -> enum change from the UNKNOWN_RING change.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Passing BLT_RING or RENDER_RING to batchbuffer functions is a lot more
obvious than passing true or false.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Some rounding errors could crop up when calculating a0. Use a more accurate
method (barycentric interpolation essentially) to fix this, though to fix
the REAL problem (which is that our interpolation will give very bad results
with small triangles far away from the origin when they have steep gradients)
this does absolutely nothing (actually makes it worse). (To fix the real
problem, either would need to use a vertex corner (or some other point inside
the tri) as starting point value instead of fb origin and pass that down to
interpolation, or mimic what hw does, use barycentric interpolation (using
the coordinates extracted from the rasterizer edge functions) - maybe another
time.)
Some (silly) tests though really want a high accuracy at fb origin and don't
care much about anything else (Just. Don't. Ask.).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
D3D9 Shader Model 2 restricted the fog register to one component,
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172945.aspx ,
but that restriction no longer exists in Shader Model 3, and several
WHCK tests enforce that.
So this change:
- lifts the single-component restriction TGSI_SEMANTIC_FOG
from Gallium interface
- updates the Mesa state tracker to enforce output fog has (f, 0, 0, 1)
- draw module was updated to leave TGSI_SEMANTIC_FOG output registers
alone
Several gallium drivers that are going out of their way to clear
TGSI_SEMANTIC_FOG components could be simplified in the future.
Thanks to Si Chen and Michal Krol for identifying the problem.
Testing done: piglit fogcoord-*.vpfp tests
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Same as Si Chen's commit e7a5905d8a for
tgsi_exec module.
Not actually tested, because softpipe is failing the test that caught
this bug due to unrelated issues.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Earlier comments suggest this was removed from GL core spec but it is
still there. Enabling makes 'texture_lod_bias_getter' Khronos
conformance tests pass, also removes some errors from Metro Last Light
game which is using this API.
v2: leave NOTE comment (Ian)
Cc: "9.0 9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
The alignment of a virtual memory area must always be at least 4096 bytes.
It only worked because size was aligned to 4096 outside of the function.
Signed-off-by: Christian König <christian.koenig@amd.com>
If a user set MESA_INFO and the OpenGL application uses a
3.0 or later context then the MESA_INFO debug output will have
an error when it queries for extensions using the deprecated
enum GL_EXTENSIONS. Passing context argument allows code
to return extension list directly regardless of profile.
Commit title updated as recommended by Kenneth Graunke.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
BLORP is essential. However, porting it to Gen8 is a huge amount of
work. Disabling it for now allows us to proceed with basic hardware
enablement.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
HiZ is difficult to implement, and while it's essential for performance,
we don't need it right away for purposes of hardware enabling.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
As always, the chipset limits here are placeholders, rather than the
actual values.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965 passed piglit, but swrast and gallium both segfaulted without this.
i965 happened to work because it never ran _mesa_load_state_parameters()
on the new program before the test called glProgramLocalParameter(), which
was allocating a LocalParams array for the fallback path.
v2: Since v1 threw away old localparams data, leaked old LocalParams
memory, only fixed fragment programs, and I was dubious of my previous
invariants already (nothing but program_parse.y will generate
LocalParams, and only that one path of program_parse.y will), just
late-allocate localparams at the other point of dereferencing them.
This adds overhead to _mesa_load_state_parameter, which is
uncomfortable, but I'm pretty sure that giant switch statement is
super slow already.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71734
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Removes IF/ENDIF and IF/ELSE/ENDIF with no intervening instructions.
total instructions in shared programs: 1360393 -> 1360387 (-0.00%)
instructions in affected programs: 157 -> 151 (-3.82%)
(no change in vertex shaders)
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For commit 4df56177 Paul discovered that the hardware restriction that
Align16 instructions cannot be compressed was lifted on Haswell. This
has prevented us from emitting compressed three-source instructions.
For added confirmation, the bspec lists a work around called
WaBreakSimd16TernaryInstructionsIntoSimd8 that hasn't been applicable
since very early Haswell silicon.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, register_coalesce() would modify
mov vgrf1:f vgrf2:f
cmp null vgrf3:d vgrf1:d
to be
cmp null vgrf3:d vgrf2:f
and incorrectly use vgrf2's type in the instruction that the mov was
coalesced into.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It's not necessary to scale down cubemap texture coords when generating
mipmaps: we are doing a 2x minification therefore it's guaranteed that
the texture coords will always be at least 1 texel away of the edges.
Scaling down can actually be harmful, as it may cause artefacts when
generating mipmaps with nearest filtering. Sample points will lie
exactly in the middle each 2x2 texels, so the scaling factor was causing
different texels to be take on each quadrant of the cube face. This is
apparent with a 1x1 checkerboard pattern in the base mipmap level:
instead of next mipmap level receiving a constant color throughout the
face, it will have different colors for each quadrant of the face.
The behaviour for blits is left untouched for now, but the cubemap
texture coord scaling hack should be reconsidered eventually.
Reviewed-by: Brian Paul <brianp@vmware.com>
We need to check the drawbuffer's orientation before inverting Y
coordinates. Fixes piglit feedback tests when running with the
-fbo option.
Cc: "9.2" "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The exec_mask must be taken in consideration, just like emit_kill above.
The tgsi_exec module has the same bug and should be fixed in a future
change.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Gen7 does not allow render targets to have a vertical alignment of 2.
So, when creating a surface, if its format is renderable, and its
vertical alignment is 2, force it to use X tiling.
Reviewed-by: Eric Anholt <eric@anholt.net>
Gen6+ allows for color buffers to use a vertical alignment of either 4
or 2. Previously we defaulted to 2. This may have caused problems on
Gen7 because Y-tiled render targets are not allowed to use a vertical
alignment of 2.
This patch changes the vertical alignment to 4 on Gen7, except for the
few formats where a vertical alignment of 2 is required.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Commit 70953b5 (i965: Initialize all member variables of
vec4_instruction on construction) inadvertently added a line to the
vec4_instruction constructor setting this->ir to NULL, wiping out the
previously set value. As a result, ever since then, the output of
INTEL_DEBUG=vs and INTEL_DEBUG=gs has been missing IR annotations.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is basically a a respin of f1dfcf4bce35e6796f873d9a00103b280da81e4c
per Jose's suggestion.
Just set the SVGA3dSurfaceFormatCaps flags for 3D and cube textures
when checking the texture format capabilities. This will filter out
unsupported combinations like 3D+DXT.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Refine 8c533022. Provide a stub __glXGetCurrentContext() function when
$(DEFINES) are such that it is not a macro.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
We were always passing PIPE_TEXTURE_2D, but not all formats are
supported for all types of textures. In particular, the driver may
not supported texture compression for all types of textures.
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
v2: Don't go to extra work to avoid extraneous flushes. (Previous
experiments in the kernel have suggested that flushing the pipeline
when it is already empty is extremely cheap).
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Add new OSMesaPostprocess() function to allow using the gallium
postprocessing filters. This only works for OSMesa with gallium
drivers, not the legacy swrast OSMesa.
Bump OSMESA_MAJOR/MINOR_VERSION numbers to 10.0
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Move private data structures and function prototypes out of the
public postprocess.h header file.
Create a pp_private.h for the shared, private data structures, functions.
Remove pp_program.h header.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
- Indent items under a GL version to allow context diffs to do their work.
- Move complete drivers into the GL version line - this should make the
stuff a little bit easier to read.
v2: keep the fd.o link (Emil Velikov)
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Joerg Mayer <jmayer@loplof.de>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The above two variables are unused as of commit
commit 024fe6852a
Author: Tom Stellard <thomas.stellard@amd.com>
Date: Tue Apr 2 10:42:50 2013 -0700
radeon/llvm: Use LLVM C API for compiling LLVM IR to ISA v2
which removed the only cpp file from drivers/radeon, but missed to
remove the CXXFLAGS. The sequential commit reintroduced and empty
LLVM_CPP_FILES.
Lets cleanup and remove both.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
If a performance monitor has never ended, then no result can be
available. Core Mesa can easily handle this, saving drivers a tiny bit
of complexity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
If a monitor has ended, it means a result should eventually become
available, pending some flushing.
This is distinct from !m->Active; if a monitor has not been started,
then m->Active == false and m->Ended == false.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The i965 implementation uses calloc, so I missed this. It's best to
simply initialize it to avoid requiring a zeroing allocator, though.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now that branch 10.0 is created, bump the minor version in
master.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We'll need this for Broadwell code as well.
Normally, when we make things public, we add the "brw" prefix. I'm not
crazy about that in this case, since it deals with prog_instruction.h's
SWIZZLE_XYZW values, rather than the BRW_SWIZZLE_XYZW enums. However,
I can't think of a better name, and at least the comments and code make
it clear.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
Broadwell code should not include brw_eu.h (since it is for Gen4-7
assembly encoding), but needs the URB write flags enum.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
Only Gen4 color write setup uses the force_sechalf flag, and it only
sets it on a single instruction. It also already has to get a pointer
to the instruction and manually set the saturate flag, so we may as well
just set force_sechalf the same way and avoid the complexity of a stack.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
Previous assumption was that the same set of flags can be reused
for both classic and gallium drivers. With megadriver work done
the classic drivers ended up using their own (single) instance of
the flags.
Move these into Automake.inc and rename to indicate that those
are gallium specific. Additionally silence an automake/autoconf
warning "XXX is not a standard libtool library name", due to
the parsing issues of the module tag.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Greatly reduce duplication and provide a sane minimum of
CFLAGS for all DRI targets.
Note: This commit adds VISIBILITY_CFLAGS to the following:
* freedreno
* i915
* ilo
* nouveau
* vmwgfx
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
In order to use the trace driver, one needs to define
GALLIUM_TRACE. Neither one of the two targets was
defining it, thus we're safe to remove libtrace.la.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Automake.inc already has GALLIUM_VIDEO_CFLAGS, which
provide the essential compiler flags needed.
Note: this commit adds VISIBILITY_CFLAGS to nouveau.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Cleanup the duplicating flags and consolidate into a sigle variable.
Note: this patch adds VISIBILITY_CFLAGS to the following targets
* freedreno/drm
* i915/{drm,sw}
* nouveau/drm
* sw/fbdev
* sw/null
* sw/wayland
* sw/wrapper
* sw/xlib
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
In order for one to use trace, noop, rbug and/or galahad, they must
set the corresponding GALLIUM_* CFLAG.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Store the compiler flags into a variable, in order to minimise
flags duplication (amongst vdpau and xvmc).
Note: this commit add VISIBILITY_CFLAGS to the nouveau target
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* minimise flags duplication
* distingush between VISIBILITY C and CXX flags
* set only required flags - C and/or CXX
v2: add LLVM_CFLAGS back to AM_CFLAGS (add missing backslash)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* Allow the lists to be shared among build systems.
* Update automake and Android build systems.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Nearly everything within the three Makefile.am's is identical.
Let's simplify things a little.
v2: Rebase and rewrite the commit message (Emil Velikov)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The array was 64kb per struct gl_program, plus we statically stored a copy
of one on disk for _mesa_DummyProgram. Given that most struct gl_programs
we generate are for GLSL shaders that don't have local parameters, this
was a waste.
Since you can store and fetch parameters beyond what the program actually
uses, we do have to do a late allocation if necessary at
GetProgramLocalParameter time.
Reduces peak memory usage in the dota2 trace I made by 76MB (4.5%)
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This has been replaced with referring to env parameters using
PROGRAM_STATE_VAR and _mesa_load_state_parameters.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This has been replaced with referring to local parameters using
PROGRAM_STATE_VAR and _mesa_load_state_parameters.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Notably, ENV and LOCAL aren't used any more (replaced by STATE_VAR), but
apparently CONSTANT is.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The comment was stale, because the lowering in question wasn't happening
in lower_instructions.cpp. Presumably if the lowering ever moves there,
we can plumb the lowering mask through to opt_algebraic.
total instructions in shared programs: 1618696 -> 1616810 (-0.12%)
instructions in affected programs: 243018 -> 241132 (-0.78%)
GAINED: 0
LOST: 0
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Previously, brw_new_batch was called just after execbuf, but before
intel_batchbuffer_reset. Essentially, it prepared for the creation of a
new batch, that wasn't yet available, and which it didn't create. This
was a bit awkward.
This patch makes brw_new_batch call intel_batchbuffer_reset as the very
first operation. This means that brw_new_batch actually creates a new
batchbuffer, and thus has it available. It brings the creation of the
new batchbuffer and BRW_NEW_BATCH flagging together into one place.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
More rebase fail. This code was written long before i915 and i965 were
split, so most of the code in i9[16]5/intel_screen.c only needed to
exist in one place. It looks like I fixed n-1 of those places after
rebasing on the split.
I only found this from the defined-but-not-used warning for
intelRendererQueryExtension. I noticed this while fixing the other,
related warnings.
(Note: During review, we decided to *not* pick this back to 10.0.)
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
radeon_llvm_compile allocates memory for binary.code, binary.config,
or neither depending on what's being done.
We need to make sure to free that memory after it's no longer needed.
v2: Don't bother checking for null before FREE()
CC: "10.0" <mesa-stable@lists.freedesktop.org>
use memset to initialize to 0's... otherwise code_size and config_size
could be uninitialized when read later in this method.
It's also hard to do NULL checks on uninitialized pointers.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
v2: Fix indentation
CC: "10.0" <mesa-stable@lists.freedesktop.org>
For DX9-level shaders, there's only limited support for indirect
indexing of registers (with the loop counter register, not the
general address register.)
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
After we blit/copy to a dest texture image we need to mark it as
being defined. This fixes broken mipmap generation for quite a
few texture formats. Mipgen involves making texture views and
svga_texture_view_surface() skips texture images that are undefined.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The index translation code expects the number of indexes to be
consistent with the primitive type (ex: a multiple of 3 for
PIPE_PRIM_TRIANGLES). If it's not, we can write out of bounds
in the destination buffer.
Fixes failed assertions in the pipebuffer debug code found with
Piglit primitive-restart-draw-mode test.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Previously, when doing intrastage and interstage interface block
linking, we only checked the interface type; this prevented us from
catching some link errors.
We now check the following additional constraints:
- For intrastage linking, the presence/absence of interface names must
match.
- For shader ins/outs, the interface names themselves must match when
doing intrastage linking (note: it's not clear from the spec whether
this is necessary, but Mesa's implementation currently relies on
it).
- Array vs. nonarray must be consistent, taking into account the
special rules for vertex-geometry linkage.
- Array sizes must be consistent (exception: during intrastage
linking, an unsized array matches a sized array).
Note: validate_interstage_interface_blocks currently handles both
uniforms and in/out variables. As a result, if all three shader types
are present (VS, GS, and FS), and a uniform interface block is
mentioned in the VS and FS but not the GS, it won't be validated. I
plan to address this in later patches.
Fixes the following piglit tests in spec/glsl-1.50/linker:
- interface-blocks-vs-fs-array-size-mismatch
- interface-vs-array-to-fs-unnamed
- interface-vs-unnamed-to-fs-array
- intrastage-interface-unnamed-array
v2: Simplify logic in intrastage_match() for handling array sizes.
Make extra_array_level const. Use an unnamed temporary
interface_block_definition in validate_interstage_interface_blocks()'s
first call to definitions->store().
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
From the Sandy Bridge PRM, Vol 1 Part 1 7.18.3.4 (Alignment Unit
Size):
j [vertical alignment] = 4 for any render target surface is
multisampled (4x)
From the Ivy Bridge PRM, Vol 4 Part 1 2.12.2.1 (SURFACE_STATE for most
messages), under the "Surface Vertical Alignment" heading:
This field is intended to be set to VALIGN_4 if the surface was
rendered as a depth buffer, for a multisampled (4x) render target,
or for a multisampled (8x) render target, since these surfaces
support only alignment of 4.
Back in 2012 when we added multisampling support to the i965 driver,
we forgot to update the logic for computing the vertical alignment, so
we were often using a vertical alignment of 2 for multisampled
buffers, leading to subtle rendering errors.
Note that the specs also require a vertical alignment of 4 for all
Y-tiled render target surfaces; I plan to address that in a separate
patch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53077
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
For both vertex and fragment shaders we default MaxUniformComponents
to 4 * MAX_UNIFORMS. It makes sense to do this for geometry shaders
too; if back-ends have different limits they can override them as
necessary.
Fixes piglit test:
spec/glsl-1.50/built-in constants/gl_MaxGeometryUniformComponents
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* Inherit gl_context so we always have access to it
* Thanks curro for the idea.
* Last Haiku cannidate for 10.0.0
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The debug printfs wouldn't actually compile when enabled, so kill them off
and insert some new one in another place, and make sure it keeps compiling
by enclosing it in a if-0 clause.
In particular get rid of home-grown vector helpers which didn't add much.
And while here fix formatting a bit. No functional change.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
d3d10 requires us to convert NaNs to zero for any float->int conversion.
We don't really do that but mostly seems to work. In particular I suspect the
very common float->unorm8 path only really passes because it relies on sse2
pack intrinsics which just happen to work by luck for NaNs (float->int
conversion in hw gives integer indeterminate value, which just happens to be
-0x80000000 hence gets converted to zero in the end after pack intrinsics).
However, float->srgb didn't get so lucky, because we need to clamp before
blending and clamping resulted in NaN behavior being undefined (and actually
got converted to 1.0 by clamping with sse2). Fix this by using a zero/one clamp
with defined nan behavior as we can handle the NaN for free this way.
I suspect there's more bugs lurking in this area (e.g. converting floats to
snorm) as we don't really use defined NaN behavior everywhere but this seems
to be good enough.
While here respecify nan behavior modes a bit, in particular the return_second
mode didn't really do what we wanted. From the caller's perspective, we really
wanted to say we need the non-nan result, but we already know the second arg
isn't a NaN. So we use this now instead, which means that cpu architectures
which actually implement min/max by always returning non-nan (that is adhering
to ieee754-2008 rules) don't need to bend over backwards for nothing.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Systems with little physical memory installed will report less than
2GiB, and some systems may (hypothetically?) have a larger address space
for the GPU. My IVB still reports 1534.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
This patch implements accelerated path for glDrawPixels from a PBO in
i965. The code follows what intel_pixel_read, intel_pixel_copy,
intel_pixel_bitmap and intel_tex_image are doing. Piglit quick.tests
show no regressions. In my testing on IVB, performance improvement is
huge (about 30x, didn't measure exactly) since generic path goes via
_mesa_unpack_color_span_float, memcpy, extract_float_rgba.
Signed-off-by: Alexander Monakov <amonakov@ispras.ru>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
createContextAttribs is a superset of what createNewContext provides.
Also remove the function typedef, since createNewContext is deprecated
and no longer used in multiple interfaces.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
This lets us allocate color buffers as __DRIimages and pass them into
the driver instead of having to create a __DRIbuffer with the flink
that requires.
With this patch, we can now run gbm on render-nodes. A render-node is a
drm device that doesn't support modesetting and all the legacy DRI ioctls.
flink is also not supported, but now that gbm doesn't need flink, we can
run piglit on head-less gbm or head-less GPGPU.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Since LIFO fails on some shaders in one particular way, and non-LIFO
systematically fails in another way on different kinds of shaders, try
them both, and pick whichever one successfully register allocates first.
Slightly prefer non-LIFO in case we produce extra dependencies in register
allocation, since it should start out with fewer stalls than LIFO.
This is madness, but I haven't come up with another way to get unigine
tropics to not spill while keeping other programs from not spilling and
retaining the non-unigine performance wins from texture-grf.
total instructions in shared programs: 1626728 -> 1626288 (-0.03%)
instructions in affected programs: 1015 -> 575 (-43.35%)
GAINED: 50
LOST: 0
Improves Unigine Tropics performance by 14.5257% +/- 0.241838% (n=38)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70445
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Long ago, the HW_REG usage in assign_curb/urb_setup() were scheduling
barriers, so we had to run scheduler before them in order for it to be
able to do basically anything. Now that that's fixed, we can delay the
scheduling until we go to allocate (which will make the next change less
scary).
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We care about depth-until-program-end, as a proxy for "make sure I
schedule those early instructions that open up the other things that can
make progress while keeping register pressure low", not actual latency
(since we're relying on the post-register-alloc scheduling to actually
schedule for the hardware).
total instructions in shared programs: 1609931 -> 1609931 (0.00%)
instructions in affected programs: 0 -> 0
GAINED: 55
LOST: 43
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
In the SIMD16 spilling changes, I replaced a "1" in the spill path with
"mlen", but obviously it wasn't mlen before because spills have the g0
header along with the payload. The interface I was trying to use was
asking for how many physical regs we're writing, so we're looking for "1"
or "2".
I'm guessing this actually passed piglit because the high 8 bits of the
execution mask in SIMD8 mode are all 0s.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Previously, the best thing we had was to schedule the things unblocked by
the last chosen instruction, on the hope that it would be consuming two
values at the end of their live intervals while only producing one new
value. But that's just a guess, and we can do counting of usage of
registers to know when an instruction would (almost surely) reduce
register pressure.
The only failure mode I know of in this new dominant heuristic is that
inside of a loop when scheduling the iterator (for example), choosing the
last use of the iterator doesn't actually reduce the live interval of the
iterator. But it doesn't seem to matter in shader-db:
total instructions in shared programs: 1618700 -> 1618700 (0.00%)
instructions in affected programs: 0 -> 0
GAINED: 13
LOST: 0
Note: The new functions are made virtual because I expect we'll soon lift
the pre-regalloc scheduling heuristic over to the vec4 backend.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes infinite loop in find_grid_optimal_factor() in cases where the
user specifies a grid size with less dimensions than the device
supports.
Reported-by: Tom Stellard <thomas.stellard@amd.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Since we explicitly require a integer input we should avoid using exp2 math
(even if we were using optimized versions), which turns the exp2 into a int
sub (plus some casts).
v2: fix bogus uint (needs to be int) math spotted by Matthew, fix comments
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Otherwise, the function would enable generic vertex attributes 0
and 1 of the array object it does not own. This was causing crashes
in Euro Truck Simulator 2, since the incorrectly enabled generic
attribute 0 in the foreign context got precedence before vertex
position attribute at later time, leading to NULL pointer dereference.
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Petr Sebor <petr@scssoft.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Adding a vl_mpeg-based helper didn't seem to work, as it produced data
that the card couldn't handle. (And I didn't investigate further.) This
makes the decoding functionality only accessible via XvMC and avoids
crashes when attempting to use VDPAU.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
This fixes a crash in glamor when mesa links against static LLVM.
v2:
- Inline LINKER_SCRIPT variable
v3: Kai Wasserbäch
- Fix out out-of-tree-builds
Tested-by: Kai Wasserbäch <kai@dev.carbon-project.or>
This makes it possible to use clover with statically linked LLVM.
v2:
- Inline LINKER_SCRIPT variable
v3: Kai Wasserbäch
- Fix out out-of-tree-builds
Tested-by: Kai Wasserbäch <kai@dev.carbon-project.or>
X_f, Y_f, Xp_f, Yp_f variables are used just inside
translate_dst_to_src().So, they can be defined just
as local variables.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
When this function was added, the returned value was signed in some
places, unsigned in others.
v2: also add unsigned in the unit test, per Ian.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, we would bogusly replace the entire statement containing the
ir_texture node with an ir_dereference_variable.
Correct this to just replace the ir_texture node itself as intended.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Commit b16b3c87 began performing CSE on CMP instructions with null
destinations. I relaxed the restrictions a bit too much, thereby
allowing CSE to be performed on instructions with, for instance, an
explicit accumulator destination.
This broke the arb_gpu_shader5/fs-imulExtended shader tests because
they emit MUL instructions with the accumulator as the destination. CSE
would instead cause the MUL to write to a GRF, which is lower precision
than the accumulator.
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: 10.0 <mesa-stable@lists.freedesktop.org>
Uses the __DRIimage loader interfaces.
v2: Fix _XIOErrors when DRI3 isn't present (change by anholt). Apparently
XCB just terminates your connection if you don't check for extensions
before using them, instead of returning an error like you'd expect.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
These provide an interface between the driver and the loader to allocate
color buffers through the DRIimage extension interface rather than through a
loader-specific extension (as is used by DRI2, for instance).
The driver uses the loader 'getBuffers' interface to allocate color buffers.
The loader uses the createNewScreen2, createNewDrawable, createNewContext,
getAPIMask and createContextAttribs APIS (mostly shared with DRI2).
This interface will work with the DRI3 loader, and should also work with GBM
and other loaders so that drivers need not be customized for each new loader
interface, as long as they provide this image interface.
v2: Fix build of i915 and i965 together (by anholt)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
The __DRI_IMAGE_FORMAT codes are used by the image extension, drivers need to
be able to translate between them. Instead of duplicating this translation in
each driver, create a shared version.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Instead of assuming that the size will be height * pitch, have the caller pass
in the size explicitly.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
This just renames them so that they can be used with the DRI3 extension
without causing too much confusion.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
There's only one minor functional change, for immediates the pixel offsets
are no longer added since the values are all the same for all elements in
any case (it might be better if those weren't stored as soa vectors in the
first place maybe).
Reviewed-by: Zack Rusin <zackr@vmware.com>
After adding $(DEFINES) to AM_CPPFLAGS, the __glXGetCurrentContext
wrapper function is no longer needed and causes compile errors. Using
the correct defines causes it to be a macro!
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
These tests primarilly ensure that the functions added by this extension
don't abuse other interfaces (e.g., glx_screen::query_renderer_integer)
when provided bad data.
These tests helped me find a couple small bugs in the initial
implementation.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
The enumerated values are currently allocated from Intel's range.
v2: Fix a typo. Update the list of functions to which the new enums can
be passed. The "Current" versions were previously missing. Both things
noticed by Marek.
v3: Fix typo in return type of glXQueryRendererIntegerMESA in the spec
body (noticed by Ken). Fix typo in issue #14 referencing itself instead
of issue #13 (noticed by Dave).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Dave Airlie <airlied@redhat.com>
The new functions for this extension were added to a separate file
(dri2_query_renderer.c) to facilitate unit testing. I tried putting
them in dri2_glx.c, and it resulting in an unending chain of
dependencies. It was the proverbial threading hanging from a sweater.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This structures will be accessed by internal functions that will be
added in a file separate from dri2_glx.c. The new code will be added to
a new file to facilitate unit testing.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Use sysconf instead of sysinfo for improved portability. Suggested
by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Use sysconf instead of sysinfo for improved portability. Suggested
by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Add assertions that the version string has the expected format.
This will catch build errors (or changes to the version string format)
in debug build without exposing release builds to buffer over-runs.
Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will soon be used in intel_screen.c from a function that doesn't
have a gl_context.
v2: Delete local variables that are now unused. This matches v1 of the
changes to the i915 driver.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will soon be used in intel_screen.c from a function that doesn't
have a gl_context.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will soon be used in intel_screen.c from a function that doesn't
have a gl_context.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will soon be used in intel_screen.c from a function that doesn't
have a gl_context.
v2: Remove spurious break after return.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will be used to let apps query hardware and driver limits before
creating a GL context.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If the application requests reset notifiction, connect up the reset
status query method and set gl_context::ResetStrategy.
v2: Update based on kernel interface / libdrm changes.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Soon some drivers will support a different set of flags than other
drivers. If some flags have to be filtered in the driver, we might as
well filter all of them in the driver.
The changes in nouveau use tabs because nouveau seems to have it's own
indentation rules.
v2: Fix some rebase failures noticed by Ken (returning the wrong types,
etc.).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
No drivers advertise the DRI2 extension yet, so no driver should ever
see a value other than false for notify_reset.
The changes in nouveau use tabs because nouveau seems to have it's own
indentation rules.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Drivers still have to implement dd_function_table::GetGraphicsResetStatus.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
These will be used to determine whether to signal a GPU reset after
another context in the share group has observed a reset.
v2: Change ShareGroupReset from GLboolean to bool. Suggested by Brian.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This allows drivers to determine whether a GPU reset has occured. It
should return non-zero status if a reset was observed by the specified
context. Another mechanism will be used to observe resets occuring in
other contexts in the share group.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This isn't going to be used in the actual implemenation of
glGetGraphicsResetStatus.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: Add comments on the purpose of the auxiliary data structures.
Check for atomic counter overlaps. Use the contains_atomic()
convenience method. Add static assert with the number of expected
shader stages.
v3: Don't resize atomic arrays.
v4: Add comment on the reason why we don't resize atomic counter
arrays. Use 'strcmp(...) == 0' instead of '!strcmp(...)'.
v5 (idr): Don't use STL in the linker.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v2: Mark atomic counters as read-only variables. Move offset overlap
code to the linker. Use the contains_atomic() convenience method.
v3: Use pointer to integer instead of non-const reference. Add
comment so we remember to add a spec quotation from the next GLSL
release once the issue of atomic counter aggregation within
structures is clarified.
v4 (idr): Don't use std::map because it's overkill. Add an assertion
that ctx->Const.MaxAtomicBufferBindings <= MAX_COMBINED_ATOMIC_BUFFERS.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This reverts most of commit 0f2da77307.
(I chose to leave the additions to brw_defines.h.)
My previous Ironlake implementation was somewhat broken: counter data
was global, rather than per-context. This meant that performance
monitors captured data from your compositor, 2D driver, and other 3D
programs.
Originally, I believed that Sandybridge and later had an easy way to
avoid this problem (setting per-context flags in OACONTROL), while
Ironlake did not. So I'd intended to leave it as a known limitation of
performance monitoring support on Ironlake. However, this turned out
not to be true.
Unfortunately, our hardware only has one set of aggregating performance
counters shared between all 3D programs, and their values are not saved
or restored by hardware contexts. Also, at least on Sandybridge and
Ivybridge, the counters lose their values if the GPU goes to sleep.
To work around both of these problems, we have to snapshot the
performance counters at the beginning and end of each batch, similar to
how we handle query objects on platforms that don't support hardware
contexts.
For occlusion queries, this batch bookending approach is fairly simple:
only one occlusion query can be active at a time, and the result is a
single integer. Performance monitors are more complex: an arbitrary
number of monitors can be active at a time, each monitoring some subset
of our ~30 observability counters. Individual monitors can be started
and stopped at any point during the batch. Tracking where each monitor
started/ended relative to batch flushes ends up being a pain. And you
can run out of space in the buffer.
Properly supporting this required some serious rearchitecting of the
code. Rather than writing patches to try and morph a broken system into
a working one (which operates quite differently), I decided it would be
simplest to revert the old code and start fresh. Parts will look
familiar, but other parts are new.
I also decided it would be best to include Sandybridge and Ivybridge
support from the start, since the newer platforms have added complexity
that I wanted to make sure worked. They're also what most people care
about these days.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we only exposed them in desktop GL or with:
#extension GL_OES_standard_derivatives : enable
GLSL ES 3.00 includes these without an extension, so we need to expose
them by default.
Note that the above #extension line results in an error or desktop GL,
so we don't need to worry about this.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This just tells the state tracker to turn on the GL_ARB_shader_texture_lod
extension. This simply allows the GLSL compiler to emit TXL and TXD
instructions for both vertex and fragment shaders. We already support
these opcodes in the svga driver. Though, the shadow2DGrad() Piglit
tests are failing.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Improves performance of RoboHornet's 2D Canvas toDataURL benchmark
[http://www.robohornet.org/#e=canvastodataurl] by approximately 5x
on Baytrail on ChromiumOS.
Elapsed time drops by -81.4861% +/- 1.22619% (n=3 s=14.9105, confidence=95%).
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Uses SSE 4.1's MOVNTDQA instruction (streaming load) to read from
uncached memory without polluting the cache.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This patch make changes to correctly set up the Dispatch GRF Start
Register in case of 'SIMD16 only' FS dispatch.
This fixes an issue of incorrect rendering on dolphin emulator with
GL_SAMPLE_SHADING enabled.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This theoretically works on earlier hardware as well, but the extension
requires at least GL3.0.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
V2: fix interaction with VertexAttribFormat, since that landed after
this was originally written
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
With this patch, the llvmpipe and draw modules will calculate the depth bias
according to floating point depth buffer semantics described in the
arb_depth_buffer_float specification, when the driver has a z buffer bound
with a format type of UTIL_FORMAT_TYPE_FLOAT.
By default, the driver will use the existing UNORM calculation for depth bias.
A new function, draw_set_zs_format, was added to calculate the Minimum
Resolvable Depth value and floating point depth sense for the draw module.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This brings over the batch-wrap-prevention and aperture space checking
code from the normal brw_draw.c path, so that we don't need to flush the
batch every time.
There's a risk here if the intel_emit_post_sync_nonzero_flush() call isn't
high enough up in the state emit sequences -- before, we implicitly had
one at the batch flush before any state was emitted, so Mesa's workaround
emits didn't really matter. Since the SNB fixes by Ken, I didn't see any
regressions after 3 piglit runs.
Improves cairo-gl performance by 13.7733% +/- 1.74876% (n=30/32)
Improves minecraft apitrace performance by 1.03183% +/- 0.482297% (n=90).
Reduces low-resolution GLB 2.7 performance by 1.17553% +/- 0.432263% (n=88)
Reduces Lightsmark performance by 3.70246% +/- 0.322432% (n=126)
No statistically significant performance difference on unigine tropics
(n=10)
No statistically significant performance difference on openarena (n=755)
The two apps that are hurt happen to include stalls on busy buffer
objects, so I think this is an effect of missing out on an opportune
flush.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
update_array() and update_array_format() are changed to update the new
attrib and binding states, and the client arrays become derived state.
Reviewed-by: Eric Anholt <eric@anholt.net>
...and rename it to _mesa_bind_buffer_gen().
This is so the function can be called from _mesa_BindVertexBuffer().
This patch also adds a caller parameter so we can report the right
entry point in error messages.
Based on a patch by Eric Anholt.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This will become derived state as part of the ARB_vertex_attrib_binding
support.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Split out the code for updating the array format into a new function
called update_array_format(). This function will be called by both
update_array() and the new glVertexAttrib*Format() entry points in
ARB_vertex_attrib_binding.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Currently, has_surface_tile_offset is equivalent to gen == 4 && !is_g4x.
We already use it for related checks in brw_wm_surface_state.c, so it
makes sense to use it here too. It's simpler and more future-proof.
Broadwell also lacks surface tile offsets. With this patch, I won't
need to update any generation checking; I can simply not set the flag.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Hardware docs say we can only use SIMD8 dispatch in this condition.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
We weren't adding the soa offsets when constructing the indices
for the gather functions. That meant that we were always returning
the data in the first element.
(Copied straight from the same fix for temps.)
While here fix up a couple of broken comments in the fetch functions,
plus don't name a straight float type float4 which is just confusing.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Otherwise OutputSurface interop has funny results sometimes.
This fixes interop with the mpv media player.
v2 (chk): add proper locking
Signed-off-by: Christian König <christian.koenig@amd.com>
V2: Add comment explaining what emit_alpha_test() is for;
fix spurious temp and bogus whitespace.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
The same setup is required here as when the user-provided shader
explicitly uses KIL or discard.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
We have to do this in the shader instead, since these gens lack an
independent RT0 alpha value in their render target write messages.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that brw_update_texture_buffer_surface() uses the virtual
emit_buffer_surface_state() function, it works for Gen7+ too.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Now that brw_create_constant_surface uses a virtual function internally,
it doesn't need to be virtual itself. We can delete the Gen7+ variant
and simplify things.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This will allow us to combine the Gen4-6 and Gen7 variants of these
functions.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This entails adding "mocs" and "rw" parameters to the Gen4-5 version.
I made it actually pay attention to the rw flag (even though it is
always false), but mocs is always ignored.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
fix: intel_screen.c:1320:4: warning: initialization from
incompatible pointer type [enabled by default]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Before the series with 3c9dc2d31b to
dynamically assign our binding table indices, we didn't really track our
binding table count per shader, so we never filled in these fields.
Affects cairo-gl trace runtime by -2.47953% +/- 1.07281% (n=20)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
SSE can't handle true vector shifts (with variable shift count),
so llvm is turning them into a mess of extracts, scalar shifts and inserts.
It is however possible to emulate them in lp_build_minify with float muls,
which should be way faster (saves over 20 instructions per 8-wide
lp_build_minify). This wouldn't work for "generic" 32bit shifts though
since we've got only 24bits of mantissa (actually for left shifts it would
work by using sse41 int mul instead of float mul but not for right shifts).
Note that this has very limited scope for now, since this is only used with
per-pixel lod (otherwise we're avoiding the non-constant shift count by doing
per-quad shifts manually), and only 1d textures even then (though the latter
should change).
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This will enable removing the dd_function_table::Scissor hook in the
near future.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This will enable removing the dd_function_table::DepthRange hook in the
near future.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The x, y, width, and height parameters aren't used by radeon_viewport,
so don't pass them. This should make future changes to the
dd_function_table::Viewport interface a little easier.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jljusten@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Courtney Goeltzenleuchter <courtney@lunarg.com>
The i830 and the i915 driver have the same dd_function_table::Viewport
function... it just has two names and lives in two places. Using a
single implementation allows cleaning up the saved_viewport nonsense
too.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jljusten@gmail.com>
Cc: Courtney Goeltzenleuchter <courtney@lunarg.com>
The i965 driver never installed a dd_function_table::Viewport function,
so this wrapper never actually did anything.
No piglit regressions on IVB on DRI2.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jljusten@gmail.com>
Cc: Courtney Goeltzenleuchter <courtney@lunarg.com>
* Goodbye BeOS, we hardly knew thee
* As BeOS was gcc2 only, there was little chance
of this being useful.
* Doesn't effect Haiku in any meaningful way
Reviewed-by: Brian Paul <brianp@vmware.com>
Previously, when packing geometry shader input varyings like this:
in float foo[3];
in float bar[3];
lower_packed_varyings would declare a packed varying like this:
(declare (shader_in flat) (array ivec4 3) packed:foo[0],bar[0])
That's confusing, since the packed varying acutally stores all three
values of foo and all three values of bar.
This patch causes it to generate the more sensible declaration:
(declare (shader_in flat) (array ivec4 3) packed:foo,bar)
Note that there should be no functional change for users of geometry
shaders, since the packed name is only used for generating debug
output. But this should reduce confusion when using INTEL_DEBUG=gs.
Reviewed-by: Eric Anholt <eric@anholt.net>
* Call mesa viewport call on winndow resize
* Add initial postprocessing code
* Pass hgl_context to private statetracker
as it is more useful than GalliumContext
* Use Lock and Unlock functions to standardize
GalliumContext locking
* Create texture resources in texture validation
Acked-by: Brian Paul <brianp@vmware.com>
The changes between Gen6-7 are minimal, and can easily be solved with
an extra generation check. This cuts a lot of duplicated code.
It also helps prevent even more duplication for Broadwell.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The latency information has been obtained empirically from
measurements taken on Haswell and Ivy Bridge.
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This can deal with all the 15 32-bit untyped atomic operations the
hardware supports, but only INC and PREDEC are going to be exposed
through the API for now.
v2: Represent atomics as GLSL intrinsics. Add support for variably
indexed atomic counter arrays.
v3: Add comment on why we don't need to assign uniform storage for
atomic counters.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This can deal with all the 15 32-bit untyped atomic operations the
hardware supports, but only INC and PREDEC are going to be exposed
through the API for now.
v2: Represent atomics as GLSL intrinsics. Add support for variably
indexed atomic counter arrays. Fix interaction with fragment
discard.
v3: Add comment on why we don't need to assign uniform storage for
atomic counters.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This patch fixes the three dead code elimination passes and the
VEC4/FS instruction scheduling passes so they leave instructions with
side effects alone.
At some point it might be interesting to have the instruction
scheduler calculate the exact memory dependencies between atomic ops,
but they're rare enough that it seems unlikely that it will make any
practical difference.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Inspired by a patch sent to the mailing list by Tom Stellard, but
using a different algorithm to calculate the optimal block size that
has been found to be considerably more effective.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
dso_list was added as an argument for createInternalizePass in 3.4, and then
it was removed again in the same llvm version.
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
The new option clamps GL_MAX_SAMPLES to a hardware-supported MSAA mode.
If negative, then no clamping occurs.
v2: (for Paul)
- Add option to i965 only, not to all DRI drivers.
- Do not realy on int->uint cast to convert negative
values to large positive values. Explicitly check for
clamp_max_samples < 0.
v3: (for Ken)
- Don't allow clamp_max_samples to alter context version.
- Use clearer for-loop and correct comment.
- Rename variables.
v4: (for Ken)
- Merge identical if-branches.
Reviewed-and-tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Actually link VS out / FS in based on semantic info, keeping in mind
that position/pointsize can also be an input to the FS. This fixes a
few fragment shaders which were using gl_Position.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Fixes use of full-precision in fragment shader (ie. don't clobber r0.x
since that can be used by future bary instructions for varying fetch).
And makes use of full-precision the default in fragment shader (but can
be overriden via FD_MESA_DEBUG=fraghalf).
Seems like half precision is often not enough for texture coordinates.
The blob compiler is clever enough to keep texture coords in full
precision registers while using half precision for everything else. But
we aren't quite that clever yet, so better to default to full precision.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Handle some relative addressing constraints: cannot handle const or
relative in cat5 and src2 of cat3.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
- Enable GEN7_WM_MSDISPMODE_PERSAMPLE, GEN7_WM_POSOFFSET_SAMPLE,
GEN7_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
- Only enable one of GEN7_WM_8_DISPATCH_ENABLE or GEN7_WM_16_DISPATCH_ENABLE
when GEN7_WM_MSDISPMODE_PERSAMPLE is enabled. Refer IVB PRM Vol. 2, Part 1,
Page 288 for details.
V2:
- Use shared function _mesa_get_min_invocations_per_fragment().
- Use brw_wm_prog_data variables: uses_pos_offset, uses_omask.
V3:
- Enable simd16 dispatch with per sample shading.
- Make changes to give preference to 'simd16 only' mode over
'simd8 only' mode in case of non 1x per sample shading.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
- Enable GEN6_WM_MSDISPMODE_PERSAMPLE, GEN6_WM_POSOFFSET_SAMPLE,
GEN6_WM_OMASK_TO_RENDER_TARGET as per extension's specification.
- Only enable one of GEN6_WM_8_DISPATCH_ENABLE or GEN6_WM_16_DISPATCH_ENABLE
when GEN6_WM_MSDISPMODE_PERSAMPLE is enabled.
Refer SNB PRM Vol. 2, Part 1, Page 279 for details.
V2:
- Use shared function _mesa_get_min_invocations_per_fragment().
- Use brw_wm_prog_data variables: uses_pos_offset, uses_omask.
V3:
- Enable simd16 dispatch with per sample shading.
- Make changes to give preference to 'simd16 only' mode over
'simd8 only' mode in case of non 1x per sample shading.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
V2:
- Update comments
- Add a special backend instructions to compute sample_mask.
- Add a new variable uses_omask in brw_wm_prog_data.
V3:
- Make changes to support simd16 mode.
- Delete redundant AND instruction and handle the register
stride in FS backend instruction.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
V2:
- Update comments
- Add compute_sample_id variables in brw_wm_prog_key
- Add a special backend instruction to compute sample_id.
V3:
- Make changes to support simd16 mode.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This is required while adding builtin system value vec{2, 3, 4}
variables. For example:
(declare (sys) vec2 gl_SamplePosition)
Without this patch above glsl ir splits in to:
(declare (temporary) float gl_SamplePosition_x)
(declare (temporary) float gl_SamplePosition_y)
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This function is used to test if we need to do per sample shading or
per fragment shading.
V2: Use MAX2() to make sure the function returns a number >= 1.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
New builtins added by GL_ARB_sample_shading:
in vec2 gl_SamplePosition
in int gl_SampleID
in int gl_NumSamples
out int gl_SampleMask[]
V2: - Use SWIZZLE_XXXX for STATE_NUM_SAMPLES.
- Use "result.samplemask" in arb_output_attrib_string.
- Add comment to explain the size of gl_SampleMask[] array.
- Make gl_SampleID and gl_SamplePosition system values.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Number of samples will be required in fragment shader program by new
GLSL builtin uniform "gl_NumSamples".
V2: Use "state.numsamples" in place of "state.num.samples"
Use _NEW_BUFFERS flag in place of _NEW_MULTISAMPLE
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Ken Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
New functions added by GL_ARB_sample_shading:
glMinSampleShadingARB()
New enums:
GL_SAMPLE_SHADING_ARB
GL_MIN_SAMPLE_SHADING_VALUE_ARB
V2: Update comments.
Create new GL4x.xml.
Remove redundant code in get.c.
Update the API_XML list in Makefile.am.
Add extra_gl40_ARB_sample_shading predicate to get.c.
V3:
Fix make check failure.
Add checks for desktop GL.
Use GLfloat in place of GLclampf in glMinSampleShading().
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ken Graunke <kenneth@whitecape.org>
This patch implements the common support code required for the
GL_ARB_sample_shading extension.
V2: Move GL_ARB_sample_shading to ARB extension list.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Ken Graunke <kenneth@whitecape.org>
Only one program's instruction count is changed, but a shader in Tropics
is also affected.
instructions in affected programs: 326 -> 320 (-1.84%)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
total instructions in shared programs: 1409124 -> 1406971 (-0.15%)
instructions in affected programs: 158376 -> 156223 (-1.36%)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Helps a lot of Steam games.
total instructions in shared programs: 1409360 -> 1409124 (-0.02%)
instructions in affected programs: 20842 -> 20606 (-1.13%)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This only operates on constant/uniform values for now, because otherwise I'd
have to deal with killing my available CSE entries when assignments happen,
and getting even this working in the tree ir was painful enough.
As is, it has the following effect in shader-db:
total instructions in shared programs: 1524077 -> 1521964 (-0.14%)
instructions in affected programs: 50629 -> 48516 (-4.17%)
GAINED: 0
LOST: 0
And, for tropics, that accounts for most of the effect, the FPS
improvement is 11.67% +/- 0.72% (n=3).
v2: Use read_only field of the variable, manually check the lod_info union
members, use get_num_operands(), rename cse_operands_visitor to
is_cse_candidate_visitor, move all is-a-candidate logic to that
function, and call it before checking for CSE on a given rvalue, more
comments, use private keyword.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Prior to the GLSL CSE pass, all of our testing happened to have a freshly
computed temporary in op[1], from the multiply by 16 to get a byte offset.
As of CSE you'll get var_refs of a reused value when you've got multiple
loads from the same offset.
Make a proper temporary for computing our temporary value, to avoid
shifting the value farther and farther down. Avoids a regression in
gs-float-array-variable-index
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Previously, the write of each 32-bit half might land in separate batch
buffers, which is insane.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
This depends on ARB_transform_feedback2, so I've predicated it on the
ability to do register writes.
It also depends on ARB_transform_feedback3, which is the only reason we
couldn't expose it previously.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This extension is written a bit strangely. Although it introduces the
concept of multiple transform feedback streams, it doesn't actually
provide more than a single stream.
The ARB_gpu_shader5 extension is what introduces the ability to write to
streams other than stream #0 and increases the required number of streams.
Since we don't yet support ARB_gpu_shader5, we can safely enable
ARB_transform_feedback3 even though we only support a single stream.
This does provide some useful functionality: applications can now use
more than one interleaved transform feedback buffer.
v2: Only expose the extension if ARB_transform_feedback2 is also
available, to avoid confusing applications (suggested by Ian).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
ARB_transform_feedback3 allows applications to insert blank space
between interleaved varyings by adding fake 1, 2, 3, or 4-component
varyings named gl_SkipComponents[1234].
Mesa's core data structures don't explicitly track these, instead simply
tracking the buffer offset for each real varying. If there is padding
due to gl_SkipComponents, these will not be contiguous.
Our hardware takes the specification quite literally. Instead of
specifying offsets for each varying, it assumes they're all contiguous
and requires you to program fake varyings for each "hole".
This patch adds support for emitting SO_DECL structures for these holes.
Although we've lost the information about exactly how the application
specified their padding (i.e. gl_SkipComponents2, gl_SkipComponents2
vs. a single gl_SkipComponents4), it shouldn't matter. We just need to
emit the right amount of space. This patch emits the minimal number of
hole SO_DECL structures.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Currently, we emit one SO_DECL structure per output, so we use the index
in the Outputs[] array as the index into the so_decl[] array as well.
In order to support the fake "gl_SkipComponents[1234]" varyings from
ARB_transform_feedback3, we'll need to emit SO_DECLs to fill in the
holes between successive outputs. This means we'll likely emit more
SO_DECLs than there are outputs, so we need to count it explicitly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
With Linux 3.12, register writes work on Ivybridge and Baytrail, but not
Haswell. That will be fixed in a future kernel revision, at which point
this extension will automatically be enabled.
v2: Use I915_GEM_DOMAIN_INSTRUCTION for the register read, and also
correctly set the writeable flag when mapping (caught by Eric).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We only want to enable ARB_transform_feedback2 if we can write to
registers from batchbuffers. In order to test that, we need to be able
to submit batches. And for batches to work, we need to program the
initial pipeline state (like PIPELINE_SELECT), which is done from
brw_state_init().
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Implementing the GetTransformFeedbackVertexCount() driver hook allows
the VBO module to call us with the right number of vertices.
The hardware doesn't directly count the number of vertices written by
SOL, so we instead use the SO_NUM_PRIMS_WRITTEN(n) counters and multiply
by the number of vertices per primitive.
Unfortunately, counting the number of primitives generated is tricky:
a program might pause a transform feedback operation, start a second one
with a different object, then switch back and resume. Both transform
feedback operations share the SO_NUM_PRIMS_WRITTEN counters.
To work around this, we save the counter values at Begin, Pause, Resume,
and End. This "bookends" each section where transform feedback is
active for the current object. Adding up differences of pairs gives
us the number of primitives generated. (This is similar to what we
do for occlusion queries on platforms without hardware contexts.)
v2: Fix missing parenthesis in assertion (caught by Eric Anholt).
v3: Reuse prim_count_bo rather than freeing it and immediately
allocating a new one (suggested by Topi Pohjolainen).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Renaming it makes it obvious that it isn't used, and the assertion
verifies that the VBO module never passes us such an object.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
DrawTransformFeedback() needs to obtain the number of vertices written
to a particular stream during the last Begin/EndTransformFeedback block.
The new driver hook returns exactly that information.
Gallium drivers already implement this by passing the transform feedback
object to the drawing function, counting the number of vertices written
on the GPU, and using draw indirect. This is efficient, but doesn't
always work:
If vertex data comes from user arrays, then the VBO module needs to
know how many vertices to upload, so we need to synchronously count.
Gallium drivers are currently broken in this case.
It also doesn't work if primitive restart is done in software. For
normal drawing, vbo_draw_arrays() performs software primitive restart,
splitting the draw call in two. vbo_draw_transform_feedback() currently
doesn't because it has no idea how many vertices need to be drawn.
The new driver hook gives it that information, allowing us to reuse
the existing vbo_draw_arrays() code to do everything right.
On Intel hardware (at least Ivybridge), using the draw indirect approach
is difficult since the hardware counts primitives, rather than vertices,
which requires doing some simple math. So we always use this hook.
Gallium drivers will likely want to use this hook in some cases, but
want to use the existing draw indirect approach where possible. Hence,
I've added a flag to allow drivers to opt-in to this call.
v2: Make it possible to implement this hook but only use this path
when necessary (suggested by Marek).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The ARB_transform_feedback2 extension introduces the ability to pause
and resume transform feedback sessions. Although only one can be active
at a time, it's possible to switch between multiple transform feedback
objects while paused.
In order to facilitate this, we need to save/restore the SO_WRITE_OFFSET
registers so that after resuming, the GPU continues writing where it
left off.
This functionality also exists in ES 3.0, but somehow we completely
forgot to implement it.
v2: Reduce alignment from 4096 to 64 (it seemed excessive).
v3: Use I915_GEM_DOMAIN_INSTRUCTION instead of RENDER, for consistency
with other writes. It shouldn't matter on IVB+.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This adds the basic driver hooks to allocate/free the brw variant.
It doesn't contain any additional information yet, but it will soon.
v2: Use the new _mesa_init_transform_feedback_object helper function
(requested by Eric and Ian).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This picks up a missing obj->EverBound = GL_FALSE line, and will catch
any new fields that get added in the future.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Both Gallium and i965 subclass gl_transform_feedback_object, which
requires implementing a custom NewTransformFeedback hook. Creating a
helper function to initialize the fields avoids code duplication and
divergence.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We'd like to CSE some instructions, like CMP, that often have null
destinations. Instead of replacing them with MOVs to null, just don't
emit the MOV.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This avoids a lot of message setup we had to do otherwise. Improves
GLB2.7 performance with register spilling force enabled by 1.6442% +/-
0.553218% (n=4).
v2: Use BRW_PREDICATE_NONE, improve a comment (by Paul).
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We were clearing the reg_offset before trying to use it. Oops. Fixes
glsl-fs-texture2drect with the reg spilling debug enabled.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Things blew up when I enabled the debug register spill code without
disabling 16-wide, so I decided to just fix 16-wide spilling.
We still don't generate 16-wide when register spilling happens as part of
allocation (since we expect it to be slower), but now we can experiment
with allowing it in some cases in the future.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
I believe this will never happen in SIMD8 mode, but it could for SIMD16
when we fix it.
v2: Fix off-by-one in my register counting comment (caught by Paul).
Reviewed-by: Paul Berry <stereotype441@gmail.com> (v1)
Now that reg spilling generates new vgrfs, we were looping forever if you
ever turned it on.
Instead, move the debug code into the register allocator right near where
we'd be doing spilling anyway, which should more accurately reflect how
register spilling occurs in the wild.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
I'm going to need to reuse this for fixing register spilling on SIMD16.
Note that BRW_MAX_MRF is 16, which is the same as BRW_MAX_GRF -
GEN7_MRF_HACK_START.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The ICD loader should be responsible for installing headers.
Reviewed and Tested-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
When faced with a million instructions that all became candidates at the
same time (none of which individually reduce register pressure), the ones
on the critical path are more likely to be the ones that will free up some
candidates soon.
shader-db:
total instructions in shared programs: 1681070 -> 1681070 (0.00%)
instructions in affected programs: 0 -> 0
GAINED: 40
LOST: 74
Fixes indistinguishable-from-hanging behavior in GLES3conform's
uniform_buffer_object_max_uniform_block_size test, regressed by
c3c9a8c857. Given that
93bd627d5a was unlocked by that commit, the
net effect on 16-wide program count is still quite positive, and I think
this should give us more stable scheduling (less dependency on original
instruction emit order).
v2: Comment suggestions by Paul
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70943
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This is a step in doing scheduling as described in Muchnick (p538). A
difference is that our latency function is only specific to one
instruction (it doesn't describe, for example, the different latency
between WAR of a send's arguments and RAW of a send's destination), but
that's changeable later. We also don't separately compute the postorder
traversal of the graph, since we can use the setting of the delay field as
the "visited" flag.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Commit aec20d66d9
(automake: properly handle non-default expat installation),
assumed that up-to date distributions use a recent version
of expat that handles security vunerabilities CVE-2012-1147
and CVE-2012-1148. Seems like this is not always the case
and they prefer to backport only the fix, rather than use
the updated library.
This commit adds a default case -lexpat whenever expat is
not found, while properly handling expat.pc if present.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71022
Reported-By: Bryce Harrington <b.harrington@samsung.com>
Reported-By: Vinson Lee <vlee@freedesktop.org>
Tested-by: Bryce Harrington <b.harrington@samsung.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This will simplify the addition of layout(location) qualifiers for
separate shader objects. This was validated with new piglit tests
arb_explicit_attrib_location/1.30/compiler/not-enabled-01.vert and
arb_explicit_attrib_location/1.30/compiler/not-enabled-02.vert.
v2: Refactor error checking to check_explicit_attrib_location_allowed
and eliminate the gotos. Suggested by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Use mode_string to get the name of the variable mode. Slightly change
the control flow. Both of these changes make it easier to support
separate shader object location layouts.
The format of the message changed because mode_string can return a
string like "shader output". This would result in an awkward message
like "vertex shader shader output..."
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
I made this a function (instead of a method of ir_variable) because it
made the change set smaller, and I expect that there will be an overload
that takes an ir_var_mode enum. Having both functions used the same way
seemed better.
v2: Add missing case for ir_var_system_value.
v3: Change the ir_var_mode_count case to just break. Move the assertion
and the return outside the switch-statment. In the unlikely event that
var->mode is an invalid value other than ir_var_mode_count, the
assertion will still fire, and in release builds we won't wind up
returning a garbage pointer. Suggested by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Since the separation of ir_var_function_in and ir_var_shader_in (similar
for out), this check is no longer necessary. Previously, global_scope
was the only way to tell which was which.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Future patches will add some extra code to this path, and some of that
code will want to exit from the explicit location code early.
v2: Change a geometry shader "break" to a "return" so that try to apply
a bogus geometry shader location qualifier (which could cause cascading
errors). Suggested by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The return value has been unused since commit d348b0c. This was
originally included in another patch, but it was split out by Ian
Romanick.
v2: Drop unnecessary final return. Suggested by Paul.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Incremental builds were failing because not all generated source files
were missing dependencies to src/mapi/glapi/gen/*.xml.
Hopefully this change will be the end of these incremental build
failures.
This avoids a defect in lower_output_reads.
The problem is lower_output_reads treats the gl_FragData array as a single
variable. It first redirects all output writes to a temporary variable (array)
and then writes the whole temporary variable to the output, generating
assignments to all elements of gl_FragData.
BTW this pass can be modified to lower all arrays, not just inputs and outputs.
The question is whether it is worth it.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
v2: addressed Paul Berry's comments
Use PKG_CHECK_MODULE over requesting the user to setup the
option at configure time. Drop unused EXPAT_INCLUDE and
update all targets.
NOTE: The this commit removes the --with-expat configure
option. One should ensure that the expat they wish to use
has expat.pc file accessible by pkg-config.
v2:
* Add note about the removal of --with-expat
(per Tom Stellard)
* Drop EXPAT_CFLAGS for targets that do not build DRI_COMMON
(spotted by Matt Turner)
v3:
* Rebase on top of megadrivers (drop EXPAT_CFLAGS from swrast)
Acked-by: Matt Turner <mattst88@gmail.com> (v2)
Reviewed-by: Tom Stellard <thomas.stellard@amd.com> (v2)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Conflicts:
configure.ac
src/mesa/drivers/dri/common/Makefile.am
The function should have never used it in the first place as it was
a left over from the DRI1 days of the nouveau ddx. While we're around
check if KMS is supported before opening the nouveau device, and
add support for Fermi & Kepler cards.
Compile tested only due to the lack of a Fermi/Kepler card.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The function xf86GetEntityInfo() retrieves the entity rather than
doing any changes. Remove this no-op code.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
v2: Remove xf86PciInfo.h, all drivers provide their own PCI ID list
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
A convenient front end to indices generate/translate code, for emulating
primitives which are not supported natively by the driver.
This handles saving/restoring index buffer state, etc.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
The idea of the original order was that you'd dead code eliminate accesses
to push constants. But I've never seen a case of that (nor has
shader-db), while we frequently see sparse accesses of large constant
arrays that would overflow into pull constants.
Cuts pull constant use on csgo, serious sam, planeshift, and the cave:
total instructions in shared programs: 1695103 -> 1688795 (-0.37%)
instructions in affected programs: 92024 -> 85716 (-6.85%)
GAINED: 339
LOST: 0
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* Use more consistant data sources
* Fix improper color space assignments
* Remove unnecessary comments and code
* Drop unnecessary round_up function (this was leftover
from moving winsys code out of renderer)
Acked-by: Brian Paul <brianp@vmware.com>
* Instead of assuming the displaytarget is the same
stride / colorspace as the destination, lets
actually check the source bitmap.
* Fixes random stride issues in rendering
Acked-by: Brian Paul <brianp@vmware.com>
The MRF variant is going to be used extensively by the atomic counter
intrinsics to assemble untyped atomic and surface read messages
easily.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The maximum number of atomic buffer objects is somewhat arbitrary, we
can change it in the future easily if it turns out it's not enough...
v2: Add comments with the relevant mesa dirty bits. Fix usage of
BRW_NEW_UNIFORM_BUFFER in the GS ABO state atom.
v3: Update binding table layout diagrams.
v4: Resolve conflicts with the recent dynamic surface index assignment changes.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Almost a trivial change, it boils down to renaming a few identifiers
so their names still make sense for opaque types other than sampler.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fix the linker to deal with intrinsic functions which are undefined
all the way down to the driver back-end, and introduce intrinsic
definition helpers in the built-in generator.
We still need to figure out what kind of interface we want for drivers
to communicate to the GLSL front-end which of the supported intrinsics
should use a default GLSL implementation and which should use a
hardware-specific override. As there's no default GLSL implementation
for atomic ops, this seems like something we can worry about later on.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v2: Define local helper function to generate ir_call nodes in the
builtin generator.
And use it to forbid comparisons of opaque operands. According to the
GL 4.2 specification:
> Except for array indexing, structure member selection, and
> parentheses, opaque variables are not allowed to be operands in
> expressions.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v2: Fix GLSL version in which the type became available. Add
contains_atomic() convenience method. Split off atomic counter
comparison error checking to a separate patch that will handle all
opaque types. Include new ir_variable fields for atomic types.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch implements the common support code required for the
ARB_shader_atomic_counters extension. It defines the necessary data
structures for tracking atomic counter buffer objects (from now on
"ABOs") associated with some specific context or shader program, it
implements support for binding buffers to an ABO binding point and
querying the existing atomic counters and buffers declared by GLSL
shaders.
v2: Fix extension checks. Drop unused MAX_ATOMIC_BUFFERS constant.
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Add XML file for the dispatch code generator, update the
dispatch_sanity test and add stub definition for the new entry point.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These ralloc contexts belong to a specific object and are being
deallocated manually from the class destructor. Now that we've hooked
up destructors to ralloc there's no reason for them to be children of
any other context, and doing so might to lead to double frees under
some circumstances. The class destructor has all the responsibility
of freeing class memory resources now.
This patch makes sure that class destructors are called as they should
be when a C++ object allocated by ralloc is released.
Based on a previous patch by Kenneth Graunke, but it doesn't exhibit
the ~0.8% performance regression in shader compilation times because
we now use the HAS_TRIVIAL_DESTRUCTOR() macro to detect the typical
case where the indirect function call can be avoided because the
object's destructor doesn't need to do anything.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Only implemented on GCC and Clang for now. Other compilers use a
dummy implementation that always returns false, which should be a safe
[but slightly inefficient] assumption in all cases.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This will let us use strcasecmp() from anywhere inside Mesa without
having to worry about the fact that it doesn't exist in MSVC.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The layer coming from GS needs to be clamped (not sure if that's actually
the correct error behavior but we need something) as the number can be higher
than the amount of layers in the fb. However, this code was using the layer
calculation from the scene, and this was actually calculated in
lp_scene_begin_rasterization() hence too late (so setup was using the value
from the _previous_ scene or just zero if it was the first scene).
Since the value is used in both rasterization and setup, move calculation up
to lp_scene_begin_binning() though it's a bit more inconvenient to calculate
there. (Theoretically could move _all_ code which was in
lp_scene_begin_rasterization() to there, because ever since we got rid of
swizzled render/depth buffers our "map" functions preparing the fb data for
render don't actually change the data in there at all, but it feels like
it would be a hack.)
v2: improve comments
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Before we were only checking the st->vertex_array_out_of_memory flag
after updating array state. But if there's two consecutive glDrawArrays
calls and the first one is skipped because of OOM, the second one should
be skipped too.
Cc: 9.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Orbital Explorer was generating a 4000 instruction geometry shader, which
was taking 275 trips through dead code elimination and register
coalescing, each of which updated live variables to get its work done, and
invalidated those live variables afterwards.
By using bitfields instead of bools (reducing the working set size by a
factor of 8) in live variables analysis, it drops from 88% of the profile
to 57%, and reduces overall runtime from I-got-bored-and-killed-it (Paul
says 3+ minutes) to 10.5 seconds.
Compare to f179f419d1 on the FS side.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This prevents unnecessary (and wrong) register allocation in the
scheduler for preloaded values in fixed registers.
Fixes interpolation-mixed.shader_test on rv770
(and probably on all other pre-evergreen chips).
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
I noticed this in a shader in Unigine Heaven that was spilling. While it
doesn't really reduce register pressure, it shaves a few instructions
anyway (7955 -> 7882).
v2: Fix turning "0 >> x" into "x" instead of "0" (caught by Erik
Faye-Lund).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
While ir_builder is slightly less efficient, we're only increasing the
work when there's actual optimization being done, and it's way more
readable code.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Matt and I had each screwed up these common required patterns recently, in
ways that wouldn't have been noticed for a long time if not for code
review. Just enforce it in the caller so that we don't rely on code
review catching these bugs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
There is nothing in the OpenGL specification which prevents the user from
calling glGenQueries to generate a new query object while another object is
active. Neither is there anything in the Mesa implementation which prevents
this. So remove the INVALID_OPERATION errors in this case.
Similarly, it is explicitly allowed by the OpenGL specification to delete an
active query, so remove the assertion for that case, replacing it with the
necesssary state updates to end the query, (clear the bindpt pointer and call
into the driver's EndQuery hook).
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
The normal drawing path does this, and it's necessary on Ivybridge,
so let's try it on Sandybridge too. It's not explicitly documented
as necessary, but might help with hangs.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
From the documentation:
"[DevIVB] 3DSTATE_DEPTH_BUFFER must always be programmed along with the
other Depth/Stencil state commands(i.e. 3DSTATE_CLEAR_PARAMS,
3DSTATE_STENCIL_BUFFER, or 3DSTATE_HIER_DEPTH_BUFFER)."
We normally do this, but BLORP was failing to do so in the case where it
disables depth.
Not observed to fix anything yet.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
For some reason, we put the flush in the caller, rather than just before
emitting the packet. This is more than a cosmetic problem: BLORP calls
gen6_emit_3dstate_multisample() directly, and so it missed the flush.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
From the comments above intel_emit_post_sync_nonzero_flush:
"[DevSNB-C+{W/A}] Before any depth stall flush (including those
produced by non-pipelined state commands), software needs to first
send a PIPE_CONTROL with no bits set except Post-Sync Operation != 0."
This suggests that every non-pipelined (0x79xx) command needs a
post-sync non-zero flush before it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Otherwise the gen6 w/a in the kernel won't kick in and the write will
land nowhere.
Inspired by a patch Ken pointed me at which had the same issue (but
isn't yet merged and also for a gen7+ feature). An audit of the entire
driver didn't reveal any other case than the one in in the write_reg
helper used by the gen6 queryobj code.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
The main purpose of this patch is to increase readability of
the array code by introducing is_unsized_array() to glsl_types.
Some redundent is_array() checks are also removed, and small number
of other related clean ups.
The introduction of is_unsized_array() should also make the
ARB_arrays_of_arrays code simpler and more readable when it arrives.
V2: Also replace code that checks for unsized arrays directly with the
length variable
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
v3 (Paul Berry <stereotype441@gmail.com>): clean up formatting.
Separate whitespace cleanups to their own patch.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
When a geometry shader is present, the fragment shader gl_PrimitiveID
input acts like an ordinary varying, receiving data from the gs
gl_PrimitiveID output. When there's no geometry shader, we have to
ask the fixed function SF hardware to provide the primitive ID to the
fragment shader instead.
Previously, the SF setup code would handle this situation by
recognizing that the FS gl_PrimitiveID input didn't match to any VS
output; since normally an FS input with no corresponding VS output
leads to undefined data, the SF setup code used to just arbitrarily
assign it to receive data from attribute 0.
This patch changes the SF setup code so that instead of arbitrarily
using attribute 0, it assigns the unmatched FS input to receive
gl_PrimitiveID. In the case where the FS input really is
gl_PrimitiveID, this produces the intended result. In all other
cases, no harm is done since GL specifies that the behaviour is
undefined.
Fixes piglit test primitive-id-no-gs.
v2: If an attribute is already being overridden with point
coordinates, don't try to also override it with gl_PrimitiveID. This
is necessary to avoid regressing piglit tests such as
shaders/glsl-fs-pointcoord.
Reviewed-by: Eric Anholt <eric@anholt.net>
v2: Actually implement interop between the gallium
state tracker and the VDPAU backend.
v3: Make it also available in non legacy contexts,
fix video buffer sharing.
v4: deny interop if we don't have the same screen object
v5: rebased on upstream changes
v6: implemented VDPAUGetSurfaceivNV, improved error handling,
unregister all surfaces in VDPAUFiniNV
v7: squash merge with Mareks changes
Signed-off-by: Christian König <christian.koenig@amd.com>
ir_txf expects an ivec* coordinate, and may be larger than ivec2;
shuffle things around so that this will work.
V2: Fix style nits, use ir_builder
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It turns out that nonzero offsets with gsampler2DRect don't work -- they
just return garbage. Work around this by folding the offset into the
coord.
Done as an IR pass rather than yet another hack in the visitors because
it's clear what's going on this way. Can possibly reuse this to replace
the existing txf coord+offset hacks.
V2: Use ir_builder
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We don't have a message that does 4 independent offsets; a lowering
pass needs to lower it to 4 normal gather4s before reaching this
point.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Note that gather4_po_c's parameters are too long for SIMD16. It might be
worth emitting 2xSIMD8 messages in this case at some point.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
gather4_c's argument layout is straightforward -- refz just goes on the
end.
gather4_po_c's layout however -- the array index is replaced with refz.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
ARB_gpu_shader5's textureGather*() functions which take shadow samplers
have a separate `refz` parameter rather than adding it to the
coordinate.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
V3: fixup crazy check for whether we need to emit the coordinate after
custom handling.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Some texturing ops are about to have nonconstant offset support; the
offset in the header in these cases should be zero.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The generator code ends up clearer this way than if we had to sniff
via the message length. Implemented via the gather4_po message in
hardware, which is present in Gen7 and later.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Prior to ARB_gpu_shader5 / GLSL 4.0, the offset is required to be
a constant expression.
With that extension, it is relaxed to be an arbitrary expression.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since 062317d667 (i965: Go back to using the kernel SOL reset feature.)
we've been flushing the batch on BeginTransformFeedback(). So it's not
necessary to do it on EndTransformFeedback(). A PIPE_CONTROL will work.
This makes gen7_end_transform_feedback() exactly the same as the gen6
variant. However, they'll diverge again shortly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was a hack to avoid choosing to schedule all texturing before
consumption of any texture results due to the way dependency chains worked
out in the presence of MRFs. On gen7, we don't have MRFs, so the problem
doesn't apply, and this was just badly constraining our scheduling.
total instructions in shared programs: 1615306 -> 1612534 (-0.17%)
instructions in affected programs: 9958 -> 7186 (-27.84%)
GAINED: 259
LOST: 9
Reviewed-by: Matt Turner <mattst88@gmail.com>
The LIFO plan was simple: Take the most recently made available
instructions, and pick those first.
But because of the order we were pushing things onto our list of
available-to-schedule instructions, it meant that when a set of
instructions was made available at the same time (for example, everything
at the start of the program that didn't depend on other instructions) we'd
schedule them in reverse order.
If you had 10 texture calls in a row in your program, each with
independent argument setup, we'd set up the last texture call's args and
execute it first, even though we wouldn't be able to consume its results
until we'd finished the other 9 texture calls (assuming consumption of
texture results happens near each texture call, and combines it with
another texture result, which is normal for a convolution shader).
To fix this, walk the list for doing LIFO in the order that instructions
were originally generated in the program, but choose to push
newly-made-available instructions to the other end of the list instead.
total instructions in shared programs: 1587242 -> 1586290 (-0.06%)
instructions in affected programs: 7801 -> 6849 (-12.20%)
GAINED: 76
LOST: 67
Thanks to Chia-I Wu for pointing out the bug in my first version of the
patch that made it a huge loss.
Reviewed-by: Matt Turner <mattst88@gmail.com>
When PIPE_CAP_MIXED_FRAMEBUFFER_SIZES is not provided, parts of
ARB_framebuffer_object can't be supported, such as on NV30.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
This CAP will determine whether ARB_framebuffer_object can be enabled.
The nv30 driver does not allow mixing swizzled and linear zsbuf/cbuf
textures.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
In commit 1b4a737 (glsl: Support redeclaration of VS and GS
gl_PerVertex output), I added code to ensure that when an unnamed
gl_PerVertex interface block is redeclared, any ir_variables that
weren't included in the redeclaration are removed from the IR (and the
symbol table). This ensures that only those variables that were
explicitly redeclared may be used.
However, when I wrote this code, I neglected to match the variable
mode when finding variables to remove. This meant that redeclaring a
built-in output block might cause the built-in input gl_in to be
accidentally removed.
Fixes piglit test gs-redeclares-pervertex-out-only.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The GLSL 4.10 rules for redeclaration of built-in interface blocks
(which we've chosen to regard as clarifications of GLSL 1.50) only
require gl_PerVertex blocks to match in shaders that actually use
those blocks. The easiest way to implement this is to detect
situations where a compiled shader doesn't refer to any elements of
gl_PerVertex, and remove all the associated ir_variables from the
shader at the end of ast-to-ir conversion.
Fixes piglit tests
linker/interstage-{pervertex,pervertex-in,pervertex-out}-redeclaration-unneeded.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Normally when a built-in array (such as gl_ClipDistance) is
redeclared, we call get_variable_being_redeclared() to do the
redeclaration, and it in turn calls check_builtin_array_max_size() to
make sure that the redeclared array size isn't too large.
However when a built-in array is redeclared as part of redeclaring
gl_in, we don't call get_variable_being_redeclared() (since the
individual built-ins aren't each represented by their own ir_variable
anymore). So we need to add an explicit call to
check_builtin_array_max_size() to make sure the new array size isn't
too large.
Note: at the moment this is redundant with a test that's done at link
time, so there's no change to piglit results. But the patch that
follows will prevent link errors from being reported if gl_PerVertex
isn't used, so in order to prevent that patch from causing
regressions, we need to add the compile check now. Besides, it's
nicer to report this error at compile time anyhow.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The queries GEOMETRY_VERTICES_OUT, GEOMETRY_INPUT_TYPE, and
GEOMETRY_OUTPUT_TYPE (defined by GL 3.2) differ from the corresponding
queries in ARB_geometry_shader4 in the following ways:
- They use different enum values
- They can only be queried; they cannot be set.
- Attempting to query them yields INVALID_OPERATION if the program is
not linked, or lacks a geometry shader.
This patch switches us over from the ARB_geometry_shader4 behaviour to
the GL 3.2 behaviour.
Fixes piglit test query-gs-prim-types.
v2: Improve comment above has_core_gs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
When program_resource_visitor visits variables that were created by
lower_named_interface_blocks, it needs to do extra work to un-do the
effects of lower_named_interface_blocks and construct the proper API
names.
Fixes piglit test
spec/glsl-1.50/execution/interface-blocks-api-access-members.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These variables will need to be treated specially by
program_resource_visitor, so that they can be addressed through the
API using their interface block name (and array index, for interface
block arrays).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Later patches will use this information to do proper error checking of
interpolation qualifiers that appear inside of interface blocks.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
In future patches, we will need this in order to interpret
interpolation qualifiers that appear inside interface blocks.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Although in principle there is no hardware limitation that prevents
gl_MaxGeometryInputComponents from being set to 128 on Gen7, we have
the following limitations in the vec4 compiler back end:
- Registers assigned to geometry shader inputs can't be spilled or
later re-used for any other purpose.
- The last 16 registers are set aside for the "MRF hack", meaning they
can only be used to send messages, and not for general purpose
computation.
- Up to 32 registers may be reserved for push constants, even if there
is sufficient register pressure to make this impractical.
A shader using 128 geometry input components, and having an input type
of triangles_adjacency, would use up:
- 1 register for r0 (which holds URB handles and various pieces of
control information).
- 1 register for gl_PrimitiveID.
- 102 registers for geometry shader inputs (17 registers per input
vertex, assuming DUAL_INSTANCED dispatch mode and allowing for one
register of overhead for gl_Position and gl_PointSize, which are
present in the URB map even if they are not used).
- Up to 32 registers for push constants.
- 16 registers for the "MRF hack".
That's a total of 152 registers, which is well over the 128 registers
the hardware supports.
Fortunately, the GLSL 1.50 spec allows us to reduce
gl_MaxGeometryInputComponents to 64. Doing that frees up 48
registers, brining the total down to 104 registers, leaving 24
registers available to do computation.
Fixes piglit test
spec/glsl-1.50/execution/geometry/max-input-components.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is similar to what we do for 16-wide vs 8-wide fragment shaders.
First we try compiling the geometry shader in DUAL_OBJECT mode. If we
can't do that without spilling, we fall back on DUAL_INSTANCED mode,
which should require less spilling (since it uses an interleaved
layout of payload registers).
In an ideal world we'd fall back to SINGLE mode, which would allow us
to interleave general-purpose registers too (resulting in even less
likelihood of spilling). But at the moment, the vec4 generator and
visitor classes don't have the infrastructure to interleave general
purpose registers, so DUAL_INSTANCED is the best we can do.
As a side benefit this paves the way for implementing instanced
geometry shaders (which are incompatible with DUAL_OBJECT mode).
Since most geometry shaders used in piglit testing are small,
DUAL_INSTANCED mode won't get exercised very much in a normal piglit
run. To force DUAL_INSTANCED mode to be used for all geometry
shaders, set INTEL_DEBUG=nodualobj.
Reviewed-by: Eric Anholt <eric@anholt.net>
Geometry shaders that run in "DUAL_INSTANCED" mode store their inputs
in vec4's. This means that when compiling gl_PointSize input
swizzling (a MOV instruction which uses a geometry shader input as
both source and destination), we need to do two things:
- Set force_writemask_all to ensure that the MOV happens regardless of
which channels are enabled.
- Set the source register region to <4;4,1> (instead of <0;4,1> to
satisfy register region restrictions.
v2: move the source register region fixup to the top of
vec4_generator::generate_vec4_instruction(), so that it applies to all
instructions rather than just MOV.
Reviewed-by: Eric Anholt <eric@anholt.net>
In future patches, this will allow us to first try compiling a
geometry shader in DUAL_OBJECT mode (which is more efficient but uses
more registers) and then if spilling is required, fall back on
DUAL_INSTANCED mode.
Reviewed-by: Eric Anholt <eric@anholt.net>
Otherwise the scheduler would be invoked with prog_data->total_grf ==
0, causing havoc.
In a future patch, this will allow us to try compiling a geometry
shader in DUAL_OBJECT mode with spilling disabled, and then fall back
to DUAL_INSTANCED mode if that failed.
Reviewed-by: Eric Anholt <eric@anholt.net>
When geometry shaders are operated in "single" or "dual instanced"
mode, a single set of geometry shader inputs is interleaved into the
thread payload (with each payload register containing a pair of
inputs) in order to save register space.
This patch modifies vec4_visitor::lower_attributes_to_hw_regs so that
it can handle the interleaved format.
Reviewed-by: Eric Anholt <eric@anholt.net>
All geometry shaders begin this instruction:
mov(1) g0.2<1>:ud 0x0:ud { align1 }
which sets up GRF0 properly for scratch reads and writes. Since this
instruction has a SIMD size of 1, it will only have an effect if the
first channel is enabled. In practice, the hardware seems to always
dispatch geometry shaders with the first channel enabled, but I can't
find anything in the docs to guarantee that.
So to be on the safe side, set force_writemask_all on the instruction,
which guarantees that it will have the desired effect regardless of
which channels are enabled.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When lower_named_interface_blocks lowers a built-in interface block
member to an ir_variable, it needs to set explicit_location in the
ir_variable. Otherwise the linker gets confused and treats the
variable as a generic varying.
Fixes the following piglit tests, which were regressed by commit
63974c0 (glsl: Simplify the interface to
link_invalidate_variable_locations):
- clip-distance-bulk-copy
- clip-distance-in-bulk-read
- clip-distance-in-explicitly-sized
- clip-distance-in-param
- clip-distance-in-values
- core-inputs
- gs-redeclares-both-pervertex-blocks
- gs-redeclares-pervertex-in-only
- redeclare-pervertex-subset-vs-to-gs
- unsized-in-named-interface-block-gs
- unsized-in-named-interface-block-multiple
- unsized-in-unnamed-interface-block-gs
- unsized-in-unnamed-interface-block-multiple
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70820
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This should never have been in the program key in the first place,
since it's determined by the shader source, not by GL state. Change
the code to just refer to gl_program::UsesClipDistanceOut directly.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This will make it easier for back-ends to share code between geometry
shader and vertex shader compilation. Also, it is renamed to
"UsesClipDistanceOut" to clarify that (a) in geometry shaders, it
refers to the gl_ClipDistance output rather than the gl_ClipDistance
input, and (b) it is irrelevant in fragment shaders.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Since gl_ClipDistance is lowered from an array of floats to an array
of vec4's during compilation, transform feedback has special logic to
keep track of the pre-lowered array size so that attempting to perform
transform feedback on gl_ClipDistance produces a result with the
correct size.
Previously, this special logic always consulted the vertex shader's
size for gl_ClipDistance. This patch fixes it so that it uses the
geometry shader's size for gl_ClipDistance when a geometry shader is
in use.
Fixes piglit test spec/glsl-1.50/transform-feedback-type-and-size.
v2: Change the type of LastClipDistanceArraySize to "unsigned", and
clarify the comment above it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We've always overriden
ctx->Const.{Vertex,Fragment}Program.MaxTextureImageUnits to reflect
the number of texture image units supported by the hardware (rather
than using the default values assigned by Mesa core) so it seems
sensible to do that for GeometryProgram.MaxTextureImageUnits too. We
set it to 0 if geometry shaders aren't supported.
Once that is done, we can just unconditionally add
GeometryProgram.MaxTextureImageUnits to MaxCombinedTextureImageUnits.
Fixes piglit test "spec/glsl-1.50/built-in
constants/gl_MaxCombinedTextureImageUnits".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The encoding of constant, relative, and relative-const src registers is
a bit more complex than originally thought, which gives an extra bit to
encode const reg # at expense of taking a bit from relative offset.
In most cases a3xx seems to actually use a scheme whereby it can encode
an extra bit for const register. You have three possible encodings in
thirteen bits:
register: (11 bits for N.c)
00........... rN.c
relative: (10 bits for N)
010.......... r<a0.x + N>
011.......... c<a0.x + N>
const: (12 bits for N.c)
1............ cN.c
Which means we can deal w/ more consts than previously thought.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
d3d10 requires that cube corners are filtered with accurate weights (that
is, the weight of the non-existing corner texel should be evenly distributed
to the other 3 texels). OpenGL does not require this (but recommends it).
This requires us to use different filtering code, since we need per-texel
weights which our 2d lerp doesn't (and can't) do. And of course the (now
per element) weights need to be adjusted too for it to work.
Invoke the new filtering code whenever there's an edge to keep things simpler,
as it will work for edges too not just corners but of course it's only needed
with corners.
More ugly code for not much gain but at least a hacked up cubemap demo
shows very nice corners now... Not sure yet if and how this should be
configurable...
v2: incorporate feedback from Jose, only use special corner filtering code
when there's a corner not when there's only an edge (as corner filtering code
is slower, though a perf difference was only measureable when always
forcing edge code). Plus some minor style fixes.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
No driver uses it any more, and it's been replaced by megadrivers.
v2: Remove always-on conditional for NEED_LIBPROGRAM (review by Emil)
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
v2: drop dridir now that it's unused.
v3: Fix linking after rebase when building just swrast from classic but a
drm-using gallium driver.
v4: Consistently put spaces around += in the updated Makefile.am block.
v5: Set a global driverAPI variable so loaders don't have to update to
createNewScreen2() (though they may want to for thread safety).
Reviewed-by: Matt Turner <mattst88@gmail.com> (v3)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
This required some reordering of headers to ensure that the symbol name
redefines happened before any prototypes.
v2: drop dridir now that it's unused.
v3: Consistently put spaces around += in the updated Makefile.am blocks.
v4: Set a global driverAPI variable so loaders don't have to update to
createNewScreen2() (though they may want to for thread safety).
Reviewed-by: Matt Turner <mattst88@gmail.com> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
i915 has symbols for formerly-shared code that conflict with i965, so we
define them away using gen-symbol-redefs.py. Options considered:
- This option. Downsides: The symbols in profiling and debugging don't
match the source. The symbol list may change in the future and we won't
notice without manually running the tool again.
- Use objcopy --localize-hidden to automatically demote our symbols to
locals. This didn't work on i965 due to c++ weak symbols (which can't
be localized), but could work on i915. We could do it on i915 only, but
it does produce libtool warnings at link time due to libtool not knowing
if the resulting .o file is safe to link (stupid libtool). Plus you end
up with different symbols of the same name, which is confusing for
debugging too. On the other hand, no future symbol conflicts long term.
- Write our own libelf tool that handles c++ weak symbols like we want and
apply it to all drivers. All the downsides of above, but applies
uniformly across drivers.
- Edit the files to just rename all the i915 or i965 symbols that
conflict. There are on the order of 100 that have a prefix we used to
share, so it would take a bit of typing. Fewest downsides, but still
can have conflicts long term.
Ultimately, this is the least invasive change at the moment, and we can
see if the "more symbol conflicts appear later" thing is a real concern or
not.
Note that the ability to compile a version of i915 without INTEL_DEBUG env
support is dropped. It's too useful.
v2: drop dridir now that it's unused.
v3: Consistently put spaces around += in the updated Makefile.am block.
v4: Set a global driverAPI variable so loaders don't have to update to
createNewScreen2() (though they may want to for thread safety).
Reviewed-by: Matt Turner <mattst88@gmail.com> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
v2: drop dridir now that it's unused.
v3: Consistently put spaces around += in the updated Makefile.am block.
v4: Set a global driverAPI variable so loaders don't have to update to
createNewScreen2() (though they may want to for thread safety).
v5: Fix missed public symbol in nouveau. (caught by Emil)
Reviewed-by: Matt Turner <mattst88@gmail.com> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Previously, we've split things such that mesa core is in libdricore,
exposing the whole Mesa core interface in the global namespace, and the
i965_dri.so code all links against that. Along with polluting application
namespace terribly, it requires extra PLT indirections and prevents LTO.
Instead, we can build all of the driver contents into the same .so with
just a few symbols exposed to be referenced from the actual driver .so
file, allowing LTO and reducing our exposed symbol count massively.
FPS improvement on GLB2.7 with INTEL_NO_HW=1: 2.61061% +/- 1.16957% (n=50)
(without LTO, just the PLT reductions from this commit)
Note that the X Server requires commit
7ecfab47eb221dbb996ea6c033348b8eceaeb893 to successfully load this driver!
v2: Set a global driverAPI variable so loaders don't have to update to
createNewScreen2() (though they may want to for thread safety).
v3: Drop AM_CPPFLAGS addition (Emil pointed out I'd missed some cflags
that would be necessary, though only if we actually relied on them).
v4: Fix install with DESTDIR set.
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2)
As we move to megadrivers, we are unable to build multiple drivers with
the same public global symbol per driver (Think an X Server with an intel
and a nouveau driver, and the X Server implementing indirect for both --
we have to actually talk to the right driver). By slipping the
driDriverAPI vtable into the driver's extension list, we can replace the
usage of the global symbol with usage of the loader-dlsym()ed driver
information.
v2: Pull in the hunk to avoid crashing on null driver_extensions. Thanks,
Emil!
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
This will allow a megadrivers build to reference the actual driver being
loaded from the shared dri_util screen creation code.
v2: Fix indentation, fallback case in EGL (review by Emil).
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
The previous interface relied on a static struct, which meant that the
driver didn't get a chance to edit the struct before the struct got used.
For megadrivers, I want struct specific to the driver being loaded.
v2: Fix the prototype in the docs (caught by Marek). Since the driver
name was in the function, we didn't need to also pass it in.
v3: Fix asprintf error checking (caught by Matt's gcc).
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Turns out already we have this nice mechanism for providing optional
things from the driver to the loader, and I was going to have to rename
the public global symbol to avoid conflicts when doing megadrivers.
While the former __driConfigOptions is technically loader interface, this
is the only loader that made use of that symbol. Continue paying
attention to it if we can't find the new option, to retain compatibility
with old drivers.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Based on a similar fix from Aaron Watry. It seems unlikely that we
will ever need a kernel-specific setting for this, and the Gallium API
doesn't support it. Remove kernel::max_block_size() altogether.
The gallium vbuf module, which we've been using for some time now, takes
care of uploading user-space vertex/index data into real buffers. The
upload code in the svga driver was unused.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Print info about packing, format, type, and tiling. This will help debug
future issues with this fastpath.
Reviewed-by: Frank Henigman <fjhenigman@google.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Fixes texture corruption of Weston clients on cairo-glesv2 backend.
Commit 49ed599 introduced the bug.
Corruption occured when glTexSubImage called
intel_texsubimage_tiled_memcpy() with:
x,y=10,9
w,h=7,7
format=GL_ALPHA(0x1906)
type=GL_UNSIGNED_BYTE(0x1401)
gl_format=MESA_FORMAT_A8(0x18)
packing.alignemnt=4
The function miscalculated the source image's stride as w*cpp=7 without
taking into account the packing alignment. The actual stride was 8.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70435
Reported-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Tested-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by:Frank Henigman <fjhenigman@google.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
In commit 800610f (i965/fs: Improve accuracy of dFdy() to match
dFdx()) I unrolled the high-accuracy dFdy() computation from a single
SIMD16 instruction to two SIMD8 instructions because of text I found
in the i965 (gen4) PRM saying that instruction compression could not
be used in align16 mode. I couldn't find similar text in later
hardware docs, and I observed problems trying to use instruction
compression on align16 mode on Ivy Bridge, so I assumed that the
restriction still applied and the associated documentation had simply
been lost.
After consultation with the hardware engineers, it turns out this is
not the case. In point of fact, the restriction was dropped in gen5,
re-introduced in Ivy Bridge, and dropped again in Haswell. The reason
I didn't notice this is that in the Ivy Bridge documentation, the
restriction was in a different section, and described using different
language.
Now that we know that the restriction only applies to Gen4 and Ivy
Bridge, we can limit the unrolling to those platforms.
Tested on gen5, gen6, and gen7 (both Ivy Bridge and Haswell).
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
From the GLSL 1.50 spec, section 4.3.8.1 (Input Layout Qualifiers):
The layout qualifier identifiers for geometry shader inputs are
layout-qualifier-id
points
lines
lines_adjacency
triangles
triangles_adjacency
And from section 4.3.8.2 (Output Layout Qualifiers)
The layout qualifier identifiers for geometry shader outputs are
layout-qualifier-id
points
line_strip
triangle_strip
max_vertices = integer-constant
We were erroneously allowing line_strip and triangle_strip to be used
as input qualifiers, and we were allowing lines, lines_adjacency,
triangles, and triangles_adjacency to be used as output qualifiers.
Fixes piglit tests "glsl-1.50-gs-{input,output}-layout-qualifiers *".
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
On DOTA2, framerate on dota2-de1.dem in windowed mode on my laptop
improves by 7.69854% +/- 0.909163% (n=3). In a microbenchmark hitting
this code path (wall time of piglit vbo-subdata-many), runtime decreases
from 0.8 to 0.05 seconds.
v2: Use out of range start/end instead of separate bool for the active
flag (suggestion by Jordan), fix double-upload in the stalling path.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The brw_prepare_vertices that sets up buffers[] depends on these
parameters, so don't let brw_prepare_vertices() skip it.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Supporting this extension turns out to simplify our code a bit over not
supporting this extension, once the glBufferSubData() synchronization code
lands.
v2: Use 16 byte alignment like we do for uniform buffers, due to unaligned
access penalties.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
This was mostly for the i915 system-memory VBO code, which we don't have
any more, but since that existed we've ended up producing dependencies on
it being there.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
If glBufferData(), glBufferSubData(0, obj->Size), or similar happens, we
get a new drm_intel_bo for the buffer object, and thus need to re-upload
texture buffer state so we point at the new data.
Fixes the new piglit GL_ARB_texture_buffer_object/data-sync
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The new function replaces four old functions: set_fragment/vertex/
geometry/compute_sampler_views().
Note: at this time, it's expected that the 'start' parameter will
always be zero.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Writing a 64-bit register value to memory is sufficiently complicated
that it makes sense to reuse this function rather than duplicating it.
Exposing it outside of gen6_queryobj.c means it needs a more descriptive
function name. It could probably be moved to brw_util.c or somewhere
else, but this works too.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The current callers just want to write a single register, so combining
the register read with a pipeline flush made sense. However, in the
future we'll want to do multiple register reads back to back, and we'll
only want to flush once.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The unit tests added in the previous commits prove some things about the
state of some internal data structures. The most important of these is
that all built-in input and output variables have explicit_location
set. This means that link_invalidate_variable_locations doesn't need to
know the range of non-generic shader inputs or outputs. It can simply
reset location state depending on whether explicit_location is set.
There are two additional assumptions that were already implicit in the
code that comments now document.
- ir_variable::is_unmatched_generic_inout is only used by the linker
when connecting outputs from one shader stage to inputs of another
shader stage.
- Any varying that has explicit_location set must be a built-in. This
will be true until GL_ARB_separate_shader_objects is supported.
As a result, the input_base and output_base parameters to
link_invalidate_variable_locations are no longer necessary, and the code
for resetting locations and setting is_unmatched_generic_inout can be
simplified.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Validates:
- ir_variable::explicit_location should not be modified.
- If ir_variable::explicit_location is not set, ir_variable::location,
ir_variable::location_frac, and
ir_variable::is_unmatched_generic_inout must be reset to 0.
- If ir_variable::explicit_location is set, ir_variable::location
should not be modified. ir_variable::location_frac, and
ir_variable::is_unmatched_generic_inout must be reset to 0.
Previous unit tests have shown that all non-generic inputs / outputs
have explicit_location set.
v2: Split the link_invalidate_variable_locations interface change out to
a separate patch. Remove the vertex_in_builtin_without_explicit and
vertex_out_builtin_without_explicit tests. There was a lot of good
discussion about this on the mailing list to which I refer the
interested reader. Both changes suggested by Paul.
http://lists.freedesktop.org/archives/mesa-dev/2013-October/046652.html
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This will make it easier to unit test this function in successive
patches. Also, correct the prototype in linker.h. It was... wrong.
v2: Split the interface change from adding the unit tests. Suggested by
Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Checks that the variables generated meet certain criteria.
- Geometry shader inputs have an explicit location.
- Geometry shader outputs have an explicit location.
- Fragment shader-only varying locations are not used.
- Geometry shader uniforms and system values don't have an explicit
location.
- Geometry shader constants don't have an explicit location and are
read-only.
- No other kinds of geometry variables exist.
It does not verify that an specific variables exist.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Checks that the variables generated meet certain criteria.
- Fragment shader inputs have an explicit location.
- Fragment shader outputs have an explicit location.
- Vertex / geometry shader-only varying locations are not used.
- Fragment shader uniforms and system values don't have an explicit
location.
- Fragment shader constants don't have an explicit location and are
read-only.
- No other kinds of fragment variables exist.
It does not verify that an specific variables exist.
v2: Use _mesa_varying_slot_in_fs in
fragment_builtin.inputs_have_explicit_location. Suggested by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Checks that the variables generated meet certain criteria.
- Vertex shader inputs have an explicit location.
- Vertex shader outputs have an explicit location.
- Fragment shader-only varying locations are not used.
- Vertex shader uniforms and system values don't have an explicit
location.
- Vertex shader constants don't have an explicit location and are
read-only.
- No other kinds of vertex variables exist.
It does not verify that an specific variables exist.
v2: Fix memory management mistakes in
common_builtin::string_starts_with_prefix. Clean up error message
reporting in common_builtin::no_invalid_variable_modes. Both suggested
by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Ever since the addition of interface blocks with instance names, we have
had an implicit invariant:
var->type->is_interface() ==
(var->type == var->interface_type)
The odd use of == here is intentional because !var->type->is_interface()
implies var->type != var->interface_type.
Further, if var->type->is_array() is true, we have a related implicit
invariant:
var->type->fields.array->is_interface() ==
(var->type->fields.array == var->interface_type)
However, the ir_variable constructor doesn't maintain either invariant.
That seems kind of silly... and I tripped over it while writing some
other code. This patch makes the constructor do the right thing, and it
introduces some tests to verify that behavior.
v2: Add general-ir-test to .gitignore. Update the description of the
ir_variable invariant for arrays in the commit message. Both suggested
by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
After some discussions about the correct way to update
_mesa_program_state_string, I decided to make a unit test for the
function. It turns out that the function didn't work quite the way I
thought. The unit test proves that the code was already correct.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Silence a bunch of MSVC type conversion warnings.
Changed return type of S_FIXED to int32_t (signed). The result
is the same. It just seems more intuitive that a signed conversion
function should return a signed value.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This extension never saw any real use so remove it.
v2: also update tests/num_strings.cpp for 'make check'
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Dead code elimination would get rid of the extra instructions, but
skipping this saves iterations through the optimization loop.
From shader-db:
N Min Max Median Avg Stddev
x 14672 3 16 3 3.1334515 0.59904168
+ 14672 1 16 3 2.8955153 0.77732963
Difference at 95.0% confidence
-0.237936 +/- 0.0158798
-7.59342% +/- 0.506783%
(Student's t, pooled s = 0.693935)
Embarassingly, the classic shadow mapping shader:
void main() { }
used to require three iterations through the optimization loop.
With this patch, it only requires one (which makes no progress).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously one side could be UD while the other was float.
V2: Prefer float; apparently IVB can dispatch float ops faster. (Thanks
Eric)
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Gather unconditionally uses a header, but in some cases the
texture_offset value will be zero.
V2: Don't introduce a bogus conversion.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, Mesa followed the linkage rules outlined in the GLSL
1.20-1.40 specs, which (collectively) said that GLSL versions 1.10 and
1.20 could be linked together, but no other versions could be linked.
In GLSL 4.30, the linkage rules were relaxed so that any two desktop
GLSL versions can be linked together. This change was made because it
reflected the behaviour of nearly all existing implementations (see
Khronos bug 8463). Mesa was one of the few (perhaps the only)
exceptions to prohibit cross-linking of some GLSL versions.
Since the GLSL linkage rules were deliberately relaxed in order to
match the behaviour of existing implementations, it seems appropriate
to relax the rules in Mesa too (even though Mesa doesn't support GLSL
4.30 yet).
Note that linking ES and desktop shaders is still prohibited, as is
linking ES shaders having different GLSL versions.
Fixes piglit tests "shaders/version-mixing {interstage,intrastage}".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Identifiers with double underscores are reserved, and using them has
undefined behavior according to the C++ spec. It's unlikely to make
any difference, but...
Tested-by: Tom Stellard <thomas.stellard@amd.com>
For seamless cube filtering it is necessary to determine new faces and new
coords per sample. The logic for this is _seriously_ complex (what needs
to happen is very "asymmetric" wrt face, x/y under/overflow), further
complicated by the fact that if the 4 samples are in a corner (meaning we
only have actually 3 samples, and all 3 are on different faces) then
falling off the edge is happening _both_ on x and y axis simultaneously.
There was a noticeable performance hit in mesa's cubemap demo when seamless
filtering was forced on (just below 10 percent or so in a debug build, when
disabling all filtering hacks, otherwise it would probably be a bit more) and
when always doing the logic, hence use a branch which it only does it if any
of the pixels in a quad (or in two quads) actually hit this. With that there
was no measurable performance hit in the cubemap demo (neither in a debug nor
release buidl), but this will vary (cubemap demo very rarely hits edges).
Might also be different on other cpus, as this forces SoA sampling path which
potentially can be quite a bit slower.
Note that as for corners, this code gets all the 3 samples which actually
exist right, and the 4th texel will simply be the same as one of the others,
meaning that filter weights will be a bit wrong. This however should be
enough for full OpenGL (but not d3d10) compliance.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Using atomic function for ncs is superfluous since it is
protected by a mutex anyway. Also lock the mutex only once
while retrieving the next CS for submission.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes this build error.
CC clientattrib.lo
In file included from ../../include/GL/glx.h:333,
from glxclient.h:45,
from clientattrib.c:32:
../../include/GL/glxext.h:275: error: redefinition of typedef ‘GLXContextID’
../../include/GL/glx.h:171: note: previous declaration of ‘GLXContextID’ was here
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70591
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Everything necessary for these appears to be implemented. We'll want to
add more tests to guard against bugs, but it should be functionally
complete.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
translate_sse.c contains code for msabi on x86_64, but it appears to be
untested.
Currently arguments 1 and 2 passed to the generated code are moved as 32-bit
quantities into the registers used by sysvabi, irrespective of the architecture.
Since these may be pointers, they must be moved as 64-bit quantities to avoid
truncation.
Commit f4dd099171 disabled tranlate_sse.c on MinGW
x86_64, I don't know if was due to this issue, or a different one...
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cygwin also uses the msabi calling convention on x86_64, not the sysvabi calling
convention
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Brian Paul <brianp@vmware.com>
ignored, and an empty message aborts the commit.
The heap is NX on 64-bit Cygwin, so use the rtasm_exec_malloc() implementation
which uses mmap() to allocate an anonymous page with execute permission, rather
than the one which just uses malloc().
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Brian Paul <brianp@vmware.com>
With most of the virtual functions gone, brwInitVtbl() is now tiny.
Merging it into the caller allows us to delete the entire file.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that i915 and i965 have been split, the separation between
intelDestroyContext and brw_destroy_context is kind of arbitrary.
This patch replaces the only brw->vtbl.destroy() call with the body
of brw_destroy_context (the only implementation of that virtual
function).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
dri_bo_release is a helper function that calls drm_intel_bo_unreference
but then also sets the pointer to NULL. This is unnecessary, since
brw_destroy_context is called from intelDestroyContext, which also frees
brw completely.
If you're still trying to access them, you've got bigger problems.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Having almost the entire body of the function indented one level for a
check that should never happen seems silly. Just early return.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Since the i915/i965 split, there's only one implementation of this
virtual function. We may as well just call it directly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Since the i915/i965 split, there's only one implementation of this
virtual function. We may as well just call it directly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
In commit f878d20 (glsl: Update ir_variable::max_ifc_array_access
properly), I accidentally used the wrong kind of check to determine
whether the variable being accessed was an interface instance (I used
var->get_interface_type() != NULL when I should have used
var->is_interface_instance()). As a result, if an unnamed interface
block contained a struct which contained an array,
update_max_array_access() would mistakenly interpret the struct as a
named interface block and try to dereference a null
var->max_ifc_array_access.
This patch corrects the check, fixing the null dereference.
Fixes piglit test interface-block-struct-nesting.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70368
Reviewed-by: Matt Turner <mattst88@gmail.com>
In desktop GLSL, location qualifiers are case-insensitive. In GLSL
ES, they are case-sensitive. This patch handles the difference by
using a new function to match layout qualifiers,
match_layout_qualifier(), which calls either strcmp() or strcasecmp()
as appropriate.
Fixes piglit tests:
- layout-not-case-sensitive-in.geom
- layout-not-case-sensitive-max-vert.geom
- layout-not-case-sensitive-out.geom
- layout-not-case-sensitive.frag
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes a number of piglit crashes when running on a hacked up llvmpipe.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This just adds the missing bits so the ubo tests don't crash.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
From the ARB_geometry_shader4 spec (section Geometry Shader outputs):
"The built-in special variable gl_Position is intended to hold the
homogeneous vertex position. Writing gl_Position is optional."
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2 (Paul Berry <stereotype441@gmail.com>: Split out to separate patch
(previously this was part of "glsl: add builtins for geometry
shaders.")
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Exposing 10-bit color configs confuses too many applications that try to
use the chooser to pick an 8 bit config. The chooser consider an fbconfig
with more bits a better match and will thus give a 10 bit config when an
application asks for a config with GLX_RED_SIZE 1 or 8.
One key example is glxinfo, which does this, and then doesn't specify that
it needs a config where GLX_DRAWABLE_TYPE has the GLX_WINDOW_BIT set.
This way it ends up with a 10 bit config that it can't use to create a
GLX window and fails to log extensions.
This reverts commit f354bcc177.
https://bugs.freedesktop.org/show_bug.cgi?id=70557
We can't perform DCE using the liveness pass between GVN and GCM
because it relies on the correct schedule, but GVN doesn't care about
preserving correctness - it's rescheduled later by GCM.
This patch makes dce_cleanup pass perform simple DCE
between GVN and GCM instead of relying on liveness pass.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=70088
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Two extra instructions in some heroesofnewerth shaders, but a win for
everything else.
total instructions in shared programs: 1531352 -> 1530815 (-0.04%)
instructions in affected programs: 121898 -> 121361 (-0.44%)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reverts commit 94d05bf87a as it has a
few problems:
- it breaks windows builds becuase env[LLVM_CXXFLAGS] is never set there
- it is merging not only rtti, but the whole cxxflags (defines etc)
which has proven to be a source of troubles (breaks debugging etc.)
This is required in order for clang to correctly handle the OpenCL C
barrier() builtin which has the following restrictions acording to
the OpenCL 1.1 Specification:
If barrier is inside a conditional statement, then all work-items must
enter the conditional if any work-item enters the conditional statement
and executes the barrier.
If barrier is inside a loop, all work-items must execute the barrier for
each iteration of the loop before any are allowed to continue execution
beyond the barrier.
By linking before otimizations, we can replace calls to barrier() with
calls to a target specific intrinsic which has the noduplicate attribute
This attribute prevents clang from performing optimizations which could
violate the above rules.
This attribute must be applied to the call instruction that invokes
the function, so it is not enough to add this attribute the barrier()
declaration.
As a bonus this will probably speed up compile times since we will no
longer need to run link-time optimizations.
During the recent bind_sampler_states() interface change in gallium
we changed the CSO single_sampler_done() function so that if we were
decreasing the number of sampler states bound in the driver, we'd
null-out the "extra/old" sampler states to unbind them. See commit
1e2fbf265.
However, we didn't make the corresponding fix for sampler views.
This caused an assertion to fail in the svga driver which checked
that the number of sampler views matched the number of sampler states.
This patch fixes cso_restore_sampler_views() so that it nulls-out
the extra/old sampler views if the number of new views is less than
the number of current/old views.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Use GL_MAP_INVALIDATE_RANGE, UNSYNCHRONIZED and FLUSH_EXPLICIT flags
when mapping VBOs during display list compilation. This mirrors what
we do for immediate-mode VBO building in vbo_exec_vtx_map().
This improves performance for applications which interleave display
list compilation with execution. For example:
glNewList(A);
glBegin/End prims;
glEndList();
glCallList(A);
glNewList(B);
glBegin/End prims;
glEndList();
glCallList(B);
Mesa's vbo module tries to combine the vertex data from lists A and B
into the same VBO when there's room. Before, when we mapped the VBO for
building list B, we did so with GL_MAP_WRITE_BIT only. Even though we
were writing to an unused part of the buffer, the map would stall until
the preceeding drawing call finished.
Use the extra map flags and FlushMappedBufferRange() to avoid the stall.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Instead of checking width==height in four places, just do it in
_mesa_legal_texture_dimensions() where we do the other width, height,
depth checks. Similarly, move the check that cube map array depth is
a multiple of 6.
This change also fixes some missing cube dimension checks for the
glTexStorage[23]D() functions.
Remove width==height assertion in _mesa_get_tex_max_num_levels() since
that's called before the other size checks for glTexStorage.
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
We can now add GBM support for the 10 bit/channel formats which lets us
create a gbm surface that we can use with KMS for display hardware that
support the format.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
We add support for the ARGB2101010 color format to the DRI image extension,
which allows DRI loaders to create a __DRIimage with this color format.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
This commit enables ARGB2101010 system framebuffers (that is, DRI drawables)
for the i965 drivers. This is done by generating DRI configs that advertise
this color format as well as teaching intelCreateBuffer to pick the right
color format when it sees such a DRI config.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
This extends the common dri driver infrastructure with the ability to create
__DRIconfigs for 10 bits/channel + 2 bit alphs formats. This still has
to be supported and requested by a driver, so this doesn't enable anthing yet.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
The EGLConfig doesn't have the rgba masks, only the rgba sizes. To
make sure a config is usable with a given GBM/KMS format, we need a way
to make sure the formats really match.
All callers now use the more correct rgba mask mechanism for filtering
out mathcing DRI configs. Even if depth and buffer size match, the
color component layout can be different, or in case or ARGB8888 and
ARGB2101010 the color components can even be different sizes.
Since anything that the depth check would reject is also rejected by
the rgba mask comparison, the depth parameter is redundant and not
specific enough. We should probably have removed it when the rgba
masks argument was introduced, but better late than never.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Matching on visual depth to buffer size makes 8 bpc RGBA look similar to
10 bit RGB with 2 bit alphs - both have buffer size 32. Instead, build
the rgba masks from the visual data and use that for finding matching
DRI configs.
We need to keep the special case that allows us to match 24 bit visuals
to DRI configs with buffer size 32. We do that by creating an alpha
mask of "all the non-rgb bits" for 24 bit visuals and matching a second
time with that.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Add information for RGB565 to the table of image formats so that we can
create a __DRIimage for that format. This in turn enables RGB565
wayland clients.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
With this patch Wayland clients can now ask EGL for RGB 565 format buffers
and attach them to a Wayland compositor.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
* The rtti fix actually dug up a bug in the scons build scripts.
* Autotools took the LLVM cpp and cxx flags, while scons only took
the cpp flags.
* This grabs the cxx flags and applies them where needed. We may
want to make the same change for the llvm cpp flags in scons.
* The only linux platform I can find with LLVM no-rtti is Ubuntu.
* Fixes bug #70471
Tested-by: Vinson Lee <vlee@freedesktop.org>
The original intent of the variable was to prevent adding
libdrm dependency for non drm drivers (swrast). This is
already handled with __NOT_HAVE_DRM_H, and with the recent
merge of the dri_util and drisw_util code this variable has
started causing build issues.
Eg. the following will fail
$ ./autogen.sh --with-dri-drivers=swrast --with-gallium-drivers=
$ make
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.com>
When a geometry shader is active, the transform feedback primitive
type ("mode") needs to be validated against the geometry shader output
primitive type, not the primitive type passed to the glDraw*()
function.
Fixes the following piglit tests:
- glsl-1.50-geometry-primitive-types GL_LINES
- glsl-1.50-geometry-primitive-types GL_LINES_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_LINE_STRIP
- glsl-1.50-geometry-primitive-types GL_LINE_STRIP_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_TRIANGLES
- glsl-1.50-geometry-primitive-types GL_TRIANGLES_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_TRIANGLE_FAN
Exposes previously hidden failures in the following piglit tests:
- glsl-1.50-geometry-primitive-id-restart GL_LINES other
- glsl-1.50-geometry-primitive-id-restart GL_LINES_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_LOOP ffs
- glsl-1.50-geometry-primitive-id-restart GL_LINE_LOOP other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_STRIP other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_STRIP_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLES other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLES_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_FAN ffs
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_FAN other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY other
(These failures were previously hidden due to a flaw in the test: it
doesn't check for GL errors. I'll fix the test shortly).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Ivy Bridge's "reorder enable" bit gives us a binary choice for the
order in which vertices from triangle strips are delivered to the
geometry shader. Neither choice follows the OpenGL spec, but setting
the bit is better, because it gets triangle orientation correct.
Haswell replaces the "reorder enable" bit with a new "reorder mode"
bit (which occupies the same location in the command packet). This
bit gives us a different binary choice, which affects both triangle
strips and triangle strips with adjacency. Setting the bit ("reorder
trailing") gives the proper order according to the OpenGL spec.
So in either case we want to set the bit.
On Ivy Bridge, fixes piglit test "triangle-strip-orientation".
On Haswell, fixes piglit tests "glsl-1.50-geometry-primitive-types
{GL_TRIANGLE_STRIP,GL_TRIANGLE_STRIP_ADJACENCY}" and
"glsl-1.50-geometry-tri-strip-ordering-with-prim-restart *".
v2: Rename the bit to "REORDER_TRAILING" for consistency with Haswell
docs.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Despite the name, this field wasn't being set to the dispatch width at
all; it was always 8. The only place it was used was that the
constant buffer read length was aligned to it, and as far as I can
tell from the docs, there is no need to align this value to the
dispatch width; aligning it to a multiple of 8 is sufficient. So I've
just replaced it with a hardcoded 8.
v2: In gen6_wm_state, use brw->wm.base.push_const_size for consistency
with VS and GS state upload.
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch populates the following built-in GLSL 1.50 variables based
on constants stored in ctx->Const:
- gl_MaxVertexOutputComponents
- gl_MaxGeometryInputComponents
- gl_MaxGeometryOutputComponents
- gl_MaxFragmentInputComponents
- gl_MaxGeometryTextureImageUnits
- gl_MaxGeometryOutputVertices
- gl_MaxGeometryTotalOutputComponents
- gl_MaxGeometryUniformComponents
- gl_MaxGeometryVaryingComponents
On i965/gen7, fixes all Piglit tests in "spec/glsl-1.50/built-in
constants/*" except for gl_MaxCombinedTextureImageUnits and
gl_MaxGeometryUniformComponents.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Now that both vec4 and fs are dynamically assigning offsets, a lot of the
code is the same.
v2: Avoid passing around the next offset through the class. (Review by
Paul)
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Note that the dropped comment in brw_context.h is mostly (better written)
in brw_binding_table.c as well.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
It would be nice to be able to pack our binding table so that programs
that use 1 render target don't upload an extra BRW_MAX_DRAW_BUFFERS - 1
binding table entries. To do that, we need the compiled program to have
information on where its surfaces go.
v2: Rename size to size_bytes to be more explicit.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
* As discussed on the mailing list,
forced no-rtti breaks C++ public
API's such as the Haiku C++ libGL.so
* -fno-rtti *can* be still set however
instead of blindly forcing -fno-rtti,
we can rely on the llvm-config
--cppflags output.
If the system llvm is built without
rtti (default), the no-rtti flag will be
present in llvm-config --cppflags
(which we pick up on)
If llvm is built with rtti
(REQUIRES_RTTI=1), then -fno-rtti is
removed from llvm-config --cppflags.
* We could selectively add / remove rtti
from various components, however mixing
rtti and non-rtti code is tricky and
could introduce missing symbols.
* This needs impact tested.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Add simple plain C routines for NV12<->YV12 and YUYV<->UYVY
conversions. The NV12->YV12 conversion is commonly used, for instance
by VLC.
Reviewed-by: Christian König <christian.koenig@amd.com>
Textures that likely reside in VRAM, are mapped for reading and
don't require direct mapping should be staged into GTT, to avoid bad
performance. This fixes readback performance of VDPAU surfaces.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This new bind flag forces linear storage, but does not have other
side effects like R600_RESOURCE_FLAG_TRANSFER.
Reviewed-by: Christian König <christian.koenig@amd.com>
Currently it's hardcoded in the shader, so every change requires
compilation of the shader variant, killing the performance
in Serious Sam 3 and probably other apps.
This patch passes alpha_ref in the user sgpr and removes it from
the shader key.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This fixes the issue when dst and src is the same reg and operation on one
channel overwrites the source for other channels, e.g.:
UMUL TEMP[2].xyz, TEMP[0].xyzz, TEMP[2].xxxx
In this example the result of the operation on channel x is written in
TEMP[2].x and then used as a second source operand for channels y and z
instead of original value in TEMP[2].x.
This patch stores the results in temp reg and moves them to
dst after performing operation on all channels.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=70327
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
v2: Keep the random 32-bit only version of memcpy, since Ian says I
can't delete it without data proving it isn't useful.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
brw_context.h includes imports.h which includes compiler.h which already
defines these.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These make it easy to convert a floating point value to a fixed point
numbers. The second parameter is the number of bits used for the
fractional part of the number.
It looks like core Mesa has similar functions already, but none that
allows an arbitrary number of fractional bits. The more generic version
is probably useful to everyone.
r600g apparently has an identical copy of the S_FIXED macro, but doesn't
include this file. I'm not sure what to do about that, so I'm just
going to leave it for now.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This seems generally useful, so it may as well live in core Mesa.
In fact, the comment for ALIGN() in macros.h actually says to "see also"
ROUND_DOWN_TO, which...was in a driver somewhere.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
intel_batchbuffer_init() sets up initial batchbuffer state; it seems
like a reasonable place to initialize this flag.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Configuring which dirty flags we want sounds like a job for
brw_init_state().
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It actually just wants generation checking, and brw->gen is the usual
way of doing that. In the future, we'll also want to check brw->hw_ctx,
which isn't available from the screen.
While we're changing the function signature, convert from camel case to
our usual naming conventions.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
There's no point in having two files for context functions. This patch
moves the code from intel_context.c into brw_context.c unmodified
(other than whitespace fixes).
Right now, this looks silly; future patches will merge functions and
tidy things up.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
brw_init_surface_formats already sets entries in TextureFormatsSupported
to true; it may as well take care of initializing it to false too.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This flag is only used in one place, and is only set on one platform.
Just check for original Gen4 in the relevant function.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This seems like a better place for it, and helps clean up
brwCreateContext (which is full of a lot of random stuff).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This was always set to false, and is only used for debugging.
To enable it, simply change the if (0) block and recompile.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since each kind of device has its own brw_device_info structure, we can
simply store the URB and thread limits there. This eliminates all the
large if-ladders, and simplifies the context initialization code quite a
bit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This option was useful during initial development, but it's been ages
since I've heard of anyone using it. Plus, Gen7+ mandates separate
stencil, so it was really only useful on Sandybridge anyway.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The idea is that struct brw_device_info should store statically-known
information about hardware features. Using the new family name in the
PCI ID table, we can easily grab the right structure.
This is basically the equivalent of intel_device_info in the kernel.
This patch also makes the new structure available from intel_screen, but
nothing uses it. Right now, it looks very redundant with existing
fields, but that will change.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I removed this a while ago, since we never used it, but I'm finally
resurrecting the idea in the next commits.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Nothing uses the #define name, and it's not terribly useful - the
numerical ID serves the same purpose. The only thing we could really do
with it is generate slightly prettier preprocessed code. But who looks
at that?
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Using a helper function clarifies the context initialization code.
I would've liked to completely centralize it, but moving the optionCache
code from intelInitExtensions into here would've required setting flags
in the context, which seems like a waste.
v2: Rebase for the introduction of disable_derivative_optimization.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now that intelInitContext isn't shared between i915 and i965, the split
is fairly arbitrary. This patch moves a bunch of the basic context
creation and generation checking code up to the top-level function
(and slightly earlier).
More will follow.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now that there isn't an intel_context structure, the split between
brw_context.[ch] and intel_context.[ch] is rather awkward and arbitrary.
Removing intel_context.[ch] seems desirable, but not everything really
belongs in brw_context.[ch], either.
Moving INTEL_DEBUG handling into separate intel_debug.[ch] files should
make them relatively easy to find.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
"error" is a very generic name. dri_ctx_error is the name used in
intelInitContext(), which is more specific.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Geometry shader support is now working well, and adequately piglit
tested. There are just a few piglit failures left to fix. So there's
no need for an "experimental" warning anymore.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Geometry shaders were the last thing we needed to finish before
turning on GLSL 1.50 and GL 3.2 support. They are now working well,
with just a few piglit failures left to fix.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
With code dump enabled LLVM may generate disassembly during compilation.
Show this disassembly when available and prefer it to SI bytecode dump.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Jay Cornwall <jay@jcornwall.me>
Fix coord wrapping (and face selection too) in case of edges.
Unfortunately, the coord wrapping is way more complicated than what
the code did, as it depends on the face and the direction where the
texel falls off the face (the logic needed to get this right in fact
seems utterly ridiculous).
Also fix a bug in (y direction under/overflow) face selection.
And get rid of complicated cube corner handling. Just like edge case,
the coord wrapping was wrong and it seems very difficult to fix.
I'm near certain it can't always work anyway (though ordinary seamless
filtering on edge has actually a similar problem but not as severe)
because we don't have per-pixel face, hence could have multiple corner
texels which would make it very difficult to average the remaining texels
correctly. Hence simply pick a texel which would only have fallen off one
edge but not both instead, which is not quite accurate but actually I think
should be enough to meet OpenGL (but not d3d10) requirements.
v2: small fixes suggested by Brian, add some comments.
Reviewed-by: Brian Paul <brianp@vmware.com>
The previous limit of of 128*1024 was reported to cause frequent recompiles
in some apps due to shader variant thrashing on IRC in some apps leading
to noticeable lags.
Note that the LP_MAX_SHADER_VARIANTS limit (1024) was more or less impossible
to reach, since even simple fragment shaders without texturing (glxgears) used
more than twice than 128 instructions, hence the instruction limit would have
always been reached first (excluding things like trivial shaders not writing
color). Even with the new limit it is VERY likely the instruction limit is hit
first.
Should help with such lags due to recompiles (though other shader types have
their own limits, LP_MAX_SETUP_VARIANTS and DRAW_MAX_SHADER_VARIANTS, in
particular the latter seems a bit small (128)).
Reviewed-by: Brian Paul <brianp@vmware.com>
Fixes this build error.
CC imports.lo
../../src/mesa/main/imports.c: In function '_mesa_strtof':
../../src/mesa/main/imports.c:570:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'loc'
../../src/mesa/main/imports.c:570:20: error: 'loc' undeclared (first use in this function)
../../src/mesa/main/imports.c:570:20: note: each undeclared identifier is reported only once for each function it appears in
../../src/mesa/main/imports.c:572:7: error: implicit declaration of function 'newlocale'
../../src/mesa/main/imports.c:572:23: error: 'LC_CTYPE_MASK' undeclared (first use in this function)
../../src/mesa/main/imports.c:574:4: error: implicit declaration of function 'strtof_l'
../../src/mesa/main/imports.c:580:1: warning: control reaches end of non-void function
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Now that libEGL has been fixed to not leak all kinds of symbols, gbm
links to its own copy of the libwayland-drm.a helper library. That means
we can't rely on comparing the addresses of a static vtable symbol in that
library to determine if a wl_buffer is a wl_drm_buffer. Instead, we
move the vtable into the wl_drm struct and use that for comparing.
https://bugs.freedesktop.org/show_bug.cgi?id=69437
Cc: 9.2 <mesa-stable@lists.freedesktop.org>
execinfo.h is not available on NetBSD.
Fixes this bulid error.
CC glapi_gentable.lo
glapi_gentable.c:44:22: fatal error: execinfo.h: No such file or directory
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
This was overriding the top-level .dir-locals.el causing some settings
(like forcing spaces instead of tabs!) to be lost.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We should be able to safely set the framebuffer state without a
fragment shader bound. bind_ps_state will take care of updating the
necessary state bits later.
v2: check in update_db_shader_control
Fixes GL2ExtensionTests/egl_image_external/TestSimpleUnassociated.test
which is part of gles2/3 conformance suite. Here image external
textures are switched to be treated the same as 2D textures. These
can be associated with the fallback texture providing fixed sample
values of (0, 0, 0, 1).
The OES_EGL_image_external spec says:
"Sampling an external texture which is not associated with any EGLImage
sibling will return a sample value of (0,0,0,1)."
"External textures cannot be used with TexImage2D, TexSubImage2D,
CompressedTexImage2D, CompressedTexSubImage2D, CopyTexImage2D, or
CopyTexSubImage2D, and an INVALID_ENUM error will be generated if
this is attempted."
And quoting Chad:
"That's enforced in _mesa_TexImage*() by calling
legal_teximage_target(), and enforced in _mesa_TexSubImage*() by
calling legal_texsubmimage_target(). Each of the
legal_tex*image_target() functions reject external textures.
Therefore, allowing GL_TEXTURE_EXTERNAL_OES in store_texsubimage()
won't violate the above spec quote.
I think it's safe to allow GL_TEXTURE_EXTERNAL_OES in
store_texsubimage(), as long as the texture has only a single
plane. Luckily, that's the only type of external textures that
Mesa currently supports."
CC: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Extend the fast texture upload from BGRA X-tiled to include RGBA,
Alpha/Luminance, and Y-tiled. Speed improvements, measured with
mesa demos teximage program, on 256 x 256 texture, in MB/s, on a
Sandy Bridge (Ivy is comparable):
before after increase
BGRA/X-tiled 3266 4524 1.39x
BGRA/Y-tiled 1739 3971 2.28x
RGBA/X-tiled 474 4694 9.90x
RGBA/Y-tiled 477 3368 7.06x
L/X-tiled 1268 1516 1.20x
L/Y-tiled 1439 1581 1.10x
v2: Cosmetic changes only: reformat and reword comments, make doxygen-friendly,
rename variables, use existing macros, add an assert.
Signed-off-by: Frank Henigman <fjhenigman@google.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
This is part of the prep for megadrivers, which won't allow using a single
global symbol due to the fact that there will be multiple drivers built
into the same dri.so file. For that, we'll need screen init to take a
reference to the driver to set up this vtable.
v2: Fix two missed references to driDriverAPI.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
The intel_screen.c used to be a dispatch to one of 3 driver functions, but
was down to 1, so it was kind of a waste. In addition, it was trying to
free all of the data that might have been partially freed in the kernel
3.6 check (which comes after intelInitContext, and thus might have had
driverPrivate set and result in intelDestroyContext() doing work on the
freed data). By moving the driverPrivate setup earlier, we can use
intelDestroyContext() consistently and avoid such problems in the future.
v2: Adjust the prototype of brwCreateContext to use the proper enum
(fixing a compiler warning in some builds)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
If bufmgr didn't get created, then screen creation failed, and we never
should have got here in the first place. This was added by Chris Wilson
in 2010 with no explanation for why it would be needed.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965, i915, radeon, r200, swrast, and nouveau were mostly trying to do the
same logic, except where they failed to. Notably, swrast had code that
appeared to try to enable GLES1/2 but forgot to set api_mask (thus
preventing any gles context from being created), and the non-intel drivers
didn't support MESA_GL_VERSION_OVERRIDE.
nouveau still relies on _mesa_compute_version(), because I don't know what
its limits actually are, and gallium drivers don't declare limits up front
at all. I think I've heard talk about doing so, though.
v2: Compat max version should be 30 (noted by Ken)
Drop r100's custom max version check, too (noted by Emil Velikov)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The only important difference was not calling drmGetVersion, and making
the swrast extension vtable. That doesn't justify duplicating the other
330 lines of code.
v2: fix the scons build (code by Emil Velikov)
v3: fix scons build with swrast-only (code by Emil Velikov)
v4: Drop the new define I added, when we already have __NOT_HAVE_DRM_H.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Looking at Lightsmark's shaders, the way we used MRFs (or in gen7's
case, GRFs) was bad in a couple of ways. One was that it prevented
compute-to-MRF for the common case of a texcoord that gets used
exactly once, but where the texcoord setup all gets emitted before the
texture calls (such as when it's a bare fragment shader input, which
gets interpolated before processing main()). Another was that it
introduced a bunch of dependencies that constrained scheduling, and
forced waits for texture operations to be done before they are
required. For example, we can now move the compute-to-MRF
interpolation for the second texture send down after the first send.
The downside is that this generally prevents
remove_duplicate_mrf_writes() from doing anything, whereas previously
it avoided work for the case of sampling from the same texcoord twice.
However, I suspect that most of the win that originally justified that
code was in avoiding the WAR stall on the first send, which this patch
also avoids, rather than the small cost of the extra instruction. We
see instruction count regressions in shaders in unigine, yofrankie,
savage2, hon, and gstreamer.
Improves GLB2.7 performance by 0.633628% +/- 0.491809% (n=121/125, avg of
~66fps, outliers below 61 dropped).
Improves openarena performance by 1.01092% +/- 0.66897% (n=425).
No significant difference on Lightsmark (n=44).
v2: Squash in the fix for register unspilling for send-from-GRF, fixing a
segfault in lightsmark.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Matt Turner <mattst88@gmail.com>
For texturing from GRFs, we now have payloads of arbitrary sizes up to the
message length limit.
v2 (Kenneth Graunke): Rebase on intel_context -> brw_context change.
v3: Add some comment text.
v4: Change some magic 16s to BRW_MAX_MRF (noted by Ken). Leave the 11,
which is the magic "max sampler message length". BRW_MAX_MRF sizing
on the little int arrays is retained because I could see us needing to
extend in the future if we move to GRFs for FB writes (those go to at
least 12 long in a quick scan of the specs)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v2)
Acked-by: Matt Turner <mattst88@gmail.com>
This will let us coalesce into texture-from-GRF arguments, which would
otherwise be prevented due to the live interval for the whole vgrf
extending across all the MOVs setting up the channels of the message
v2 (Kenneth Graunke): Rebase for renames.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Now optimization passes will be able to look at the per-channel ranges.
v2: Rebase on various optimization pass changes.
v3 (Kenneth Graunke): Rename live_variables to live_intervals; split
introduction of invalidate_live_intervals() into a separate patch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When compacting the list of VGRFs, we patch up the live interval ranges
(which are indexed by VGRF number). Unfortunately, once we make
per-component data available, this will become too complicated to
maintain. Instead, simply invalidate them.
This was pulled out of a patch by Eric Anholt.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
In compute_live_intervals(), start and end are shorter names for
the virtual_grf_start and virtual_grf_end class members.
Now that the fs_live_intervals class has arrays named start and end
which are indexed by var, rather than VGRF, reusing the name is
confusing. Plus, most of the code has been factored out, so using the
long names isn't as inconvenient.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is the information we'll actually use to replace the
virtual_grf_start[]/end[] arrays.
No change in shader-db.
v2 (Kenneth Graunke): Rebase; minor comment updates.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These blocks are about to grow some more code, and the indentation was
getting out of hand.
v2 (Kenneth Graunke): Rebase, minor typo fixes and style changes.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For now, this simply sets live_intervals_valid = false, but in the
future it will do something more sophisticated.
Based on a patch by Eric Anholt.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This significantly improves our handling of VGRFs of size > 1.
Previously, we only marked VGRFs as def'd if the whole register was
written by a single instruction. Large VGRFs which were written
piecemeal would not be considered def'd at all, even if they were
ultimately completely written.
Without being def'd, these were then marked "live in" to the basic
block, often extending the range to preceding blocks and sometimes
even the start of the program.
The new per-component tracking gives more accurate live intervals,
which makes register coalescing more effective.
In the future, this should help with texturing from GRFs on Gen7+.
A sampler message might be represented by a 2-register VGRF which
holds the texture coordinates. If those are incoming varyings,
they'll be produced by two PLN instructions, which are piecemeal writes.
No reduction in shader-db instruction counts. However, code which
prints the live interval ranges does show that some VGRFs now have
smaller (and more correct) live intervals.
v2: Rebase on current send-from-GRF code requiring adding extra use[]s.
v3: Rebase on live intervals fix to include defs in the end of the
interval.
v4 (Kenneth Graunke): Rebase; split off a few preparatory patches;
add lots of comments; minor style changes; rewrite commit message.
v5 (Eric Anholt): whitespace nit.
Written-by: Eric Anholt <eric@anholt.net> [v1-3]
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [v4]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> (v4)
num_vars was shorthand for the number of virtual GRFs. num_vgrfs is a
bit clearer. Plus, the next patch will introduce "vars" which are
distinct from vgrfs.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This has no functional effect, but should make subsequent changes a
little simpler.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
From section 4.1.9 (Arrays) of the GLSL 4.40 spec (as of revision 7):
However, unless noted otherwise, blocks cannot be redeclared;
an unsized array in a user-declared block cannot be sized
through redeclaration.
The only place where the spec notes that interface blocks can be
redeclared is to allow for redeclaration of built-in interface blocks
such as gl_PerVertex. Therefore, user-defined interface blocks can
never be redeclared. This is a clarification of previous intent (see
Khronos bug 10659).
We were already preventing interface block redeclaration using the
same block name at compile time, but we weren't preventing interface
block redeclaration using the same instance name (and different block
names) at compile time. And we weren't preventing an instance name
from conflicting with a previously-declared ordinary variable.
In practice the problem would be caught at link time, but only because
of a coincidence: since ast_interface_block::hir() wasn't doing any
checking to see if the instance name already existed in the shader, it
was creating a second ir_variable in the shader having the same name
but a different type. Coincidentally, when the linker checked for
intrastage consistency of global variable declarations, it treated the
two declarations from the same shader as a conflict, so it reported a
link error.
But it seems dangerous to rely on that linker behaviour to catch
illegal redeclarations that really ought to be detected at compile
time.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch verifies that:
- The gl_PerVertex input interface block may only be redeclared in a
geometry shader, and that it may only be redeclared as gl_in[].
- The gl_PerVertex output interface block may only be redeclared in a
vertex or geometry shader, and that it may only be redeclared as a
non-array without an interface name.
- gl_PerVertex may not be redeclared as any other type of interface
block (i.e. as a uniform interface block).
As a side-effect, the code now keeps track of what the previous
declaration of gl_PerVertex was--this will be needed in future
patches.
Fixes piglit tests:
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-in-with-incorrect-name.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-as-array.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-with-instance-name.geom
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
In later patches, we'll use this in order to implement the required
behaviour that after the gl_PerVertex interface block has been
redeclared, only members of the redeclared interface block may be
used.
v2: Update the function name and comment to clarify that we aren't
actually removing the variable from the symbol table, just disabling
it.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This will be used by future patches to change an ir_variable's
interface type when the gl_PerVertex built-in interface block is
redeclared.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch modifies the get_variable_being_redeclared() function so
that it no longer relies on the ast_declaration for the variable being
redeclared. In future patches, this will allow
get_variable_being_redeclared() to be used for processing
redeclarations of the built-in gl_PerVertex interface block.
v2: Also make get_variable_being_redeclared() static.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Note: we need to make an exception for the gl_PerVertex interface
block, since in geometry shaders it is allowed to be redeclared with
the instance name gl_in. Future patches will make redeclaration of
gl_PerVertex work properly.
Fixes piglit test
spec/glsl-1.50/compiler/interface-block-instance-name-uses-gl-prefix.vert.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Note: we need to make an exception for the gl_PerVertex interface
block, since built-in variables are allowed to be redeclared inside
it. Future patches will make redeclaration of gl_PerVertex work
properly.
Fixes piglit tests:
- spec/glsl-1.50/compiler/interface-block-array-elem-uses-gl-prefix.vert
- spec/glsl-1.50/compiler/named-interface-block-elem-uses-gl-prefix.vert
- spec/glsl-1.50/compiler/unnamed-interface-block-elem-uses-gl-prefix.vert
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Note: we need to make an exception for the gl_PerVertex interface
block, since this is allowed to be redeclared. Future patches will
make redeclaration of gl_PerVertex work properly.
Fixes piglit test
spec/glsl-1.50/compiler/interface-block-name-uses-gl-prefix.vert.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Note: some limited amount of redeclaration is actually allowed,
provided the shader is redeclaring the built-in gl_PerVertex interface
block. Support for this will be added in future patches.
Fixes piglit tests
spec/glsl-1.50/compiler/unnamed-interface-block-elem-conflicts-with-prev-{block-elem,global}.vert.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
GLSL reserves identifiers beginning with "gl_" or containing "__", but
we haven't been consistent about enforcing this rule. This patch
makes a new function to check whether identifier names are valid. In
the process it closes a loophole where we would previously allow
function argument names to contain "__".
v2: Rename check_valid_identifier() -> validate_identifier(). Add
curly braces in validate_identifier().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
In commit e2660770731b018411fbe1620cacddaf8dff5287 (glsl: Keep track
of location for interface block fields), I neglected to update
glsl_type::record_key_compare to account for the fact that interface
types now contain location information. As a result, interface types
that differ only by their location information would not be properly
distinguished.
At the moment this is not a problem, because the only interface block
in which location information != -1 is gl_PerVertex, and gl_PerVertex
is always created in the same way. However, in the patches that
follow, we'll be adding new ways to create gl_PerVertex (by
redeclaring it), so we'll need location information to be handled
properly.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Although these interfaces can't be accessed directly by GLSL (since
they don't have an instance name), they will be necessary in order to
allow redeclarations of gl_PerVertex.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Currently, we create just a single gl_PerVertex interface block for
geometry shader inputs. In later patches, we'll also need to create
an interface block for geometry and vertex shader outputs. Moving the
code into its own class will make reuse easier.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We use a location of -1 for variables which don't have their own
assigned locations--this includes ir_variables which represent named
interface blocks. Technically the location assigned to gl_in doesn't
matter, since gl_in is only accessed via its members (which have their
own locations). But it's nice to be consistent.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Calling radeon_drm_cs_flush from multiple threads might cause deadlocks,
fix this by immediately signaling the semaphore after waiting for it.
This is a candidate for the stable branch(es).
Partially fixes: https://bugs.freedesktop.org/show_bug.cgi?id=70123
v2: some fixes on commit message
Signed-off-by: Christian König <christian.koenig@amd.com>
Unless the polygon fill mode is different from PIPE_POLYGON_MODE_FILL,
so checking the the polygon mode is sufficient.
Testing done: no regression in polygon-mode-offset
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Not used since ages, and it wouldn't work at all with explicit derivatives now
(not that it did before as it ignored them but now the code would just use
the derivs pre-projected which would be quite random numbers).
v2: also get rid of 3 helper functions no longer used.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
They need some special handling. Quite complicated.
Additionally, use the same code for implicit derivatives too if no_rho_approx
and no_quad_lod is set, because it seems while generally it should be ok
to use per quad lod for implicit derivatives there's at least some test which
insists that in case of cubemaps the shared lod value MUST come from a pixel
inside the primitive (due to the derivatives becoming different if a different
larger major axis is chosen).
v2: based on Brian's feedback, clean up code a bit.
And use sign bit of major axis instead of pre-select s/t/r sign for coord
mirroring (which should be the same in the end, saves 2 ands).
Also fix two bugs with select/mirror of derivatives, the minor axes need to
use major axis sign as well (instead of major derivative axis sign), and
don't mistakenly use absolute values of major derivative and inverse major
values.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
There's two reasons for this:
1) even when ignoring rho approximation for cube maps, the result is still
not correct, but it's better as the max error at edges is now sqrt(2) instead
of 2 (which was a full mip level), same as it is for ordinary 2d maps when
doing rho approximations (so the error actually goes from factor 2 at edges and
sqrt(2) completely inside a face to sqrt(2) at edges and 0 inside a face).
2) I want to repurpose rho_no_approx for cubemaps for fully correct cubemap
derivatives (so don't need yet another debug var).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
We were already setting the array size of unsized arrays that appeared
inside unnamed interface blocks, but we weren't updating
ir_variable::interface_type to reflect the new array size, causing
bogus link errors.
This patch causes array_sizing_visitor to keep track of all the
unnamed interface types it sees, and the ir_variables corresponding to
each one. After the visitor runs, a new function,
fixup_unnamed_interface_types(), adjusts each unnamed interface type
to correctly correspond with the array sizes in the ir_variables.
Fixes piglit tests:
- spec/glsl-1.50/execution/unsized-in-unnamed-interface-block-gs
- spec/glsl-1.50/execution/unsized-in-unnamed-interface-block-multiple
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When multiple shaders of the same type access an interface block
containing an unsized array, we need to set the array size based on
the maximum array element accessed across all the shaders. This is
similar to what we already do with unsized arrays occurring outside of
interface blocks.
Note: one corner case is not yet addressed by these patches: the case
where one compilation unit defines an interface block containing
unsized arrays and another compilation unit defines the same interface
block containing sized arrays.
Fixes piglit test:
- spec/glsl-1.50/execution/unsized-in-named-interface-block-multiple
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Unsized arrays appearing inside named interface blocks now get a
proper size assigned by the array_sizing_visitor.
Fixes piglit tests:
- spec/glsl-1.50/execution/unsized-in-named-interface-block
- spec/glsl-1.50/execution/unsized-in-named-interface-block-gs
- spec/glsl-1.50/linker/unsized-in-named-interface-block
- spec/glsl-1.50/linker/unsized-in-named-interface-block-gs
- spec/glsl-1.50/linker/unsized-in-unnamed-interface-block-gs (*)
(*) is fixed by dumb luck--support for unsized arrays in unnamed
interface blocks will come in a later patch.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This patch modifies update_max_array_access() so that it updates
ir_variable::max_ifc_array_access to reflect the shader's use of
arrays appearing within interface blocks.
v2: Use an ordinary function in ast_array_index.cpp rather than a
virtual function in ir_rvalue. Avoid dereferencing NULL when handling
accesses to ordinary structs.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
For interface blocks that contain arrays, this field will contain the
maximum element of each contained array that is accessed by the
shader. This is a first step toward supporting unsized arrays in
interface blocks.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Currently, when converting an access to an array element from ast to
IR, we need to see if the array is an ir_dereference_variable, and if
so update the variable's max_array_access.
When we add support for unsized arrays in interface blocks, we'll also
need to account for cases where the array is an ir_dereference_record
and the record is an interface block.
To make this easier, move the update into its own function.
v2: Use an ordinary function in ast_array_index.cpp rather than a
virtual function in ir_rvalue.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Although it's not explicitly stated in the GLSL 1.50 spec, unsized
arrays are allowed in interface blocks.
section 1.2.3 (Changes from revision 5 of version 1.5) of the GLSL
1.50 spec says:
* Completed full update to grammar section. Tested spec examples
against it:
...
* add unsized arrays for block members
And section 7.1 (Vertex and Geometry Shader Special Variables)
includes an unsized array in the built-in gl_PerVertex interface
block:
out gl_PerVertex {
vec4 gl_Position;
float gl_PointSize;
float gl_ClipDistance[];
};
Furthermore, GLSL 4.30 contains an example of an unsized array
occurring inside an interface block. From section 4.3.9 (Interface
Blocks):
uniform Transform { // API uses "Transform[2]" to refer to instance 2
mat4 ModelViewMatrix;
mat4 ModelViewProjectionMatrix;
vec4 a[]; // array will get implicitly sized
float Deformation;
} transforms[4];
This patch adds the parser rule to support unsized arrays inside
interface blocks. Later patches in the series will add the
appropriate semantics to handle them.
Fixes piglit tests:
- spec/glsl-1.50/execution/unsized-in-unnamed-interface-block
- spec/glsl-1.50/linker/unsized-in-unnamed-interface-block
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Interface declarations have two names associated with them: the block
name and the instance name. It's the block name that needs to be
passed to get_interface_instance(). This patch renames the argument
so that there's no confusion.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
BLORP performs blits by drawing a rectangle with a shader that samples
from the source texture, and writes color data to the destination.
The sampler always returns 32-bit RGBA float data, regardless of the
source format's component ordering or data type. Likewise, the render
target write message takes 32-bit RGBA float data, and converts it
appropriately. So the bulk of the work is already taken care of for us.
This greatly accelerates a lot of CopyTexSubImage calls, and makes
Legends of Aethereus playable on Ivybridge. At the default settings,
LOA continually blits between SRGBA8888 (the window format) and
RGBA16_FLOAT. Since neither BLORP nor our BLT paths supported this,
it fell back to meta, spending 33% of the CPU in floorf() converting
between floats and half-floats.
v2: Use != instead of ^ (suggested by Ian). Note that only
CopyTexSubImage is affected by this patch (caught by Eric).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The previous code for sRGB overrides assumes that the source and
destination formats are equal, other than the color space. This won't
be feasible when we add support for format conversions.
Here are a few cases, and how the old code handled them:
1. RGB8 -> SRGB8, MSAA ==> SRGB8 -> SRGB8
2. RGB8 -> SRGB8, single ==> RGB8 -> RGB8
3. SRGB8 -> RGB8, MSAA ==> RGB8 -> RGB8
4. SRGB8 -> RGB8, single ==> SRGB8 -> SRGB8
Apparently, preserving the behavior of #1 is important. When doing a
multisample to single-sample resolve, blending the samples together in
an sRGB correct fashion results in a noticably higher quality image.
It also is necessary to pass Piglit's EXT_framebuffer_multisample
accuracy color tests.
Paul, Eric, Anuj, and I talked about this, and aren't sure that it
matters in the other cases.
This patch preserves the behavior of #1, but otherwise reverts to
doing everything in linear space, changing the behavior of case #4.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We could conceivably use BRW_SURFACEFORMAT_R24_UNORM_X8_TYPELESS for
Z24 source images, allowing conversions from Z24 to either Z16 or Z32F.
Unfortunately, we can't use it for destination images since it isn't
supported as a render target.
Using different formats for sources or destinations would be painful,
so for now, punt.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, all that matters is that we copy the correct number of bits,
so any format that has 32-bits of data will work fine.
Once BLORP begins handling format conversions, the sampler will need to
correctly interpret the data. We don't need a depth format, but we do
need the right number of components and data type (FLOAT).
For Z32F, this means using R32_FLOAT.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, all that matters is that we copy the correct number of bits,
so any format that has 16-bits of data will work fine.
Once BLORP begins handling format conversions, the sampler will need to
correctly interpret the data. We don't need a depth format, but we do
need the right number of components and data type (UNORM).
For Z16, this means using R16_UNORM.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Once blorp gains the ability to do format conversions, it's conceivable
that the source format may be texturable but not supported as a render
target. This would break Paul's code, which assumes that it can use the
render_target_format array even for the source format.
There are three ways to convert MESA_FORMAT enums to BRW_SURFACEFORMAT
enums:
1. brw_format_for_mesa_format()
This translates the Mesa format to the most equivalent BRW format.
2. brw->render_target_format[]
This is used for renderbuffers, and handles the subset of formats
that are renderable. However, it's not always equivalent, since
it overrides a few non-renderable formats. For example, it
converts B8G8R8X8_UNORM to B8G8R8A8_UNORM so it can be rendered to.
3. translate_tex_format()
This is used for textures. It wraps brw_format_for_mesa_format(),
but overrides depth textures, and one sRGB case on Gen4.
BLORP has a fourth function, which uses brw->render_target_format[]
and overrides depth formats (differently than translate_tex_format).
This patch makes the BLORP function to use brw_format_for_mesa_format()
for textures/source data, since not everything will be a render target.
It continues using brw->render_target_format[] for render targets, since
it needs the format overrides that provides.
We don't use translate_tex_format() since the additional overrides are
not useful or simply redundant.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we're moving towards expanding the number of subpixel
bits and the width of the variables used in the computations
we need to make this code a bit more centralized.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The code introduces two new 32bit integer multiplication opcodes which
can be used to produce correct 64 bit results. GLSL, OpenCL and D3D10+
require them. We use two seperate opcodes, because they match the
behavior of GLSL and OpenCL, are a lot easier to add than a single
opcode with multiple destinations and because there's not much (any)
difference wrt code-generation.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The UD values were getting set up as floats. This happened to work out
because they were used as the second argument where the first was a dword,
and gen6+ doesn't do source conversions. But it did trigger fulsim
warnings, and it meant if you used the push constant as the first operand
you would have been disappointed.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The EGL library has some references to x11 but it gets the link flags
from the XCB_DRI2_LIBS if and only if HAVE_EGL_PLATFORM_X11 is true.
The X11_LIBS variable was probably coming from a PKG_CHECK_MODULES (x11)
earlier in history.
If it is possible to have HAVE_EGL_DRIVER_GLX without HAVE_EGL_PLATFORM_X11
then the link flags for libX11 should be passed. However, it won't come
from X11_LIBS which is undefined.
Reported-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
The Xlib.h file is not installed on my workstation. It is supplied in
the libx11-dev package. This allows an X developer control over which
version of this file is used for X development.
Use to test: --enable-gallium-egl --enable-xlib-glx --disable-dri
Acked-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
The Xlib.h file is not installed on my workstation. It is supplied in
the libx11-dev package. This allows an X developer control over which
version of this file is used for X development.
Acked-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
It is used for building the code in the x11 subdir.
The build does not fail on this one as LIBDRM_CFLAGS happens to have
the inludedir value as the one for X11. It will not always be the case.
The option --enable-gallium-egl is required durimg configuration.
Acked-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
OutputSurfaces have simple YCbCr rendering functionality built in,
but so far only 4:2:0 subsampling worked correctly. This fixes 4:2:2
and 4:4:4 formats.
Reviewed-by: Christian König <christian.koenig@amd.com>
It doesn't work (decodes to garbage) with most videos on UVD 3.0. Worse
yet, it often results in random memory corruption or GPU hangs. Rumor
has it only the newest UVD hardware could do it anyway.
Reviewed-by: Christian König <christian.koenig@amd.com>
The DPB size calculations seem to be off; there is various random
corruption happening, even with advanced profile. Always assuming
a minimum number of references appears to fix it, similarly to
H.264. This might overallocate the DPB. Also clean up the SPS/PPS
field setup so that it matches VC-1 specifications better.
With these changes, all advanced profile VC-1 files I could get my
hand on work fine.
Reviewed-by: Christian König <christian.koenig@amd.com>
UVD can only support NV12 in the case of hardware decoding, but we
can still use all other formats for software decoding. Use the UNKNOWN
profile to signal that we're not interesting in hardware decoding.
v2: use profile instead of entrypoint
Reviewed-by: Christian König <christian.koenig@amd.com>
which contains -Wl,-Bsymbolic. If I understand it correctly, it prevents
symbols from clashing if multiple drivers are loaded at the same time.
Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Copy sechalf to the new register, otherwise we would read wrong HW registers.
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
When the instruction to send the sampler message is forced uncompressed or
sechalf, send SIMD8 one even in SIMD16 mode.
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
SIMD8 sampler messages are allowed in SIMD16 mode, and they could not work
without BRW_COMPRESSION_2NDHALF. Later PRMs (gen5 and later) do not
explicitly state whether BRW_COMPRESSION_2NDHALF is allowed, but they do have
examples using send with SecHalf. It should be safe to assume SecHalf is
valid.
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
gl_PointSize is stored in the w component of VARYING_SLOT_PSIZ, but
the geometry shader infrastructure assumes that it should look for all
geometry shader inputs of type float in the x component. So when
compiling a geomtery shader that uses a gl_PointSize input, fix it up
during the shader prolog by moving the w component to the x component.
This is similar to how we emit fixups and workarounds for vertex
shader attributes.
Fixes piglit test spec/glsl-1.50/execution/geometry/core-inputs.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This corresponds to the lowering of gl_ClipDistance to
gl_ClipDistanceMESA for vertex and geometry shader outputs. Since
this lowering pass occurs after lower_named_interface blocks, it deals
with 2D arrays (gl_ClipDistance[vertex][clip_plane]) rather than 1D
arrays in an interface block
(gl_in[vertex].gl_ClipDistance[clip_plane]).
v2 (Paul Berry <stereotype441@gmail.com>): Fix indexing order for
gl_ClipDistance input lowering. Properly lower bulk assignment of
gl_ClipDistance inputs. Rework for GLSL 1.50 style geometry shaders.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
v3 (Paul Berry <stereotype441@gmail.com>): Add comments and assertions
to clarify that the 2D version of clip distance is only used for
geometry shader inputs.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, builtin_variables.cpp was written assuming that we
supported ARB_geometry_shader4 style geometry shader inputs, meaning
that each built-in varying input to a geometry was supplied via an
array variable whose name ended in "In", e.g. gl_PositionIn or
gl_PointSizeIn.
However, in GLSL 1.50 style geometry shaders, things work
differently--built-in inputs are supplied to geometry shaders via a
built-in interface block called gl_in, which contains all the built-in
inputs using their usual names (e.g. the gl_Position input is supplied
to the geometry shader as gl_in[i].gl_Position).
This patch adds the necessary logic to builtin_variables.cpp to create
the gl_in interface block and populate it accordingly for geometry
shader inputs. The old ARB_geometry_shader4 style varyings are
removed, though they can easily be added back in the future if we
decide to support ARB_geometry_shader4.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This patch adds a "location" element to struct glsl_struct_field, so
that we can keep track of the gl_varying_slot associated with each
built-in geometry shader input.
In lower_named_interface_blocks, we use this value to populate the
"location" field in the ir_variable that stores each geometry shader
input.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
For a few reasons.
1: In the (current) common case, these conditionals are never true. All
we're doing by checking them is slowing down MakeCurrent. The server
does these checks already anyway.
2: GLX >= 3.0 contexts may legally be made current without a bound
framebuffer.
This does not fix piglit/glx-create-context-current-no-framebuffer, but
is a prerequisite for fixing it.
Cc: "9.1 9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The new sampler bind sends us NULL samplers, so we need to count
the number of valid samplers ourselves. This fixes ~500 piglit
regressions from the sampler rework.
While we're at it, let's also support start.
In 3DSTATE_DEPTH_BUFFER, we set Width and Height to the miptree slice's
physical dimensions. (Logical and physical dimensions may differ for
multisample surfaces).
However, in SURFACE_STATE, we always set Width and Height to the slice's
logical dimensions. We should do the same for 3DSTATE_DEPTH_BUFFER,
because the hw docs say so.
No Piglit regressions (-x glx -x glean) on Ivybridge with Wayland.
v2: No Piglit regressions, for real this time.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Now, one can do the following to generate and read the i965 Doxygen:
cd $MESA_TOP/doxygen
make
firefox i965/index.html
Reviewed-by: Frank Henigman <fjhenigman@google.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The registers in the architecture register file don't share much in
common, so there's no point in grouping them together. Use the HW_REG
class instead. The vec4 backend already does this.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Accidentally pushed an old version of the patch.
v2: Set destination register using brw_null_reg().
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
CSE would otherwise combine the two mul(8) emitted by [iu]mulExtended:
mul(8) acc0 x y
mach(8) null x y
mov(8) lsb acc0
...
mul(8) acc0 x y
mach(8) msb x y
Into:
mul(8) temp x y
mov(8) acc0 temp
mach(8) null x y
mov(8) lsb acc0
...
mov(8) acc0 temp
mach(8) msb x y
But mul(8) into the accumulator produces more than 32-bits of precision,
which is required and lost if multiplying into a general register and
moving to the accumulator.
Reviewed-by: Eric Anholt <eric@anholt.net>
These built-ins have two "out" parameters, which makes implementing them
efficiently with our current compiler infrastructure difficult. Instead,
implement them in terms of the existing ir_binop_mul IR (to return the
low 32-bits) and a new ir_binop_mul64 which returns the high 32-bits.
v2: Rename mul64 -> imul_high as suggested by Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965 implements this with a single (multiple destination) instruction,
SUBB. Emitting SUBB directly from usubBorrow() would be ideal, but our
optimization passes don't know how to copy with expressions with
side-effects.
Radeon has an SUBB_UINT instruction that only generates the borrow
bit. I've chosen to go this route and implement usubBorrow() by doing the
subtraction and the borrow operations separately.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965 implements this with a single (multiple destination) instruction,
ADDC. Emitting ADDC directly from uaddCarry() would be ideal, but our
optimization passes don't know how to copy with expressions with
side-effects.
Radeon has an ADDC_UINT instruction that only generates the carry
bit. I've chosen to go this route and implement uaddCarry() by doing the
addition and the carry operations separately.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Calculates the carry out of the addition of two values and the
borrow from subtraction respectively. Will be used in uaddCarry() and
usubBorrow() built-in implementations.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The only GLSL extension that is not enabled is AMD_vertex_shader_layer.
I think the standalone-compiler could enable this (as shading language
support is complete), but no driver enables it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Infer whether or not to use ES based on the GLSL version (100 or 300 are
for ES). This replaces the --glsl-es command line option. Set various
compiler limits based on the minimums required for the specified GLSL
version.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
The choices aren't just 0 and 1, so using the enum names is much more
clear.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This allows application developers to use Mesa's compiler as a
standalone validator for their shaders.
This is mostly a revert of commit 569f0e4.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Pull the data directly from the context like the other varying related
limits. The parser state shadow copies were added back when the parser
state didn't have a pointer to the context. There's no reason to do it
now days.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
gl_MaxVertexOutputVectors => ctx->Const.VertexProgram.MaxOutputComponents
gl_MaxFragmentInputVectors => ctx->Const.FragmentProgram.MaxInputComponents
v2: Add types so that the code compiles. Pointed out by Brian.
v3: Leave gl_MaxVaryingFloats et al. as-is. Suggested by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com> [v2]
Reviewed-by: Marek Olšák <marek.olsak@amd.com> [v2]
Reviewed-by: Paul Berry <stereotype441@gmail.com> [v2]
Starting with OpenGL 3.2 input limits and output limits for stages may
not match. This means they need to be accounted separately.
No piglit regressions.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
No need to keep a copy of the message in system memory anymore,
since it should now be in GART memory on newer chips.
Signed-off-by: Christian König <christian.koenig@amd.com>
This fixes issues where get_rt_format would see a 0 format because the
nouveau_surface had not been properly initialized. Fixes crash on
supertuxkart startup (which still fails due to out-of-vram issues).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
As of ARB_gpu_shader5, textureGather doesn't always read the
post-swizzle RED channel -- so we can't just look at the red swizzle
state.
Theoretically we could only flag the quirk if *some* green swizzle is in
use, but that's probably more trouble than it's worth.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
- For HSW: Select the channel based on the component selected (swizzle
is done in HW)
- For IVB: Select the channel based on the swizzle state for the
component selected. Only apply the RG32F w/a if we actually want
green -- we're about to flag it regardless of swizzle state.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
- For HSW: Select the channel based on the component selected (swizzle
is done in HW)
- For IVB: Select the channel based on the swizzle state for the
component selected. Only apply the RG32F w/a if we actually want
green -- we're about to flag it regardless of swizzle state.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
- gsampler2DRect support
- optional `comp` parameter
Future patches will add shadow sampler support and
textureGatherOffsets().
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
ARB_gpu_shader5 introduces new variants of textureGather* which have an
explicit component selector, rather than relying purely on the sampler's
swizzle state.
This patch adds the GLSL plumbing for the extra parameter.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Theoretically would work on Gen5 as well but requires GLSL 1.30, which
is not (yet) enabled by default there.
V2: Enable for Gen5 conditionally on GLSL version.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Previously we special-cased textureSize() but this is the more correct
condition.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
* This in essence means that Mesa would be
taking control of Haiku's OpenGL kit.
* This works by dispatching renderers from the
OpenGL add-ons directory
This patch fixes this Oracle Solaris Studio build error.
"../../src/glsl/ir_constant_expression.cpp", line 1398: Error: The function "isnormal" must have a prototype.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
All texture instructions can use offsets, not just TXF. Offsets into
the literals array were wrong, too.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
We return 0 for GL_NUM_SHADER_BINARY_FORMATS, so
GL_SHADER_BINARY_FORMATS should not write any data to the application
buffer.
Fixes piglit test 'arb_get_program_binary-overrun shader'.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
As we march over the source buffer we're uploading in pieces, we
need to memcpy from the current offset, not the start of the buffer.
Fixes graphical corruption when drawing very large vertex buffers.
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matthew McClure <mcclurem@vmware.com>
This patch adds the lrint, lrintf, llrint, and llrintf rounding utility
functions. When packing unorm depth values, we will round to nearest.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
With commit cb1febb07, I have incorrectly removed HAVE_COMMON_DRI
assuming that swrast does not need to build the translations for
driconf options, as effectively swrast/drisw does not use them.
With the incoming unification work of dri and drisw, it makes
sense just to revert the offending hunk.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70057
Reported-by: Vinson Lee <vlee@freedesktop.org>
Tested-by: Vinson Lee <vlee@freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Previously, we computed dFdy() using the following instruction:
add(8) dst<1>F src<4,4,0)F -src.2<4,4,0>F { align1 1Q }
That had the disadvantage that it computed the same value for all 4
pixels of a 2x2 subspan, which meant that it was less accurate than
dFdx(). This patch changes it to the following instruction when
c->key.high_quality_derivatives is set:
add(8) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1Q }
This gives it comparable accuracy to dFdx().
Unfortunately, align16 instructions can't be compressed, so in SIMD16
shaders, instead of emitting this instruction:
add(16) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1H }
We need to unroll to two instructions:
add(8) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1Q }
add(8) (dst+1)<1>F (src+1)<4,4,1>.xyxyF -(src+1)<4,4,1>.zwzwF { align16 2Q }
Fixes piglit test spec/glsl-1.10/execution/fs-dfdy-accuracy.
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
The inferface/prototype in native_wayland_bufmgr.h uses boolean/int, as
well as the rest of the file. Convert to improve consistency and to
prevent gcc compiler warnings due to type miss-match.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Clean up inconsistency in enum decoration:
- Use the undecorated enums where possible.
- MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS_ARB remains decorated, since it
has no undecorated equivalent in GL4.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70054
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The new surface channel select bits allow us to avoid having to
recompile the shader for this workaround.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-and-tested-by: Kenneth Graunke <kenneth@whitecape.org>
This allows us to use a different surface format for gather4, which is
required for R32G32_FLOAT to work on Gen7.
V4: - Only emit alternate surface state for shaders which will actually
use it.
- Pass a simple 'for_gather' flag rather than a function pointer.
The callee can decide what w/a to apply.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Worst-case is that *every* texunit uses a format that needs overriding.
V4: Place the gather slots last, so shaders which don't use gather don't
get penalized by having a huge binding table.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
gather4 GREEN channel against a surface with format R32G32_FLOAT doesn't work
correctly on IVB. w/a from bspec:
- use R32G32_FLOAT_LD = 0x97 instead, for gather4 only.
- select BLUE channel to read GREEN
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
V4: Only flag quirks if there are any uses of gather in the shader,
to avoid spurious recompiles just because someone happened to use
RG32F.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Pretty much the same as the FS case. Channel select goes in the header,
V2: Less mangling.
V3: Avoid sampling at all, for degenerate swizzles.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Lowers ir_tg4 (from textureGather and textureGatherOffset builtins) to
SHADER_OPCODE_TG4.
The usual post-sampling swizzle workaround can't work for ir_tg4,
so avoid doing that:
* For R/G/B/A swizzles use the hardware channel select (lives in the
same dword in the header as the texel offset), and then don't do
anything afterward in the shader.
* For 0/1 swizzles blast the appropriate constant over all the output
channels instead of sampling.
V2: Avoid duplicating header enabling block
V3: Avoid sampling at all, for degenerate swizzles.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Adds the Gen7 message IDs, a new SHADER_OPCODE_TG4 pseudo-op, and
low-level support for emitting it via generate_tex().
V3: Updated for changes in master.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When used with a cube array in VS, failed assertion in ir_validate:
Assignment count of LHS write mask channels enabled not
matching RHS vector size (3 LHS, 4 RHS).
To fix this, swizzle the RHS correctly for the writemask.
This showed up in the ARB_texture_gather tests, which exercise cube
arrays in the VS.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Consider only the top-left and top-right pixels to approximate DDX in a 2x2
subspan, unless the application requests a more accurate approximation via
GL_FRAGMENT_SHADER_DERIVATIVE_HINT or this optimization is disabled from the
new driconf option disable_derivative_optimization.
This results in a less accurate approximation. However, it improves the
performance of Xonotic with Ultra settings by 24.3879% +/- 0.832202% (at 95.0%
confidence) on Haswell. No noticeable image quality difference observed.
The improvement comes from faster sample_d. It seems, on Haswell, some
optimizations are introduced to allow faster sample_d when all pixels in a
subspan have the same derivative. I considered SAMPLE_STATE too, which allows
one to control the quality of sample_d on Haswell. But it gave much worse
image quality without giving better performance comparing to this change.
No piglit quick.tests regression on Haswell (tested with v1).
v2: better guess for precompile program key
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
We have the destination framebuffer object passed in; there's no need to
go digging around in the context.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Using it encourages the (IMHO worrying) practice of leaving member
variables uninitialized in constructor definitions. This macro
shouldn't be necessary anymore after the last patch series fixing all
its users to initialize all member variables from the class
constructor. Remove it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All member variables of glsl_to_tgsi_instruction are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All member variables of ir_to_mesa_instruction are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All member variables of vec4_live_variables are already being
initialized from its constructor, it's not necessary to use rzalloc to
allocate its memory, and doing so makes it more likely that we will
start relying on the allocator to zero out all memory if the class is
ever extended with new member variables.
That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All member variables of fs_live_variables are already being
initialized from its constructor, it's not necessary to use rzalloc to
allocate its memory, and doing so makes it more likely that we will
start relying on the allocator to zero out all memory if the class is
ever extended with new member variables.
That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All member variables of fs_inst are already being initialized from its
constructor, it's not necessary to use rzalloc to allocate its memory,
and doing so makes it more likely that we will start relying on the
allocator to zero out all memory if the class is ever extended with
new member variables.
That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All member variables of ip_record are already being initialized from
its constructor, it's not necessary to use rzalloc to allocate its
memory, and doing so makes it more likely that we will start relying
on the allocator to zero out all memory if the class is ever extended
with new member variables.
That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The cfg_t object relies on the memory allocator zeroing out its
contents before it's initialized, which is quite an unusual practice
in the C++ world because it ties objects to some specific allocation
scheme, and gives unpredictable results when an object is created with
a different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind. Initialize all fields from the
constructor and stop using the zeroing allocator.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The bblock_t object relies on the memory allocator zeroing out its
contents before it's initialized, which is quite an unusual practice
in the C++ world because it ties objects to some specific allocation
scheme, and gives unpredictable results when an object is created with
a different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind. Initialize all fields from the
constructor and stop using the zeroing allocator.
v2: Use zero initialization for numeric types instead of default construction.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All member variables of ast_type_qualifier are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All member variables of ast_node are already being initialized from
its constructor, but some of its derived classes were leaving members
uninitialized -- Fix them.
Using rzalloc makes it more likely that we will start relying on the
allocator to zero out all memory if the class is ever extended with
new member variables. That's bad because it ties objects to some
specific allocation scheme, and gives unpredictable results when an
object is created with a different allocator -- Stack allocation,
array allocation, or aggregation inside a different object are some of
the useful possibilities that come to my mind.
v2: Use NULL initialization instead of default construction for pointers.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The vec4_instruction object relies on the memory allocator zeroing out
its contents before it's initialized, which is quite an unusual
practice in the C++ world because it ties objects to some specific
allocation scheme, and gives unpredictable results when an object is
created with a different allocator -- Stack allocation, array
allocation, or aggregation inside a different object are some of the
useful possibilities that come to my mind. Initialize all fields from
the constructor and stop using the zeroing allocator.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The _mesa_glsl_parse_state object relies on the memory allocator
zeroing out its contents before it's initialized, which is quite an
unusual practice in the C++ world because it ties objects to some
specific allocation scheme, and gives unpredictable results when an
object is created with a different allocator -- Stack allocation,
array allocation, or aggregation inside a different object are some of
the useful possibilities that come to my mind. Initialize all fields
from the constructor and stop using the zeroing allocator.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Several C++ source files include "main/uniforms.h" from an extern "C"
block, which is both unnecessary, because "uniforms.h" already checks
for a C++ compiler and sets the right linkage, and incorrect, because
the header file includes other C++ headers ("glsl_types.h" and
"ir_uniform.h") that are supposed to get C++ linkage.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
In commit 247f90c77e (i965/gs: Set
control data header size/format appropriately for EndPrimitive()), I
incorrectly numbered the DWORDs in the 3DSTATE_GS command starting
from 1 instead of starting from 0. This caused the control data
format to be programmed into the wrong DWORD, resulting in corruption
in some geometry shaders that used an output type of points.
This patch numbers the DWORDs starting from 0, as we do for all other
commands, which causes the control data format to be programmed into
the correct DWORD.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The spec doesn't say GL_INVALID_VALUE should be raised for bufSize <= 0.
In any case, memcpy(len < 0) will lead to a crash, so don't allow it.
CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Error checking bufSize isn't mentioned in the spec, but it is in the
man pages. However, I believe the man page is incorrect. Typically,
GL functions that take GLsizei parameters check that they're positive
or non-negative. Negative values don't make sense here.
A spec bug has been filed with Khronos/ARB.
v2: check for negative values, not <= 0.
This incorporates Vinson's change to check for a null src pointer as
detected by coverity.
Also, rename the function params to be src/dst, const-qualify src,
and use GL types to match the calling functions. And add some more
comments.
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>
libllvmradeon.la is available whenever NEED_RADEON_LLVM is set, using
R600_NEED_RADEON_GALLIUM is rather ambiguous and unnecessary. Drop it
in favour of NEED_RADEON_LLVM.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
The mesa/drivers/dri/Makefile.am already guards the individual
targets/subdirs with HAVE_*_DRI before including them. Thus making
the additional check within each Makefile.am unnecessary.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
libdricommon.la is available whenever a non swrast driver is built.
All the classic dri drivers make use of the prebuild library but all
of the gallium ones rebuild it explicitly.
While we're here gallium/{llvm,soft}pipe does not require HAVE_COMMON_DRI
thus do not set in during configure.
v2: [Emil] Add commit message and drop HAVE_COMMON_DRI from configure.ac
v3: [Emil] Rebase and resolve targets/r*/dri conflicts
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
shader has already been dereferenced earlier so cannot be null here.
Fixes "Dereference before null check" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
The block size for all formats is currently at least 1 byte. Add an
assertion for this.
This should silence several Coverity "Division or modulo by zero"
defects.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is an earlier null check for draw so draw could be null here as
well.
Fixes "Dereference after null check" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Fix build errors.
CC surface.lo
surface.c: In function 'vlVdpVideoSurfaceGetBitsYCbCr':
surface.c:247:10: error: implicit declaration of function 'util_copy_rect' [-Werror=implicit-function-declaration]
CC output.lo
output.c: In function 'vlVdpOutputSurfaceGetBitsNative':
output.c:216:4: error: implicit declaration of function 'util_copy_rect' [-Werror=implicit-function-declaration]
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Fix build error.
CC device.lo
device.c: In function 'vlVdpDefaultSamplerViewTemplate':
device.c:251:4: error: implicit declaration of function 'util_format_description' [-Werror=implicit-function-declaration]
device.c:251:9: warning: assignment makes pointer from integer without a cast [enabled by default]
device.c:252:12: error: dereferencing pointer to incomplete type
device.c:252:28: error: 'UTIL_FORMAT_SWIZZLE_0' undeclared (first use in this function)
device.c:252:28: note: each undeclared identifier is reported only once for each function it appears in
device.c:254:12: error: dereferencing pointer to incomplete type
device.c:256:12: error: dereferencing pointer to incomplete type
device.c:258:12: error: dereferencing pointer to incomplete type
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
This patch fixes the build error introduced with commit
81bb98e928.
CC subpicture.lo
subpicture.c: In function 'upload_sampler':
subpicture.c:181:4: error: implicit declaration of function 'util_copy_rect' [-Werror=implicit-function-declaration]
subpicture.c: In function 'XvMCClearSubpicture':
subpicture.c:304:21: error: storage size of 'uc' isn't known
subpicture.c:328:4: error: implicit declaration of function 'util_fill_rect' [-Werror=implicit-function-declaration]
subpicture.c:304:21: warning: unused variable 'uc' [-Wunused-variable]
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
The svga/d3d9 convention is that pixel centers are at integer coordinates.
Fixes piglit glsl-arb-fragment-coord-conventions test.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Using the map/unmap path for glTexImage is a little bit faster
than blitting. Also, this fixes about 50 assorted piglit failures
that seem to be related to the blit version of glReadPixels.
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
u_rect.h was including u_surface.h just to avoid touching a bunch
of other source files after some functions were moved from u_rect.h
to u_surface.h. This patch cleans up that hack.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The format of the window system framebuffer changed from ARGB8888 to
SARGB8, but we're still supposed to render to it the same as ARGB8888
unless the user flipped the GL_FRAMEBUFFER_SRGB switch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for stable branches.
I believe this extension was enabled by accident. As far as I can tell,
there has never been any code in Mesa to actually support it. Not only
that, this extension is only useful in the common-lite profile, and Mesa
does the common profile.
This "fixes" the piglit test oes_matrix_get-api.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "9.1 9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For some reason that I don't yet fully understand, Glaze does not work with
libEGL unless libEGL is linked with -Bsymbolic.[*]
Beyond that specific reason, all of the reasons for which libGL.so is linked
with -Bsymbolic, (see the commit history), should also apply here.
[*] The specific behavior I am seeing is that when Glaze calls dlopen for
libEGL.so, ifunc resolvers within Glaze for EGL functions are called before
the dlopen returns. These resolvers cannot succeed, as they need the return
value from dlopen in order to find the functions to resolve to. I don't know
what's causing these resolvers to be called, but I have verified that linking
libEGL with -Bsymbolic causes this problematic behavior to stop.
CC: "9.1 and 9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
From the bspec documentation of the SEND instruction:
"destination region cannot cross the 256-bit register boundary."
To avoid violating this restriction when executing SIMD16 texturing
operations (such as those used by blorp), we need to ensure that the
destination of the SEND instruction doesn't exceed 256 bits in size.
An easy way to do this is to set the type of the destination register
to UW (unsigned word), since 16 unsigned words can fit inside a
256-bit register. Fortunately, this has no effect on the sampling
operation, since the sampler always infers the destination data type
from the sampler message rather than from the type of the instruction
operand.
Previously, we did this for texturing operations issued by the vec4
and fs back-ends, but not for blorp. This patch makes blorp use the
same trick.
I haven't observed any behavioural difference on actual hardware due
to this patch, but it avoids a warning from the simulator so it seems
like the right thing to do.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
We originally had a path just did the loop and called
ctx->Driver.AllocTextureImageBuffer(), which I moved into Mesa core. But
we can do better, avoiding incorrect miptree size guesses and later
texture validations by just directly allocating the miptree and setting it
to all the images.
v2: drop debug printf.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
As long as the baselevel, maxlevel still sit inside the range we had
previously validated, there's no need to reallocate the texture.
I also hope this makes our texture validation logic much more obvious.
It's taken me enough tries to write this change, that's for sure. Reduces
miptree copy count on a piglit run by 1.3%, though the change in amount of
data moved is much smaller.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Given that a teximage that calls us with this flag set will immediately
proceed to allocate the other levels, we can probably just go ahead and
allocate those levels now.
Reduces miptree copies in piglit by about .05%.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
If the caller shows up with GL_BASE_LEVEL != 0, it doesn't mean that the
texture will over the course of its lifetime have that nonzero baselevel,
it means that the caller is filling the texture from the bottom up for
some reason (one could imagine demand-loading detailed texture layers at
runtime, for example). If we allocate from just the current baselevel, it
means when they come along with the next level up, we'll have to allocate
a new miptree and copy all of our bits out of the first miptree.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Let's say you started allocating your 2D texture with level 2 of a tree as
a 1x1 image. The driver doesn't know if this means that level 0 is 4x4 or
4x1 or 1x4, so we would just allocate a single 1x1 and let it get copied
in to the real location at texture validate time later.
Since this is just a temporary allocation that *will* get copied, the
extra space allocation of just taking the normal path which will happen to
producing a 4x1 level 0, 2x1 level 1, and 1x1 level 2 is the right way to
go, to reduce complexity in the normal case.
No change in miptree copies over the course of a piglit run.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This has no effect currently, because intel_finalize_mipmap_tree() always
makes mt->first_level == tObj->BaseLevel.
The change I made before to handle it
(b1080cfbdb) got very close to working, but
after fixing some unrelated bugs in the series, it still left
tex-miplevel-selection producing errors when testing textureLod(). The
problem is that for explicit LODs, the sampler's LOD clamping is ignored,
and only the surface's MIP clamping is respected. So we need to use
surface mip clamping, which applies on top of the sampler's mip clamping,
so the sampler change gets backed out.
Now actually tested with a non-regressing series producing a non-zero
computed baselevel.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
We know that the object's mt is equal to the firstimage's mt because it's
gone through intel_finalize_mipmap_tree(). Saves a lookup of firstimage
on pre-gen7.
v2: Merge in the warning fix that appeared later in the series (noted by
Chad)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The function r600_choose_tiling is new and needs a review.
The only change in functionality is that it enables 2D tiling for compressed
textures on SI. It was probably accidentally turned off.
v2: don't make scanout buffers linear
More work needs to be done for this to be entirely shared with r600g.
I'm just trying to share r600_texture.c now.
The reason I put the implementation to si_descriptors.c is that the emit
function had already been there.
This doesn't fix any known issue (I haven't run piglit with this yet),
but the code was obviously completely wrong. It looks like copy-pasted from CMP.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
If the argument to emit_bool_to_cond_code() is an ir_expression, we
loop over the operands, calling accept() on each of them, which
generates assembly code to compute that subexpression. We then emit
one or two final instruction that perform the top-level operation on
those operands.
If it's not an expression (say, a boolean-valued variable), we simply
call accept() on the whole value.
In commit 80ecb8f1 (i965/fs: Avoid generating extra AND instructions on
bool logic ops), Eric made logic operations jump out of the expression
path to the non-expression path.
Unfortunately, this meant that we would first accept() the two operands,
skip generating any code that used them, then accept() the whole
expression, generating code for the operands a second time.
Dead code elimination would always remove the first set of redundant
operand assembly, since nothing actually used them. But we shouldn't
generate it in the first place.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Ironlake's counters are always enabled; userspace can simply send a
MI_REPORT_PERF_COUNT packet to take a snapshot of them. This makes it
easy to implement.
The counters are documented in the source code for the intel-gpu-tools
intel_perf_counters utility.
v2: Adjust for core data structure changes. Add a table mapping buffer
object offsets to exposed counters (which changes each generation).
Finally, add report ID assertions to sanity check the BO layout
(thanks to Carl Worth).
v3: Update for core BeginPerfMonitor hook changes (requested by Brian).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This provides an interface for applications (and OpenGL-based tools) to
access GPU performance counters. Since the exact performance counters
available vary between vendors and hardware generations, the extension
provides an API the application can use to get the names, types, and
minimum/maximum values of all available counters. Counters are also
organized into groups.
Applications create "performance monitor" objects, select the counters
they want to track, and Begin/End monitoring, much like OpenGL's query
API. Multiple monitors can be in flight simultaneously.
v2: Pass ctx to all driver hooks (suggested by Christoph), and attempt
to fix overallocation of bitsets (caught by Christoph). Incomplete.
v3: Significantly rework core data structures. Store counters in groups
rather than in a global list. Use their array index in the group's
counter list as the ID rather than trying to store a globally unique
counter ID. Use bitsets for active counters within a group, and
also track which groups are active so that's easy to query.
v4: Remove _mesa_ prefix on static functions; detect out of memory
conditions in new_performance_monitor(); make BeginPerfMonitor hook
return a boolean rather than setting m->Active or raising an error.
Switch to GLuint/unsigned for NumGroups, NumCounters, and
MaxActiveCounters (which also means switching a bunch of temporary
variable types). All suggested by Brian Paul. Also, remove
commented out code at the bottom of the block. Finally, fix the
dispatch sanity test (noticed by Ian Romanick).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com> [v3]
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is better than overriding the extension enable based on the
language version; it's robust against shaders that do:
#version 140
#extension GL_ARB_uniform_buffer_object : disable
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Explicit attribute locations are supported with GLSL 3.30, GLSL ES 3.00,
or "#extension GL_ARB_explicit_attrib_location: enable". Using a helper
function makes it easy to check for this.
This enables support in GLSL 3.30, which was previously missing.
Previously, we overrode the extension enable flag for ES 3.00. This is
not robust against a shader such as:
#version 330
#extension GL_ARB_explicit_attrib_location : disable
Disabling extensions should not remove core language functionality.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Hardware requires the magnitude of the largest component to not exceed
1; brw_cubemap_normalize ensures that this is the case.
Unfortunately, we would previously multiply the array index for cube
arrays by the normalization factor. The incorrect array index would then
cause the sampler to attempt to access either the wrong cube, or memory
outside the cube surface entirely, resulting in garbage rendering or in
the worst case, hangs.
Alter the normalization pass to only multiply the .xyz components.
Fixes broken rendering in the arb_texture_cube_map_array-cubemap piglit,
which was recently adjusted to provoke this behavior.
V2: Fix indent.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "9.2" mesa-stable@lists.freedesktop.org
Reviewed-by: Eric Anholt <eric@anholt.net>
Compress empty triangles (don't emit more than one in a row) and
never emit empty triangles if we already generated a triangle
covering a non-null area. We can't skip all null-triangles
because c_primitives expects ones that were generated from vertices
exactly at the clipping-plane, to be emitted.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We need to count the clipper primitives before the rasterizer
discards one it considers to be null.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We need to subdivide triangles if either of the dimensions is
larger than the max edge length, not when both of them are larger.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The fix is at the end (TGSI_TEXTURE_SHADOWCUBE handling), but I also
restructured the code for it to be more readable.
Fixes spec/!OpenGL 3.0/sampler-cube-shadow.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This fixes some piglits, e.g:
spec/!OpenGL 3.0/required-renderbuffer-attachment-formats.
This can be ported to r600g.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Only create one screen for each winsys instance.
This helps with buffer sharing and interop handling.
v2: rebased and some minor cleanup
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This reverts commit 755c11dc5e.
We agreed that this is band-aid that's not very useful and
the proper solution is to rewrite the rasterization algo
so that it operates on 64 bit values.
Signed-off-by: Zack Rusin <zackr@vmware.com>
No such argument exists since this commit:
commit 92f3fca0ea
Author: Ian Romanick <ian.d.romanick@intel.com>
AuthorDate: Sun Aug 21 17:23:58 2011 -0700
Commit: Ian Romanick <ian.d.romanick@intel.com>
CommitDate: Tue Aug 23 14:52:09 2011 -0700
mesa: Remove target parameter from dd_function_table::BufferSubData
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When subdiving a triangle we're using a temporary array to store
the new coordinates for the subdivided triangles. Unfortunately
the array used for that was not aligned properly causing
random crashes in the llvm jit code which was trying to load
vectors from it.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This patch fixes the MSVC build error introduced by commit
673129e0b9.
enums.c
mesa\main\enums.c(3776) : error C2143: syntax error : missing ';' before 'type'
mesa\main\enums.c(3781) : error C2065: 'elt' : undeclared identifier
mesa\main\enums.c(3781) : warning C4047: '!=' : 'int' differs in levels of indirection from 'void *'
mesa\main\enums.c(3782) : error C2065: 'elt' : undeclared identifier
mesa\main\enums.c(3782) : error C2223: left of '->offset' must point to struct/union
mesa\main\enums.c(3782) : warning C4033: '_mesa_lookup_enum_by_nr' must return a value
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Normally, LD_PRELOAD will take precedence over your own symbols, which you
want for things like malloc() in libc. But we don't have any local
symbols we would want overridden (like hash_table_insert(), for example!),
so tell the linker to resolve them internally. This also avoids calls
through the PLT.
Saves almost 100k on libdricore's size, and gets us a bunch of the
performance back that we had with non-dricore.
Reviewed-by: Ian Romanick <ian.d.romanick@.intel.com>
This gives the compiler the chance to inline and not export class symbols
even in the absence of LTO. Saves about 60kb on disk.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@.intel.com>
Noticed while grepping through the code for something else.
v2: Don't convert really-runtime asserts to static asserts.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@.intel.com>
Since it's only used for debug information, we can misalign the struct and
save the disk space. Another 19k on a 64-bit build.
v2: Make a compiler.h macro to only use the attribute if we know we can.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@.intel.com>
Now that there's no name -> enum direction, we can drop the extra strings,
and merge the offsets table and the reduced_enums table.
Between the previous commit and this one, Mesa core drops by 30k.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@.intel.com>
It's been unused for a long time. I stopped digging through git history
as of 2009.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@.intel.com>
Unfortunately d3d10 requires a lot higher precision (e.g.
wgf11clipping tests for it). The smallest number of precision
bits with which it passes is 8. That means that we need to
decrease the maximum length of an edge that we can handle without
subdivision by 4 bits. Abstracted the code a bit to make it easier
to change once to switch to 64bit rasterization.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This patch fixes these MSVC build errors.
ir_constant_expression.cpp
src\glsl\ir_constant_expression.cpp(564) : warning C4244: '=' : conversion from 'int' to 'float', possible loss of data
src\glsl\ir_constant_expression.cpp(1384) : error C3861: 'isnormal': identifier not found
src\glsl\ir_constant_expression.cpp(1385) : error C3861: 'copysign': identifier not found
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69541
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Matt Turner <mattst88@gmail.com>
Share the winsys between different fd's if they point to the same device.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Waiting for an empty queue is nonsense and can lead to deadlocks if we have
multiple waiters or another thread that continuously sends down new commands.
Just post the cs to the queue and immediately wait for it to finish.
This is a candidate for the stable branch.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Kill the thread only after we checked that it's not used any more, not before.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The rescale_texcoord(), if it does something, will return just the
GLSL-sized coordinate, leaving out the 3rd and 4th components where we
were storing our projected shadow compare and the texture projector.
Deref the shadow compare before using the shared rescale-the-coordinate
code to fix the problem.
Fixes piglit tex-shadow2drect.shader_test and txp-shadow2drect.shader_test
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69525
NOTE: This is a candidate for stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Probably non-intentional, but the SURFACE_STATE setup refactoring
for buffer surfaces had missed the scs bits when creating constant
surface states.
Fixes broken GLB 2.5 on Haswell where the knight's textures are missing
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These classes declared a placement new operator, but didn't declare a
delete operator. Switching to the macro gives them a delete operator,
which probably is a good idea anyway.
This also eliminates a lot of boilerplate.
v2: Properly use RZALLOC in Mesa IR/TGSI translators. Caught by Eric
and Chad.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Most of our C++ classes define placement new and delete operators so we
can do convenient allocation via:
thing *foo = new(mem_ctx) thing(...)
Currently, this is done via a lot of boilerplate. By adding simple
macros to ralloc, we can condense this to a single line, making it
trivial to add this feature to a new class.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Allocate a CMASK on demand and use it to fast clear single-sample
colorbuffers. Both FBOs and window system colorbuffers are fast
cleared. Expand as needed when colorbuffers are mapped or displayed
on screen.
v2: cosmetics, move transfer expansion into dma_blit
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
r600g needs explicit flushing before DRI2 buffers are presented on the screen.
v2: add (stub) implementations for all drivers, fix frontbuffer flushing
v3: fix galahad
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
We must take rounding in consideration when re-scaling to narrow
normalized channels, such as 2-bit normalized alpha.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS, GL_MAX_GEOMETRY_OUTPUT_VERTICES,
GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS, and
GL_MAX_GEOMETRY_UNIFORM_COMPONENTS all have the same enum value and
meaning as their _ARB counterparts.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The comment '# GL 3.0 / GLES3' was incorrect. The
MAX_VERTEX_OUTPUT_COMPONENTS and MAX_FRAGMENT_INPUT_COMPONENTS queries
were added in OpenGL 3.2 (with geometry shaders) and OpenGL ES 3.0.
This just fixes that comment.
v2: Add the GEOMETRY queries in the existing '# GL 3.2' section since
they have nothing to do with GLES3. Suggested by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
In OpenGL ES 3.0 the minimum-maximum for GL_MAX_VERTEX_OUTPUT_VECTORS is 16,
but the minimum-maximum for GL_MAX_FRAGMENT_INTPUT_VECTORS is 15.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
In OpenGL ES 3.0 the minimum-maximum for GL_MAX_VERTEX_OUTPUT_VECTORS is 16,
but the minimum-maximum for GL_MAX_FRAGMENT_INTPUT_VECTORS is 15.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Now that MaxVaryings is > 16, VertexProgram.MaxOutputComponents,
GeometryProgram.MaxInputComponents, GeometryProgram.MaxOutputComponents,
and FragmentProgram.MaxInputComponents also need to be set.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Paul Berry <stereotype441@gmail.com>
Previously gl_constants::MaxVaryingComponents was used. Now
gl_constants::VertexProgram::MaxOutputs and
gl_constants::GeometryProgram::MaxOutputs are used.
This means that st_extensions.c had to be updated to set these fields
instead of MaxVaryingComponents. It was previously the only place that
set MaxVaryingComponents.
I believe that the structure is allocated by calloc, so the value should
be initialized to zero in non-Gallium drivers before and after my
change. Right now nobody enables GL_ARB_geometry_shader4, so it's
pretty much dead code anyway.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: Zack Rusin <zackr@vmware.com>
In OpenGL 3.2 these are independently queryable. In addition, the spec
has different minimum-maximums for various values.
GL_MAX_VERTEX_OUTPUT_COMPONENTS is 64, but
GL_MAX_GEOMETRY_OUTPUT_COMPONENTS (and GL_MAX_FRAGMENT_INPUT_COMPONENTS)
is 128.
In OpenGL ES 3.0 these are also independently queryable. The spec has
different minimum-maximums for various values.
GL_MAX_VERTEX_OUTPUT_VECTORS is 16, but GL_MAX_FRAGMENT_INTPUT_VECTORS
is 15.
None of these values are used yet. I have just added space to the
structures. Future patches will add users and eventually remove some
old fields.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: Zack Rusin <zackr@vmware.com>
This was an embarassingly large amount of copy and pasted code,
and it wasn't particularly simple code either. By factoring it out
into a helper function, we consolidate the complexity.
v2: Properly NULL-check bo. Caught by Eric Anholt.
v3: Do the subtraction by 1 in gen7_emit_buffer_surface_state, rather
than making callers do it. This makes the buffer_size parameter
the actual size of the buffer. Suggested by Paul Berry.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was an embarassingly large amount of copy and pasted code,
and it wasn't particularly simple code either. By factoring it out
into a helper function, we consolidate the complexity.
v2: Properly NULL-check bo. Caught by Eric Anholt.
v3: Do the subtraction by 1 in gen7_emit_buffer_surface_state, rather
than making callers do it. This makes the buffer_size parameter
the actual size of the buffer. Suggested by Paul Berry.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The value that's split into width/height/depth needs to be the size of
the buffer minus one. This makes it consistent with the constant buffer
and shader time SURFACE_STATE setup code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This fixes myriads of regressions since commit 169f9c030c
("i965: Add an assertion that writemask != NULL for non-ARFs.").
On Sandybridge, our control flow handling (such as brw_IF) does:
brw_set_dest(p, insn, brw_imm_w(0));
insn->bits1.branch_gen6.jump_count = 0;
This results in a IMM destination with zero for the writemask. IMM
destinations are rather bizarre, but the code has been working for ages,
so I'm loathe to change it.
Fixes glxgears on Sandybridge.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
I would use _mesa_delete_shader, but it's declared static, and we don't
really need any of the stuff in it anyway.
This fixes a memory leak caught by Valgrind.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
&a and &b are the address of the local stack variables, not the actual
structures. Instead of comparing the fields of a and b, we compared
...some stack memory.
Not a candidate for stable since GS code doesn't exist in 9.2.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The code to upload the binding tables for each stage was scattered
across brw_{vs,gs,wm}_surface_state.c and brw_misc_state.c, which also
contain a lot of code to populate individual SURFACE_STATE structures.
This patch brings all the binding table upload code together, and splits
it out from the code which fills in SURFACE_STATE entries.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is not quite the same: brw_upload_binding_table() also has code to
early-return if there are no entries, while the existing code did not.
The PS binding table is unlikely to be empty since it will have at least
one color buffer. If it ever is empty, early returning seems wise.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Instead of passing in a brw_vec4_prog_data structure, we can simply
pass the one field it needs: the number of entries in the binding table.
We also need to pass in the shader time surface index rather than
hardcoding SURF_INDEX_VEC4_SHADER_TIME.
Since the resulting function is stage-agnostic, this patch removes
"vec4_" from the name.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is probably more efficient. At any rate, it's less code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The first comment was a bit stale; there are more kinds of surfaces than
textures and pull constants.
The second was a leftover "to do" comment for something I already did.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
xlib_sw_winsys.h:5:22: fatal error: X11/Xlib.h: No such file or directory
The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
The Xlib.h file is not installed on my workstation. It is supplied in
the libx11-dev package. This allows an X developer control over which
version of this file is used for X development.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
egl_glx.c:40:22: fatal error: X11/Xlib.h: No such file or directory
The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
The Xlib.h file is not installed on my workstation. It is supplied in
the libx11-dev package. This allows an X developer control over which
version of this file is used for X development.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Technically without seamless filtering enabled GL allows any wrap mode, which
made sense when supporting true borders (can get seamless effect with border
and CLAMP_TO_BORDER), but gallium doesn't support borders and d3d9 requires
wrap modes to be ignored and it's a pain to fix up the sampler state (as it
makes it texture dependent). It is difficult to imagine a situation where an
app really wants another behavior so just cheat here. (It looks like some
graphics hw (intel) actually requires this too hence it should be safe.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This removes a lot of code, but not everything, as util_blit_pixels_tex
is still useful when one needs to override pipe_sampler_view::swizzle_?.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
By calling util_map_texcoords2d_onto_cubemap.
A new parameter for util_blit_pixels_tex is necessary, as
pipe_sampler_view::first_layer is always supposed to point to the first
face when sampling from cubemaps.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The previous names were really confusing to talk about:
- brw_fs_visitor() contained methods named emit_whatever().
- brw_fs_generator() contained methods named generate_whatever(), but
lived in brw_fs_emit.cpp.
So when someone said "the emit layer", or "emit code", we weren't sure
whether they meant the visitor's emit() functions or the generator in
brw_fs_emit.cpp.
By renaming these files, the method names, class names, and file names
all match, which is much less confusing.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Eric Anholt <eric@anholt.net>
I initially implemented frexp() as an IR opcode with a lowering pass,
but since it returns a value and has an out-parameter, it would break
assumptions our optimization passes make about ir_expressions being pure
(i.e., having no side effects).
For example, if opt_tree_grafting encounters this code:
uniform float u;
void main()
{
int exp;
float f = frexp(u, out exp);
float g = float(exp)/256.0;
float h = float(exp) + 1.0;
gl_FragColor = vec4(f, g, h, g + h);
}
it may try to optimize it to this:
uniform float u;
void main()
{
int exp;
float g = float(exp)/256.0;
float h = float(exp) + 1.0;
gl_FragColor = vec4(frexp(u, out exp), g, h, g + h);
}
Some hardware has an instruction which performs frexp(), but we would
need some other compiler infrastructure to be able to generate it, such
as an intrinsics system that would allow backends to emit specific code
for particular bits of IR.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Note the parameter name change in the int version of ir_constant, to
avoid the conflict with the loop iterator.
v2: Make analogous change to builtin_builder::imm().
Reviewed-by: Paul Berry <stereotype441@gmail.com>
These data structures are used for debug output, so it wasn't hurting
anything that there were missing bits. But it's good to keep things
up to date.
This patch also adds static asserts so that the {brw,cache}_bits[]
arrays are the proper size, so that we don't forget to add to them in
the future. Unfortunately there's no convenient way to assert that
mesa_bits[] is the proper size.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If the geometry shader refers to the built-in variable
gl_PrimitiveIDIn, we need to set a bit in 3DSTATE_GS to tell the
hardware to dispatch primitive ID to r1, and we need to leave room for
it when allocating registers.
Note: this feature doesn't yet work properly when software primitive
restart is in use (the primitive ID counter will incorrectly reset
with each primitive restart, since software primitive restart works by
performing multiple draw calls). I plan to address that in a future
patch series.
Fixes piglit test "spec/glsl-1.50/execution/geometry/primitive-id-in".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When we previously implemented primitive restart, we didn't add cases
to brw_primitive_restart.c's can_cut_index_handle_prims() for the
primitive types that are introduced with geometry shaders. It turns
out that all of the new primitive types are supported by hardware
primitive restart.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
As part of its support for geometry shaders, GL 3.2 introduces four
new primitive types: GL_LINES_ADJACENCY, GL_LINE_STRIP_ADJACENCY,
GL_TRIANGLES_ADJACENCY, and GL_TRIANGLE_STRIP_ADJACENCY.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Simply adjust wrap mode to clamp_to_edge. This is all that's needed for a
correct implementation for nearest filtering, and it's way better than
using repeat wrap for instance for linear filtering (though obviously this
doesn't actually do seamless filtering).
v2: fix s/t wrap not r/s...
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Specifying a miptree layout makes no sense for constant buffers.
This has no functional change since BRW_SURFACE_MIPMAPLAYOUT_BELOW is
just a #define for 0.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This paves the way for using gen7_upload_constant_state for PS data.
The formula is copied from gen7_wm_state.c.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
GL 3.2 requires us to support 128 varying components for geometry
shader outputs and fragment shader inputs, and 64 varying components
otherwise. But there's no hardware limitation that restricts us to 64
varying components, and core Mesa doesn't currently allow different
stages to have different maximum values, so just go ahead and enable
128 varying components for all stages. This gets us better test
coverage anyway.
Even though we are only working on GL 3.2 support for gen7 right now,
gen6 also supports 128 varying components, so go ahead and switch it
on there too.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously we only ever did 1 URB write, since the maximum number of
varyings we support is small enough to fit in 1 URB write (when using
BRW_URB_SWIZZLE_NONE, which is what the pre-Gen7 GS always uses). But
we're about to increase the number of varying components we support
from 64 to 128.
With 128 varyings, the most URB writes we'll have to do is 2, but it's
just as easy to write a general-purpose loop.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The "{VS,GS} URB Entry Allocation Size" fields of 3DSTATE_URB allow
values in the range 0-4, but they are U8-1 fields, so the range of
possible allocation sizes is 1-5. We were erroneously prohibiting a
size of 5.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously we only ever did 1 or 2 URB writes, since the maximum
number of varyings we support is small enough to fit in 2 URB writes.
But GL 3.2 requires the geometry shader to support 128 output varying
components, and this could require up to 3 URB writes.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since the SF/SBE stage is only capable of performing arbitrary
reorderings of 16 varying slots, we can't arrange the fragment shader
inputs in an arbitrary order if there are more than 16 input varying
slots in use. We need to make sure that slots 16-31 match the
corresponding outputs of the previous pipeline stage.
The easiest way to accomplish this is to just make all varying slots
match up with the previous pipeline stage.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The for loop was rather silly. In addition to checking brw->gen < 6
on each loop iteration, it took pains to exclude bits from
fp->Base.InputsRead that don't correspond to fragment shader inputs.
But those bits would never have been set in the first place, since the
only bits that are ever set in fp->Base.InputsRead are fragment shader
inputs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Now that the vertex shader output VUE map is determined solely by a
64-bit bitfield, we don't have to store it in its entirety in the
geometry shader program key; instead, we can just store the bitfield,
and let the geometry shader infer the VUE map at compile time.
This dramatically reduces the size of the geometry shader program key,
which we want to keep small since it gets recomputed whenever the
active program changes.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, on Gen6+, we laid out the vertex (or geometry) shader VUE
map differently depending whether user clipping was active. If it was
active, we put the clip distances in slots 2 and 3 (where the clipper
expects them); if it was inactive, we assigned them in the order of
the gl_varying_slot enum.
This made for unnecessary recompiles, since turning clipping on/off
for a shader that used gl_ClipDistance might rearrange the varyings.
It also required extra bookkeeping, since it required the user
clipping flag to be provided to brw_compute_vue_map() as a parameter.
With this patch, we always put clip distances at in slots 2 and 3 if
they are written to. do_vs_prog() and do_gs_prog() are responsible
for ensuring that clip distances are written to when user clipping is
enabled (as do_vs_prog() previously did for gen4-5).
This makes the only input to brw_compute_vue_map() a bitfield of which
varyings the shader writes to, a fact that we'll take advantage of in
forthcoming patches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, if a fragment shader accessed gl_FragCoord or
gl_FrontFacing, we would assign them their own slots in the fragment
shader input attribute array, using up space that could be made
available to real varyings. This was not strictly necessary (since
these values are not true varyings, and are instead computed from
other data available in the FS payload). But we had to do it anyway
because the SF/SBE setup code assumed that every 1 bit in the
gl_program::InputsRead bitfield corresponded to a genuine varying
variable.
Now that the SF/SBE code consults brw_wm_prog_data and only sets up
the attributes that the fragment shader actually needs, we don't have
to do this anymore.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, the SF/SBE setup code delivered varying inputs to the FS
in the order in which they appear in the gl_program::InputsRead
bitfield, since that's what the FS expects.
When we add support for more than 64 varying components, this will no
longer always be the case, because the Gen6+ SF/SBE stage is only
capable of performing arbitrary reorderings of 16 varying slots. So,
when there are more than 16 vec4's worth of varying inputs, the FS
will have to adjust the order its input varyings in order to partially
match the order of outputs from the geometry or vertex shader.
To allow extra flexibility in the ordering of FS varyings, this patch
causes the SF/SBE to deliver varying inputs to the FS in exactly the
order that the FS requests, by consulting brw_wm_prog_data::urb_setup
and brw_wm_prog_data::num_varying_inputs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We always program the SF unit to start reading the vertex URB entry at
offset 1. In upcoming patches, we'll be adding FS code that relies on
this. So consistently use the constant BRW_SF_URB_ENTRY_READ_OFFSET
rather than hardcoding a 1.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we assumed that the number of varying inputs consumed by
the fragment shader was equal to the number of bits set in
gl_program::InputsRead. However, we'll soon be making two changes
that will cause that not to be true:
- We'll stop wasting varying input space for gl_FragCoord and
gl_FrontFacing, which aren't varyings.
- For fragment shaders that have more than 16 varying inputs, we'll
adjust the layout of the inputs to account for the fact that the
SF/SBE pipeline stage can't reorder inputs beyond the first 16; if
there are GS outputs that the FS doens't use (or vice versa) this
may cause the number of FS varying inputs to change.
So, instead of trying to guess the number of FS inputs from
gl_program::InputsRead, simply read it from
brw_wm_prog_data:num_varying_inputs, which is guaranteed to be correct
since it's populated by fs_visitor::calculate_urb_setup().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
On gen4-5, the FS stage reads varying inputs from URB entries that
were output by the SF thread, where each register stores the
interpolation setup for two components of a vec4, therefore the FS
urb_read_length is twice the number of FS input varyings. On gen6+,
varying inputs are directly deposited in the FS payload by the SF/SBE
fixed function logic, so urb_read_length is irrelevant.
However, in future patches, it will be nice to be able to consult
brw_wm_prog_data to determine how many varying inputs the FS expects
(rather than inferring it from gl_program::InputsRead). So instead of
storing urb_read_length, we simply store num_varying_inputs in
brw_wm_prog_data. On gen4-5, we multiply this by 2 to recover the URB
read length.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
At the moment, for Gen6+, the FS assumes that all varying inputs are
delivered to it in the order in which they appear in the
gl_program::InputsRead bitfield, and the SF/SBE setup code ensures
that they are delivered in this order.
When we add support for more than 64 varying components, this will no
longer always be possible, because the Gen6+ SF/SBE stage is only
capable of performing arbitrary reorderings of 16 varying slots.
To allow extra flexibility in the ordering of FS varyings, this patch
causes the FS to advertise exactly what ordering it expects.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For each sampler type, this tests that:
- The base type is GLSL_TYPE_SAMPLER.
- The dimensionality is set correctly.
- The returned data type is correct.
- The sampler_array and sampler_shadow flags are set correctly.
- sampler_coordinate_components() returns the correct value.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
It seems a user app can get us into this state, I trigger the fail
running fbo-maxsize inside virgl, it fails to create the backing
storage for the texture object, but then segfaults here when it
should fail the completeness test.
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix the return type and allow src and dst types for comparison
to be separate, this at least fixes the two test cases I've written.
v2: drop the u32->s32 change
Acked-by: Christoph Bumiller <christoph.bumiller@speed.at>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When the old contents do not need to be preserved, it is faster to
create a new backing bo rather than stall.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
max_index may be 0xffffffff. The hardware does not need 1 + max_index
(although it does not hurt unless max_index wraps around to zero).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
For mem->gmem we don't sample depth/stencil as it's native type. So we
need to setup the swizzle state for the sampler based on the format used
for sampling.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Needed by some games, like etuxracer and supertuxkart which use alpha
test rather than blending, to handle texture transparency.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
With a debug option to force DIRECT (mainly to make it easier for
capturing cmdstream dumps). Using INDIRECT for large shaders at least
makes a noticable reduction in CPU load, which helps for CPU limited
games.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Because of how the tiling works, we can't really flush at arbitrary
points very easily. So wraparound is handled by resetting to top of
ringbuffer. Previously this would stall until current rendering is
complete. Instead cycle through multiple ringbuffers to avoid a stall.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Emit markers by writing to scratch registers in order to "triangulate"
gpu lockup position from post-mortem register dump. By comparing
register values in post-mortem dump to command-stream, it is possible to
narrow down which DRAW_INDX caused the lockup.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Have a single helper that all draws come through.. mainly for a
convenient debug and instrumentation point.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The varying-out config comes from the inputs of the frag shader (so that
we aren't exporting unneeded varyinges). The varyings-count should come
from the frag shader as well, to avoid a discrepency in configuration
and resulting gpu lockup.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
These functions are defined in EXT_texture_array, which makes no
mention of what shader types they should be allowed in. At the time
EXT_texture_array was introduced, functions ending in "Lod" were
available only in vertex shaders, however this restriction was lifted
in later spec versions and extensions.
We already have the function lod_exists_in_stage() for figuring out
whether functions ending in "Lod" should be available, so just re-use
that.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since BRW_MAX_WM_SURFACES is greater than BRW_MAX_VEC4_SURFACES, the
existing array isn't large enough to be used by the WM. Increasing it
will make it possible to share them.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
These are largely based on the similar fields in brw->wm.
v2: Add a better comment than "Scratch buffer".
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Everyone at the Khronos meeting was as surprised that GLSL didn't
already support this as we were. Several vendors said they'd ship it,
but there didn't seem to be enough interest to put in the effort to make
it ARB or KHR.
v2: Fix a couple typos and rename the spec file to
EXT_shader_integer_mix.spec. Suggested by Roland.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
start_instance doesn't affect gl_InstanceID.
There's no piglit test, but it's kinda obvious the code was wrong.
Reviewed-by: Christian König <christian.koenig@amd.com>
The shader is responsible for writing to streamout buffers using
the TBUFFER_STORE_FORMAT_* instructions.
The locations of some input SGPRs and VGPRs are assigned dynamically, because
the input SGPRs controlling streamout are not declared if they are not needed,
decreasing the indices of all following inputs.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
So that the "init" state is always emitted first and not later in draw_vbo.
This fixes streamout where the "init" state, which disables streamout,
was emitted in draw_vbo after streamout was enabled.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This could happen if set_stream_output_targets is called twice
in a row without a draw call in between.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Paused transform feedback objects may refer to a program other than the
current program. If any active objects refer to a program, LinkProgram
must reject the request to relink.
The code to detect this is ugly since _mesa_HashWalk is awkward to use,
but unfortunately we can't use hash_table_foreach since there's no way
to get at the underlying struct hash_table (and even then, we'd need to
handle locking somehow).
Fixes the last subcase of Piglit's new ARB_transform_feedback2
api-errors test.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is actually a pretty important error condition: otherwise, you
could set up transform feedback with one program, and resume it with
a program that generates a completely different set of outputs.
Fixes a subcase of Piglit's new ARB_transform_feedback2 api-errors test.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The next few patches will use this for API error checking.
All of the drivers appear to CALLOC_STRUCT transform feedback objects,
so this should be properly NULL initialized on creation.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes a subcase of Piglit's new ARB_transform_feedback2 api-errors test.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Move the code back into the common UVD files since we now
have base structures for R600 and radeonsi.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Fixes FTBFS on kfreebsd-*
Debian GNU/kFreeBSD doesn't provide getprogname() since it uses stdlib.h
from glibc. Instead it provides program_invocation_short_name from glibc.
You can find the same order in src/mesa/drivers/dri/common/xmlconfig.c
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Tested-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
It was wrong for EXP.y, as we clamped the source before computing the
fractional part, and this opcode should be rarely used, so it's not
worth the hassle.
We used to pass the number of components actually used for the
coordinate (rather than padding, shadow comparitors, and projectors) by
hand, specifying it on every _texture() call.
The new helper function can just compute this, eliminating a lot of
potential mistakes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This computes the number of components necessary to address a sampler
based on its dimensionality. It will be useful for texturing built-ins.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
It is planned to ship openSUSE 13.1 with -shared libs.
nouveau.la, nv30.la, nv50.la and nvc0.la are currently LIBADDs in all nouveau
related targets.
This change makes it possible to easily build one shared libnouveau.so which is
then LIBADDed.
Also dlopen will be faster for one library instead of three and build time on
-jX will be reduced.
Whitespace fixes were requested by 'git am'.
Signed-off-by: Johannes Obermayr <johannesobermayr@gmx.de>
Acked-by: Christoph Bumiller <christoph.bumiller@speed.at>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
According to GLSL, the shader may call EndPrimitive() at any point
during its execution, causing the line or triangle strip currently
being output to be terminated and a new strip to be begun.
This is implemented in gen7 hardware by using one control data bit per
vertex, to indicate whether EndPrimitive() was called after that
vertex was emitted.
In order to make this work without sacrificing too much efficiency, we
accumulate 32 control data bits at a time in a GRF. When we have
accumulated 32 bits (or when the shader terminates), we output them to
the appropriate DWORD in the control data header and reset the
accumulator to 0.
We have to take special care to make sure that EndPrimitive() calls
that occur prior to the first vertex have no effect.
Since geometry shaders that output a large number of vertices are
likely to be rare, an optimization kicks in if max_vertices <= 32. In
this case, we know that we can wait until the end of shader execution
before any control data bits need to be output.
I've tried to write the code in such a way that in the future, we can
easily adapt it to output stream ID bits (which are two bits/vertex
instead of one).
Fixes piglit tests "spec/glsl-1.50/glsl-1.50-geometry-end-primitive *".
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, brw_urb_WRITE() would always generate a URB_WRITE_HWORD
message, we always wanted to write data to the URB in pairs of varying
slots or larger (an HWORD is 32 bytes, which is 2 varying slots).
In order to support geometry shader EndPrimitive functionality, we'll
need the ability to write to just a single OWORD (16 byte) slot, since
we'll only be outputting 32 of the control data bits at a time. So
this patch adds a flag that will cause brw_urb_WRITE to generate a
URB_WRITE_OWORD message.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, brw_urb_WRITE() would unconditionally override the channel
masks in the URB_WRITE message to 0xff (indicating that all channels
should be written to the URB).
In order to support geometry shader EndPrimitive functionality, we'll
need the ability to set the channel masks programatically, so that we
can output just 32 of the control data bits at a time. So this patch
adds a flag that will prevent brw_urb_WRITE() from overriding them.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The gen7 geometry shader uses a "control data header" at the beginning
of the output URB entry to store either
(a) flag bits (1 bit/vertex) indicating whether EndPrimitive() was
called after each vertex, or
(b) stream ID bits (2 bits/vertex) indicating which stream each vertex
should be sent to (when multiple transform feedback streams are in
use).
Fortunately, OpenGL only requires separate streams to be supported
when the output type is points, and EndPrimitive() only has an effect
when the output type is line_strip or triangle_strip, so it's not a
problem that these two uses of the control data header are mutually
exclusive.
This patch modifies do_vec4_gs_prog() to determine the correct
hardware settings for configuring the control data header, and
modifies upload_gs_state() to propagate these settings to the
hardware.
In addition, it modifies do_vec4_gs_prog() to ensure that the output
URB entry is large enough to contain both the output vertices *and*
the control data header.
Finally, it modifies vec4_gs_visitor so that it accounts for the size
of the control data header when computing the offset within the URB
where output vertex data should be stored.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v2: Fixed incorrect handling of IVB/HSW differences.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This information will be useful in the i965 back end, since we can
save some compilation effort if we know from the outset that the
shader never calls EndPrimitive().
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Do not attempt to share the code that uploads
3DSTATE_BINDING_TABLE_POINTERS_GS, 3DSTATE_SAMPLER_STATE_POINTERS_GS,
or 3DSTATE_GS with VS.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v3: Add _NEW_TRANSFORM to gen7_gs_state.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will allow us to reuse some code when setting up the geometry
shader stage.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Mesa provides the wayland-egl libs and the pkgconfig file, but the headers
originate from the wayland package. Ensure everything matches, by requiring
application builds to look at the wayland headers as well.
Signed-off-by: Torsten Duwe <duwe@suse.de>
Signed-off-by: Johannes Obermayr <johannesobermayr@gmx.de>
Commit b77316ad75
st/dri: always copy new DRI front and back buffers to corresponding MSAA buffers
introduced creating a pipe_context for every call to validate, which is not required
because the callers have a context anyway.
Only exception is egl_g3d_create_pbuffer_from_client_buffer, can someone test if it
still works with NULL passed as context for validate? From examining the code I
believe it does, but I didn't thoroughly test it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: 9.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We've observed GPU hangs on Ivybridge from the following instruction:
mov(8) g115<1>.F 0D { align16 WE_normal NoDDChk 1Q };
There should be no reason to ever set the writemask on a destination
register to zero, except for perhaps the ARF NULL register.
This patch adds an assertion to enforce this for non-ARF registers.
Excluding ARFs is conservative yet should still catch the majority
of mistakes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Otherwise, coordinates with four components would result in a MOV
with a destination writemask that has no channels enabled:
mov(8) g115<1>.F 0D { align16 WE_normal NoDDChk 1Q };
At best, this is stupid: we emit code that shouldn't do anything.
Worse, it apparently causes GPU hangs (observable with Chris's
textureGather test on CubeArrays.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Cc: mesa-stable@lists.freedesktop.org
This was originally introduced by commit
ba47aabc98, but unfortunately the commit message
doesn't go into much detail about why +INF would be a problem here.
A similar issue exists for STATE_FOG_PARAMS_OPTIMIZED, but allowing infinity
there would potentially introduce NaNs where they shouldn't exist, depending
on the values of fog end and the fog coord. Since STATE_FOG_PARAMS_OPTIMIZED
is only used for fixed function (including ARB_fragment_program with fog
option), and the calculation there probably isn't very stable to begin with
when fog start and end are close together, it seems best to just leave it
alone.
This fixes piglit glsl-fs-fogscale, and a couple of Wine D3D tests. No piglit
regressions on Cayman.
Signed-off-by: Henri Verbeet <hverbeet@gmail.com>
Tested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
278372b47e added the uninitialized pointer
field gl_sync_object:Label. A free of this pointer, added in commit
6d8dd59cf5, resulted in a crash.
This patch fixes piglit ARB_sync regressions with swrast introduced by
6d8dd59cf5.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
These instructions will be used with immediate arguments in the upcoming
ldexp lowering pass and frexp implementation.
v2: Add vec4 support as well.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
It's a ?: that operates per-component on vectors. Will be used in
upcoming lowering pass for ldexp and the implementation of frexp.
csel(selector, a, b):
per-component result = selector ? a : b
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
builtin_info was originally going to be a structure containing a bunch
of information, but after various rewrites, it turned into a boolean
availability predicate.
builtin_avail is a better name than builtin_info, since it doesn't
store any information other than availability.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This creates a new replacement for the existing built-in function code.
The new module lives in builtin_functions.cpp (not builtin_function.cpp)
and exists in parallel with the existing system. It isn't used yet.
The new built-in function code takes a significantly different approach:
Instead of implementing built-ins via printed IR, build time scripts,
and run time parsing, we now implement them directly in C++, using
ir_builder. This translates to faster load times, and a much less
complex build system.
It also takes a different approach to built-in availability: each
signature now stores a boolean predicate, which makes it easy to
construct arbitrary expressions based on _mesa_glsl_parse_state's
fields. This is much more flexible than the old system, and also
easier to use.
Built-ins are also now stored in a single gl_shader object, rather
than being spread out across a number of shaders that need to be linked.
When searching for a matching prototype, we simply consult the
availability predicate. This also simplifies the code.
v2: Incorporate Matt Turner's feedback: use the new fma() function rather
than expr(). Don't expose textureQueryLOD() in GLSL 4.00 (since it
was renamed to textureQueryLod()). Also correct some #undefs.
v3: Incorporate Paul Berry's feedback: rename legacy to compatibility;
add comments to explain a few things; fix uvec availability; include
shaderobj.h instead of repeating the _mesa_new_shader prototype.
v4: Fix lack of TEX_PROJECT on textureProjGrad[Offset] (caught by oglc).
Add an out_var convenience function (more feedback by Matt Turner).
v5: Rework availability predicates for Lod functions. They were broken.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Enthusiastically-acked-by: Paul Berry <stereotype441@gmail.com>
Each ir_factory needs an instruction list and memory context in order to
be useful. Rather than creating an object and manually assigning these,
we can just use optional parameters in the constructor.
This makes it possible to create a ready-to-use factory in one line:
ir_factory body(&sig->body, mem_ctx);
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Adding new convenience emitters makes it easier to generate IR involving
these opcodes.
bitfield_insert is particularly useful, since there is no expr() for
quadops.
v2: Add fma() and rename lrp() operands to x/y/a to match the GLSL
specification (suggested by Matt Turner). Fix whitespace issues.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
IR builder already offers a lot of swizzling functions, such as
swizzle_xxxx, swizzle_z, or swizzle_for_size.
The swizzle_xxxx style is convenient if you statically know which
components you want. swizzle_for_size is great if you want to select
the first few components. However, if you want to select components
based on, say, a loop counter, none of those are sufficient.
IR builder actually already had support for arbitrary swizzling, but
didn't expose it. This patch exposes that API.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
dotlike() uses ir_binop_mul for scalars, and ir_binop_dot for vectors.
When generating built-in functions, we often want to use regular
multiply for scalar signatures, and dot() for vector signatures.
ir_binop_dot only works on vectors, so we have to switch opcodes,
even if the code is otherwise identical. dotlike() makes this easy.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We use "ret" as the function name since "return" is a C++ keyword, and
"ir_return" is already a class name.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This adds two new signatures:
assign(lhs, rhs, condition, writemask);
assign(lhs, rhs, condition);
All the other existing APIs still exist.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We already have ir_expression constructors for unary and binary
operations, which automatically infer the type based on the opcode and
operand types.
These are convenient and also required for ir_builder support.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This isn't strictly necessary, since creators of ir_texture objects
should set LOD when relevant. However, it's nice to have a NULL pointer
in case they forget.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
During compilation, we'll use this to determine built-in availability.
The plan is to have a single shader containing every built-in in every
version of the language, but filter out the ones that aren't actually
available to the shader being compiled.
At link time, we don't actually need this filtering capability: we've
already imported prototypes for every built-in that the shader actually
calls, and they're flagged as is_builtin(). The linker doesn't import
any additional prototypes, so it won't pull in any unavailable
built-ins. When resolving prototypes to function definitions, the
linker ensures the values of is_builtin() match, which means that a
shader can't trick the linker into importing the body of an unavailable
built-in by defining a suspiciously similar prototype.
In other words, during linking, we can just pass in NULL. It will work
out fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We can simply call the stored predicate function. If state is NULL,
just report that the function is available.
v2: Add a comment (requested by Paul Berry).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This promises the method won't modify the contents of the object.
This allows us to call it even with a const pointer to the state.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
A signature is a built-in if and only if builtin_info != NULL, so we
don't actually need a separate flag bit. Making a boolean-valued
method allows existing code to ask the same question while not worrying
about the internal representation.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
For the upcoming built-in function rewrite, we'll need to be able to
answer "Is this built-in function signature available?".
This is actually a somewhat complex question, since it depends on the
language version, GLSL vs. GLSL ES, enabled extensions, and the current
shader stage.
Storing such a set of constraints in a structure would be painful, so
instead we store a function pointer. When creating a signature, we
simply point to a predicate that inspects _mesa_glsl_parse_state and
answers whether the signature is available in the current shader.
Unfortunately, IR reader doesn't actually know when built-in functions
are available, so this patch makes it lie and say that they're always
present. This allows us to hook up the new functionality; it just won't
be useful until real data is populated. In the meantime, the existing
profile mechanism ensures built-ins are available in the right places.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Otherwise, coordinates with four components would result in a MOV
with a destination writemask that has no channels enabled:
mov(8) g115<1>.F 0D { align16 WE_normal NoDDChk 1Q };
At best, this is stupid: we emit code that shouldn't do anything.
Worse, it apparently causes GPU hangs (observable with Chris's
textureGather test on CubeArrays.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Chris Forbes <chrisf@ijw.co.nz>
Cc: mesa-stable@lists.freedesktop.org
The change is very small. Do seamless filtering if either the context
enable is set or the sampler enable is set.
The AMD_seamless_cubemap_per_texture says:
"If TEXTURE_CUBE_MAP_SEAMLESS_ARB is emabled (sic) globally or the
value of the texture's TEXTURE_CUBE_MAP_SEAMLESS_ARB parameter is
TRUE, seamless cube map sampling is enabled..."
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Appendix F.2 of the OpenGL ES 3.0.0 spec says:
"OpenGL ES 3.0 requires that all cube map filtering be
seamless. OpenGL ES 2.0 specified that a single cube map face be
selected and used for filtering."
Setting the field only in the context will work fine with sampler
objects (and drivers that support AMD_seamless_cubemap_per_texture)
because seamless filtering is used if *either* the context or the
sampler enable it:
"If TEXTURE_CUBE_MAP_SEAMLESS_ARB is emabled (sic) globally or the
value of the texture's TEXTURE_CUBE_MAP_SEAMLESS_ARB parameter is
TRUE, seamless cube map sampling is enabled..."
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reported-by: Maxence Le Dore <maxence.ledore@gmail.com>
Thanked-by: Maxence Le Dore <maxence.ledore@gmail.com>
There is no GL_TEXTURE_CUBE_MAP_SEAMLESS in any version of OpenGL ES or
in any extension that applies to OpenGL ES. The same error check
already occurs for glTexParameteri.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: Maxence Le Dore <maxence.ledore@gmail.com>
This aligns the gfx, compute, and dma IBs to 8 DW boundries.
This aligns the the IB to the fetch size of the CP for optimal
performance. Additionally, r6xx hardware requires at least 4
DW alignment to avoid a hw bug. This also aligns the DMA
IBs to 8 DW which is required for the DMA engine. This
alignment is already handled in the gallium driver, but that
patch can be removed now that it's done in the winsys.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CC: "9.2" <mesa-stable@lists.freedesktop.org>
CC: "9.1" <mesa-stable@lists.freedesktop.org>
We support indirect addressing only on the vertex index, but some
shaders also use indirect addressing on attributes. This patch
adds support for indirect addressing on both dimensions inside
gs arrays.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
When adding a new buffer to the beginning of the memory pool, we were
accidentally deleting the buffer that was first in the buffer list.
This was caused by a bug in the memory pool's linked list
implementation.
DPA2 is listed in the "Defeatured Instructions" section of the
965 PRM, Volume 4:
"The following instructions are removed from Gen4 implementation mainly
due to implementation cost/schedule reasons. They are candidates for
future generations."
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
RSR and RSL are listed in the "Defeatured Instructions" section of the
965 PRM, Volume 4:
"The following instructions are removed from Gen4 implementation mainly
due to implementation cost/schedule reasons. They are candidates for
future generations."
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes a bug where if an uniform array is passed to a function the accesses
to the array are not propagated so later all but the first vector of the
uniform array are removed in parcel_out_uniform_storage resulting in
broken shaders and out of bounds access to arrays in
brw::vec4_visitor::pack_uniform_registers.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-and-Tested-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Haswell GT2 and GT3 require the number of vertex shader URB entries to
be at least 64, not 32.
At the moment, we always meet this requirement automatically, because
in the absence of a geometry shader, we assign all available URB space
to the vertex shader. But when we turn on support for geometry
shaders, this lower limit will become important.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This patch creates a new file brw_vec4_vs_visitor.cpp, to contain code
that is specific to the vertex shader. Now the organization of vertex
shader and geometry shader visitor code is symmetric: vs-specific code
is in brw_vec4_vs_visitor.cpp, gs-specific code is in
brw_vec4_gs_visitor.cpp, and code shared between vs and gs is in
brw_vec4_visitor.cpp.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
This will allow it to be shared between brw_vec4_visitor.cpp and
brw_vec4_vs_visitor.cpp (which will be created in the next patch).
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
The fixup code emulates non-BGRA render targets by adding an
extra instruction at the end of fragment shaders to swizzle the
output. To do this, we also swizzle the blend function. However
an oversight until now was that the writemask wasn't getting
swizzled. This patch fixes that which fixes a bunch of piglit
tests.
The old code in dri2_glx suffered from a typographical error that caused
the default version to be 2.1 instead of 1.2 (minimum required by the
Linux OpenGL ABI). drisw_glx had a similar error resulting in a default
version of 0.1.
Some driver/card combinations (r200/RV280, i915/915G) don't support
OpenGL 2.1. These create in some corner cases an indirect context
instead of a direct context when calling glXCreateContextAttribsARB().
This happens because of a bad default value. To avoid this, just used
the default value specified by the GLX_ARB_create_context specification:
"The default values for GLX_CONTEXT_MAJOR_VERSION_ARB and
GLX_CONTEXT_MINOR_VERSION_ARB are 1 and 0 respectively. In this
case, implementations will typically return the most recent version
of OpenGL they support which is backwards compatible with OpenGL 1.0
(e.g. 3.0, 3.1 + GL_ARB_compatibility, or 3.2 compatibility
profile)"
Refactor all the default value setting to dri2_convert_glx_attribs, and
make sure the correct defaults are set in that one place.
Signed-off-by: Rico Schüller <kgbricola@web.de>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla http://bugs.winehq.org/show_bug.cgi?id=34238
Cc: "9.1 9.2" <mesa-stable@lists.freedesktop.org>
This patch adds liveness analysis to i915g and a couple
optimizations which benefit from it. One interesting
optimization turns (fake) indirect texture accesses into direct
texture accesses (the i915 supports a maximum of 4 indirect
texture accesses). Among other things this fixes a bunch of
piglit tests.
The vertex shader color outputs (gl_FrontColor, gl_BackColor,
gl_FrontSecondaryColor, and gl_BackSecondaryColor) don't have the same
names as the matching fragment shader color inputs (gl_Color and
gl_SecondaryColor). As a result, the qualifiers on them were not being
properly cross validated.
Full spec compliance required ir_variable::used and
ir_variable::assigned be set properly. Without the preceeding patch,
which fixes the ::clone method to copy them, this will not be the case.
Fixes all of the previously failing piglit
spec/glsl-1.30/linker/interpolation-qualifiers tests.
v2: Update callers of cross_validate_types_and_qualifiers and
cross_validate_front_and_back_color. The function signature changed in
v2 of a previous patch. Suggested by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47755
The new function, cross_validate_types_and_qualifiers, will have
multiple callers from this file in future commits.
v2: Don't pass the names of the producer / consumer stages to
cross_validate_types_and_qualifiers. Instead, pass the types and get
the names only in the error paths. Suggested by Paul.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Changes to the grammar for GL_ARB_shading_language_420pack (commit
6eec502) moved precision qualifiers out of the type_specifier production
chain. This caused declarations such as:
struct S {
lowp float f;
};
to generate parse errors. Section 4.1.8 (Structures) of both the GLSL
ES 1.00 spec and GLSL 1.30 specs says:
"Member declarators may contain precision qualifiers, but may not
contain any other qualifiers."
So, it sure seems like we shouldn't generate a parse error. :)
Instead of type_specifier, use fully_specified_type in struct members.
However, fully_specified_type allows a lot of other qualifiers that are
not allowed on structure members, so expeclitly disallow them.
Note, this makes struct_declaration look an awful lot like
member_declaration (used for interface blocks). We may want to
(somehow) unify these rules to reduce code duplication at some point.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68753
Reported-by: Aras Pranckevicius <aras@unity3d.com>
Cc: Aras Pranckevicius <aras@unity3d.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Remap any type or severity exclusive to KHR_debug to
something suitable for ARB_debug_output
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Brian Paul <brianp@vmware.com>
V3: make sure to add null terminator when setting label,
generate error when the client specifies an explicit
length that exceeds MAX_LABEL_LENGTH, set label pointer
to NULL when freed, and output correct length in
MAX_LABEL_LENGTH error message.
V2: fixed indentation of comment
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Brian Paul <brianp@vmware.com>
The main GL context's swtnl_im field is the VBO module's vbo_context
structure. Using the name "swtnl" in the name is confusing since
some drivers use hardware texturing and lighting, but still rely on the
VBO module for drawing.
v2: Forward declare the type and use that instead of void *
(suggested by Eric Anholt).
v3: Remove unnecessary cast (pointed out by by Topi Pohjolainen).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Some drawing functions take a single _mesa_prim object, while others
take an array of primitives. Both kinds of functions used a parameter
called "prim" (the singular form), which was confusing.
Using the plural form, "prims," clearly communicates that the parameter
is an array of primitives.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
can_cut_index_handle_prims() was passed an array of _mesa_prim objects
and a count, and ran a loop for that many iterations. However, it
treated the array like a pointer, repeatedly checking the first element.
This patch makes it actually check every primitive.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Fixes assertion failues in 24 piglit tests with
MESA_GL_VERSION_OVERRIDE=3.0, 12 of which are now passing.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
LIBGL_SHOW_FPS=1 makes GLX print FPS every second while other values do
nothing. Extend it so that LIBGL_SHOW_FPS=N will print the FPS every N
seconds.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The VBO module actually calls us with an array of _mesa_prim objects.
For example, it may break up a DrawArrays() call into multiple
primitives when primitive restart is enabled.
Previously, we treated prim like a pointer, always accessing element 0.
This worked because all of the primitive objects in a single draw call
have the same value for num_instances and basevertex.
However, accessing an array as a pointer and using the wrong object's
fields is misleading. For stylistic reasons alone, we should use the
right object.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
These functions have almost identical code; the only difference is that
a few of the bits moved around. Adding a few trivial conditionals
allows the same function to work on all generations, and the resulting
code is still quite readable.
v2: Comment that the workaround flush is only necessary on SNB
(requested by Paul Berry).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Fixes broken rendering if these MRFs contained anything other than zero.
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There is a slight functionality change. Previously we would compute a
common value for num_samplers for all stages, and populate that many
entries in each stage's surf_offset table regardless of how many
samplers each stage used. Now we only populate the number of entries
in the surf_offset table corresponding to the number of samplers
actually used by the stage.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously these functions would accept a pointer to the binding table
and an index indicating which entry in the binding table should be
updated. Now they merely take a pointer to the binding table entry to
be updated.
This will make it easier to generalize brw_texture_surfaces to support
geometry shaders.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch implements pull constant upload, binding table upload, and
surface setup for geometry shaders, by re-using vertex shader code
that was generalized in previous patches.
Based on work by Eric Anholt <eric@anholt.net>.
v2: Update ditry bits for brw_gs_ubo_surfaces to account for commit
77d8fbc (mesa: add & use a new driver flag for UBO updates instead of
_NEW_BUFFER_OBJECT).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The hardware requires that after constant buffers for a stage are
allocated using a 3DSTATE_PUSH_CONSTANT_ALLOC_{VS,HS,DS,GS,PS}
command, and prior to execution of a 3DPRIMITIVE, the corresponding
stage's constant buffers must be reprogrammed using a
3DSTATE_CONSTANT_{VS,HS,DS,GS,PS} command.
Previously we didn't need to worry about this, because we only
programmed 3DSTATE_PUSH_CONSTANT_ALLOC_{VS,HS,DS,GS,PS} once on
startup (or, previous to that, whenever BRW_NEW_CONTEXT was flagged).
But now that we reallocate the constant buffers whenever geometry
shaders are switched on and off, we need to make sure the constant
buffers are reprogrammed.
We do this by adding a new bit, BRW_NEW_PUSH_CONSTANT_ALLOCATION, to
brw->state.dirty.brw.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we would always use the same push constant allocation
regardless of what shader programs were being run: the available push
constant space was split into 2 equal size partitions, one for the
vertex shader, and one for the fragment shader.
Now that we are adding geometry shader support, we need to do
something smarter. This patch adjusts things so that when a geometry
shader is in use, we split the available push constant space into 3
nearly-equal size partitions instead of 2.
Since the push constant allocation is now affected by GL state, it can
no longer be set up by brw_upload_initial_gpu_state(); instead it must
be set up by a state atom.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is required by the internal hardware docs and the PRM. Probably
the reason we were getting away with not doing it was because we only
emitted 3DSTATE_PUSH_CONSTANT_ALLOC_PS during startup. However that's
going to change with the introduction of geometry shaders.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we gave all of the URB space (other than the small amount
that is used for push constants) to the vertex shader. However, when
a geometry shader is active, we need to divide it up between the
vertex and geometry shaders.
The size of the URB entries for the vertex and geometry shaders can
vary dramatically from one shader to the next. So it doesn't make
sense to simply split the available space in two. In particular:
- On Ivy Bridge GT1, this would not leave enough space for the worst
case geometry shader, which requires 64k of URB space.
- Due to hardware-imposed limits on the maximum number of URB entries,
sometimes a given shader stage will only be capable of using a small
amount of URB space. When this happens, it may make sense to
allocate substantially less than half of the available space to that
stage.
Our algorithm for dividing space between the two stages is to first
compute (a) the minimum amount of URB space that each stage needs in
order to function properly, and (b) the amount of additional URB space
that each stage "wants" (i.e. that it would be capable of making use
of). If the total amount of space available is not enough to satisfy
needs + wants, then each stage's "wants" amount is scaled back by the
same factor in order to fit.
When only a vertex shader is active, this algorithm produces
equivalent results to the old algorithm (if the vertex shader stage
can make use of all the available URB space, we assign all the space
to it; if it can't, we let it use as much as it can).
In the future, when we need to support tessellation control and
tessellation evaluation pipeline stages, it should be straightforward
to expand this algorithm to cover them.
v2: Use "unsigned" rather than "GLuint".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This paves the way for sharing the code that will set up the vertex
and geometry shader pipeline state.
v2: Rename the base class to brw_stage_state.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Defines that previously referred to VS now refer to VEC4, since they
will be shared by the user-programmable vertex shader and geometry
shader stages.
Defines that previously referred to the Gen6 geometry shader stage
(which is only used for transform feedback) are now renamed to
explicitly refer to Gen6, to avoid confusion with the Gen7
user-programmable geometry shader stage.
Based on work by Eric Anholt <eric@anholt.net>.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This will avoid confusion when we add geometry shaders, since these
data structures will be shared by vertex and geometry shaders.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Now that the name "gs" is no longer used to refer to the legacy fixed
function geometry shaders, we can use it to refer to user-defined
geometry shaders.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
"ff" is for "fixed function". This frees up the name "gs" to refer to
user-defined geometry shaders.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This mimics r600g. The R600_CONTEXT_xxx flags are added to rctx->b.flags
and si_emit_cache_flush emits the packets. That's it. The shared radeon code
tells us when the streamout cache should be flushed, so we have to check
the flags anyway.
There is a new atom "cache_flush", because caches must be flushed *after*
resource descriptors are changed in memory.
Functional changes:
* Write caches are flushed at the end of CS and read caches are flushed
at its beginning.
* Sampler view states are removed from si_state, they only held the flush
flags.
* Everytime a shader is changed, the I cache is flushed. Is this needed?
Due to a hw bug, this also flushes the K cache.
* The WRITE_DATA packet is changed to use TC, which fixes a rendering issue
in openarena. I'm not sure how TC interacts with CP DMA, but for now it
seems to work better than any other solution I tried. (BTW CIK allows us
to use TC for CP DMA.)
* Flush the K cache instead of the texture cache when updating resource
descriptors (due to a hw bug, this also flushes the I cache).
I think the K cache flush is correct here, but I'm not sure if the texture
cache should be flushed too (probably not considering we use TC
for WRITE_DATA, but we don't use TC for CP DMA).
* The number of resource contexts is decreased to 16. With all of these cache
changes, 4 doesn't work, but 8 works, which suggests I'm actually doing
the right thing here and the pipeline isn't drained during flushes.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
There is a new "class" si_buffer_resources, which should be good enough for
implementing any kind of buffer bindings (constant buffers, vertex buffers,
streamout buffers, shader storage buffers, etc.)
I don't even keep a copy of pipe_constant_buffer - we don't need it.
The main motivation behind this is to have a well-tested infrastrusture
for setting up streamout buffers.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
This streamout state code will be used by radeonsi.
There are new structures r600_common_context and r600_common_screen.
What is inherited by what is shown here:
pipe_context -> r600_common_context -> r600_context
pipe_screen -> r600_common_screen -> r600_screen
The common structures reside in drivers/radeon. Currently they only contain
enough functionality to be able to handle streamout. Eventually I'd like
the whole pipe_screen implementation to be shared and some of the context
stuff too.
This is quite big, but most changes are because of the new structures and
the fact r600_write_value is replaced by radeon_emit.
Thanks to Tom Stellard for fixing the build for r600g/compute.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
It is incorrect to assume that src[0] of a SEND-from-GRF opcode is the
GRF. For example, FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD uses src[1] for
the GRF.
To be safe, loop over all the source registers and mark any GRFs. We
probably won't ever have more than one, but it's simpler to just check
all three rather than attempting to bail early.
Not observed to fix anything yet, but likely to. Parallels the bug fix
in the previous commit, which actually does fix known failures.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: mesa-stable@lists.freedesktop.org
It is incorrect to assume that src[0] of a SEND-from-GRF opcode is the GRF.
VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 uses an IMM as src[0], and stores the
GRF as src[1].
To be safe, loop over all the source registers and mark any GRFs. We
probably won't ever have more than one, but it's simpler to just check
all three rather than attempting to bail early.
Fixes assertion failures in Unigine Sanctuary since we started making
register allocation rely on split_virtual_grfs working. (The register
classes were actually sufficient, we were just interpreting an IMM as
a virtual GRF number.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68637
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: mesa-stable@lists.freedesktop.org
pstipple/aaline stages used PIPE_MAX_SAMPLER instead of
PIPE_MAX_SHADER_SAMPLER_VIEWS when dealing with sampler views.
Now these stages can't actually handle sampler_unit != texture_unit anyway
(they cannot work with d3d10 shaders at all due to using tex not sample
opcodes as "mixed mode" shaders are impossible) but this leads to crashes if
a driver just installs these stages and then more than PIPE_MAX_SAMPLER views
are set even if the stages aren't even used.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Turns out we don't need to do much extra work for detecting this case,
since we are guaranteed to get a empty static texture state in this case,
hence just rely on format being 0 and return all zero then.
Previously needed dummy textures (would just have crashed on format being 0
otherwise) which cannot return the correct result for size queries and when
sampling textures with wrap modes using border.
As a bonus should hugely increase performance when sampling unbound textures -
too bad it isn't a useful feature :-).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
No idea if this is working right but copied straight from llvmpipe.
(Not only does this check the so_target but also use buffer->data instead
of buffer for the mapping.)
Just trying to get rid of a segfault testing something else...
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
The only reason this was needed was because the fetch texel function had to
get the (dynamic) border color, but this is now done much earlier.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Instead of enhancing the AoS path so it can deal with it, just use SoA. Fixing
AoS path wouldn't be all that difficult (use all the same logic as SoA) but
considered not worth it for now.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
If the app is asking us to do GL_COMPRESSED_RGBA, then the app obviously
doesn't have pre-compressed data to hand us. So don't choose a storage
format that we won't actually be able to compress and store.
Fixes black screen in warzone2100 when libtxc_dxtn is not present. Also
66 piglit tests.
NOTE: This is a candidate for the 9.2 branch.
Reported-by: Paul Wise <pabs@debian.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
You should only be flagging the formats as supported if you support them
anyway.
NOTE: This is a candidate for the 9.2 branch. (required for next commit)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Thanks to Ken for trawling through my neglected public branches and
finding the bug in this change (inside a megacommit) that made me abandon
this work.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This avoids the need to get the inter- and intra-tile offset and adjust
our miptree info based on them.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These are things that happen to be occurring because of the batch flush at
the start of the blorp op (which exists to prevent batch space or aperture
space overflow), but the intention was for this sequence of state resets at
the end of blorp to be everything necessary for the next draw call.
Found when debugging the next commit, by comparing brw_new_batch() and
intel_batchbuffer_reset() to brw_blorp_exec().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The code that got replaced with map_raw didn't do the flush, but now
map_raw() is responsible for it and we don't have to worry about it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This gives us more information about why we're flushing that we can
use for handling our throttling.
v2 (Kenneth Graunke): Rebase on latest master, add missing
FLUSH_VERTICES and FLUSH_CURRENT, which fixes a regression in Glean's
polygonOffset test.
v3 (anholt): Drop FLUSH_CURRENT -- FLUSH_VERTICES is what we need, which
is "get any queued prims out of VBO and into the driver", not "update
ctx->Current so we can read it with the CPU." Also drop batch->used
check, which intel_batchbuffer_flush() does anyway.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This was already happening because blorp happens to flush at the end of
every call, but we have been talking about removing that at some point,
and this would surely get overlooked.
v2 (Kenneth Graunke): Rebase on latest master. Note that we did remove
the other flush, and this change actually did get overlooked!
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
intel_flush() now did nothing except call through (and
intel_batchbuffer_flush() does the no-op check, too!)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
df06745c5a made it so that we didn't
allocate extra uniform space for unused clip planes, which also
incidentally made us not allocate any space at all, which we were relying
on for this no-uniforms case. Instead of putting the knowledge of this
special HW exception into the thing that normally preallocates prog_data
for us, just allocate it here.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68766
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since we can have per-pixel lod we should also honor the filter per-pixel
(in fact we didn't honor it per quad neither in the multiple quad case).
Do this by running the linear path and simply beating the weights into shape
(the sample with the higher weight is the one which should have been chosen
with nearest filtering hence adjust filter weight to 1.0/0.0 based on that).
If all pixels use nearest filter (either min and mag) then still run just a
nearest filter as this is way cheaper (probably around 4 times faster for 2d,
more for 3d case) and it should be relatively rare that pixels really need
different filtering. OTOH if all pixels would require linear don't do anything
special since the linear path with filter adjustments shouldn't really be all
that much more expensive than ordinary linear, and we think it's rare that
min/mag filters are configured differently so there doesn't seem much value
in trying to optimize this further.
This does not yet fix the AoS path (though currently AoS is only used for
single quads hence it could be considered less broken, just never honoring
per-pixel filter decision but doing it per quad).
v2: simplify code a bit (unify min linear and min nearest cases)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
While a sqrt here and there shouldn't hurt much (depending on the cpu) it is
possible to completely omit it since rho is only used for calculating lod and
there log2(x) == 0.5*log2(x^2). Depending on the exact path taken for
calculating lod this means we get a simple mul instead of sqrt (in case of
nearest mip filter in fact we don't need to replace the sqrt with something
else at all), only in some not very useful path this doesn't work (combined
brilinear calculation of int level and fractional lod, accurate rho calc but
brilinear filtering seems odd).
Apart from being faster as an added bonus this should increase our crappy
fractional accuracy of lod, since fast_log2 is only good for ~3bits and this
should increase accuracy by one bit (though not used if dimension is just one
as we'd need an extra mul there as we never had the squared rho in the first
place).
v2: use separate ilog2_sqrt function if we have squared rho.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This is just preparation for per-pixel (or per-quad in case of multiple quads)
min/mag filter since some assumptions about number of miplevels being equal
to number of lods no longer holds true.
This change does not change behavior yet (though theoretically when forcing
per-element path it might be slower with different min/mag filter since the
code will respect this setting even when there's no mip maps now in this case,
so some lod calcs will be done per-element just ultimately still the same
filter used for all pixels).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Fixes "Missing break in switch" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The downstream android kernel driver is "kgsl", the upstream drm/kms
driver is called "msm". Since libdrm_freedreno handles the differences
between the two, we need to load the same thing for either device.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
We need to set the flag on all the .xyzw components that are written by
the instruction, not just on .x. Otherwise a later use of rN.y (for
example) will not trigger the appropriate sync bit to be set.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Seems like most/all instructions have some restrictions about const src
registers. In seems like the 2 src (cat2) instructions can take at most
one const, and the 3 src (cat3) instructions can take at most one const
in the first 2 arguments. And so on. Handle this properly now.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
GLSL 1.30 doesn't allow precision qualifiers on sampler types,
but in GLSL ES, sampler types are also allowed. This seems like
an oversight (since the intention of including these in GLSL 1.30
is to allow compatibility with ES shaders).
Currently, Mesa allows "default" precision qualifiers to be set for
sampler types in GLSL (commit d5948f2). This patch makes it follow
GLSL ES rules and also allow declaring sampler variables with a
precision qualifier in GLSL 1.30 (and later). e.g.
uniform lowp sampler2D sampler;
This fixes a shader compilation error in Khronos OpenGL conformance
test "depth_texture_mipmap".
V2: Update comments.
Signed-off-by: Ian Romanick <idr@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <idr@lists.freedesktop.org>
Cc: <mesa-stable@lists.freedesktop.org>
Previously, we allocated space in brw_vs_prog_data's params and
pull_params arrays for MAX_CLIP_PLANES vec4s---even when it wasn't
necessary.
On a 64-bit architecture, this used 0.5 kB of space (8 clip planes *
4 floats per plane * 8 bytes per float pointer * 2 arrays of pointers =
512 bytes). Since this cost was per-vertex shader, it added up.
Conveniently, we already store the number of clip plane constants in the
program key. By using that, we can allocate the exact amount of space
needed. For the common case where user clipping is disabled, this means
0 bytes.
While we're here, mention exactly what code requires this extra space,
since it wasn't obvious.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
When validating draw parameters move check for 0 draw count last
(drawing with count 0 is not an error), so that other parameters (e.g.: the
primitive type) are validated and the correct errors (if applicable) are
generated.
>From the OpenGL 3.3 spec page 33 (page 48 of the PDF):
"[Regarding DrawArraysOneInstance, in terms of which other draw operations
are defined:]
If count is negative, an INVALID_VALUE error is generated."
This patch also changes the bahavior of MultiDrawElements to perform the draw
operation if some primitive's index counts are zero.
Signed-off-by: Fabian Bieler <fabianbieler@fastmail.fm>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
MAD will be generated directly from ir_triop_fma, so this assertion
checks that all ir_expressions are usable.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
MSAA was tested by one user on RS690 and it works for him with color
compression (CMASK) disabled. Our theory is that his chipset lacks CMASK RAM.
Since we don't have hardware documentation about which chipsets actually have
CMASK RAM, I had to take a guess based on the presence of HiZ.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
In particular noone is interested in the vertex count, so drop that,
and also drop the duplicated num_primitives_generated /
so.primitives_storage_needed variables in drivers. I am unable for now to figure
out if primitives_storage_needed in SO stats (used for d3d10) should
increase if SO is disabled, though the equivalent num_primitives_generated
used for OpenGL definitely should increase. In any case we were only counting
when SO is active both in softpipe and llvmpipe anyway so don't pretend there's
an independent num_primitives_generated counter which would count always.
(This means the PIPE_QUERY_PRIMITIVES_GENERATED count will still be wrong just
as before, should eventually fix this by doing either separate counting for this
query or adjust the code so it always counts this even if SO is inactive depending
on what's correct for d3d10.)
Reviewed-by: Brian Paul <brianp@vmware.com>
SEQ and SNE are not native i915 instructions, so they each generate at
least 3 instructions. If both operands are uniforms or constants, we
get 5 instructions like:
U[1] = MOV CONST[1]
U[0].xyz = SGE CONST[0].xxxx, U[1]
U[1] = MOV CONST[1].-x-y-z-w
R[0].xyz = SGE CONST[0].-x-x-x-x, U[1]
R[0].xyz = MUL R[0], U[0]
This code is stupid. Instead of having the individual calls to
i915_emit_arith generate the moves to utemps, do it in the caller. This
results in code like:
U[1] = MOV CONST[1]
U[0].xyz = SGE CONST[0].xxxx, U[1]
R[0].xyz = SGE CONST[0].-x-x-x-x, U[1].-x-y-z-w
R[0].xyz = MUL R[0], U[0]
This allows fs-temp-array-mat2-index-col-wr and
fs-temp-array-mat2-index-row-wr to fit in hardware limits (instead of
falling back to software rasterization).
NOTE: Without pending patches to the piglit tests, these tests will now
fail. This is an unrelated, pre-existing issue.
v2: Copy most of the body of the commit message into comments in the
code. Suggested by Eric.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The command is submitted once the event has been triggered, but it might not
have completed yet. Therefore, we have to add it to deps in order to wait on it.
Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
I previously fixed this partly in 9e8400f4c9,
however I didn't go far enough in testing it, now when I parse a TGSI shader
with arrays in it my iterator can see the ArrayID set to the proper value.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that we use a fixed set of register classes, we can set up the
register set and conflict graphs once, at context creation, rather than
on every VS compile. This is obviously less expensive, and also what
we already do in the FS backend.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We're soon going to be calling brw_alloc_reg_set() from outside of the
visitor, where we don't have the precomputed "max_grf" variable handy.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
For now, nothing else can get allocated over them. That may change at
some point in the future.
This also means that base_reg_count can be computed without knowing the
number of registers used for the payload, which is required if we want
to allocate the register set once at context creation time.
See commit 551e1cd44f, which implemented
virtually identical code in the FS backend.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Arrays, structures, and matrices use large VGRFs of arbitrary sizes.
However, split_virtual_grfs() breaks those down into VGRFs of size 1.
For reference, commit 5d90b98879 is the
analogous change to the FS backend.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
(From a suggestion by Francisco Jerez)
If an enum represents a bitfield of flags, e.g.:
enum E {
A = 1,
B = 2,
C = 4,
D = 8,
};
then C++ normally prohibits statements like this:
enum E x = A | B;
because A and B are implicitly converted to ints before OR-ing them,
and an int can't be stored in an enum without a type cast. C, on the
other hand, allows an int to be implicitly converted to an enum
without casting.
In the past we've dealt with this situation by storing flag bitfields
as ints. This avoids ugly casting at the expense of some type safety
that C++ would normally have offered (e.g. we get no warning if we
accidentally use the wrong enum type).
However, we can get the best of both worlds if we override the |
operator. The ugly casting is confined to the operator overload, and
we still get the benefit of C++ making sure we don't use the wrong
enum type.
v2: Remove unnecessary comment and unnecessary use of "enum" keyword.
Use static_cast.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
We never noticed that this field was uninitialized because it is only
used in an error path that reports internal Mesa errors.
But it's silly to have it around anyway because &brw->ctx is
equivalent.
Should fix Coverity defect CID 1063351: Uninitialized pointer field
(UNINIT_CTOR) /src/mesa/drivers/dri/i965/brw_vec4_emit.cpp: 148
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
If brwNewProgram is asked to create a program for an unrecognized
target, don't bother falling back on _mesa_new_program(). That just
hides bugs.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
v2: Use assert() rather than _mesa_problem().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
330.frag is a direct copy of 150.frag.
330.glsl is 150.glsl combined with ARB_shader_bit_encoding.glsl.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These are necessary in order to compile the built-in functions.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
glIsQuery is supposed to return false for names returned by glGenQueries
until their first use. BeginQuery is a use, but QueryCounter is also a
use.
From the ARB_timer_query spec:
"A timer query object is created with the command
void QueryCounter(uint id, enum target);
[...] If <id> is an unused query object name, the
name is marked as used [...]"
Fixes Piglit's spec/ARB_timer_query/query-lifetime.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: mesa-stable@lists.freedesktop.org
I assume this should have been part of commit
7727fbb7c5. This (obviously) fixes a lot tests.
Signed-off-by: Henri Verbeet <hverbeet@gmail.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Commit 53e20b8b introduced the use of a template to initialize some
common fields. Move this copying of fields to before the common vp3
fields are initialized.
Reported-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Christian König <christian.koenig@amd.com>
The cmps.f.* instruction doesn't actually seem to give a float 1.0 or
0.0 output. It either needs a cov.u16f16 or add.s + sel.f16. This
makes SGT/SLT/etc more similar to CMP, so handle them in trans_cmp().
This fixes a bunch of piglit tests.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
It seems there are a number of cases where instructions have limitations
about taking reading src's from const register file, so make
get_unconst() a bit easier to use.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
We probably should get rid of assert() entirely, but at this stage it is
more useful for things to crash where we can catch it in a debugger.
With compile_error() we have a single place to set an error flag (to
bail out and return an error on the next instruction) so that will be a
small change later when enough of the compiler bugs are sorted.
But re-arrange/cleanup the error/assert stuff so we at least get a dump
of the TGSI that triggered it. So we see some useful output in piglit
logs.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Don't crash when no color buffer bound. Something caught when starting
to run piglit, fixes a hanful of piglit tests.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Category 4 instructions (rsq, rcp, sqrt, etc) seem to be unable to take
a const register as src. In these cases we need to move the src to a
temporary gpr first.
This is the second case of such a restriction, where the instruction
encoding appears to support a const src, but in fact the hw appears to
ignore that bit. So split things out into a helper that can be re-used
for any instructions which have this limitation.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Our current (rather naive) register assignment is based on mapping
different register files (INPUT, OUTPUT, TEMP, CONST, etc) based on the
max register index of the preceding file. But in some cases, the lowest
used register in a file might not be zero. In which case
file_count[file] != file_max[file] + 1.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Sometimes things other than color dst need saturating, like if there is
a 'clamp(foo, 0.0, 1.0)'. So for saturated dst add the extra
instructions to fix up dst.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The 1st src to add.s needs (r) flag (repeat), otherwise it will end up:
add.s dst.xyzw, tmp.xxxx -1
instead of:
add.s dst.xyzw, tmp.xyzw, -1
Also, if we are using a temporary dst to avoid clobbering one of the src
registers, we actually need to use that as the dst for the sel
instruction.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This patch adds support for:
PIPE_COMPUTE_CAP_MAX_INPUT_SIZE
PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE
Return the values reported by the closed source driver for now.
Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Previously, the min/mag switchover point when using nearest/none mip
filter was effectively -0.5 which can't be right. Looks like new OpenGL
thinks it's ok if it's always 0.0 (older versions required 0.5 in some
cases), let's hope everybody else thinks that's fine too.
Refactor this slightly and get the per-quad/per-pixel min/mag decision
values further down to sampling, though still only the first component
is used yet.
While here also fix code trying to skip lod bias application etc. when
mipfilter is none, as this is still needed for determining min/mag filter.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
As of "2f142d59 build: Add --enable-gallium-osmesa flag." the pkgconfig
file from classic osmesa is no longer installed when building gallium
osmesa, so copy it to gallium osmesa and install the copy instead.
CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This patch introduces the vec4_gs_visitor class, which translates
geometry shaders from GLSL IR to back-end opcodes.
This class is derived from vec4_visitor (which is also the base class
for vec4_vs_visitor), so as a result most of the back end code is
shared. The only parts that differ are:
- Geometry shaders use a different input payload organization, since
the inputs need to match up with the outputs of the previous
pipeline stage (vec4_gs_visitor::setup_payload() and
vec4_gs_visitor::setup_varying_inputs()).
- Geometry shader input array dereferences need a special stride
computation, since all geometry shader inputs are interleaved into
one giant array (vec4_gs_visitor::compute_array_stride()).
- There are no geometry shader system values
(vec4_gs_visitor::make_reg_for_system_value()).
- At the beginning of a geometry shader, extra data in R0 needs to be
zeroed out, and a vertex counter needs to be initialized
(vec4_gs_visitor::emit_prolog()).
- When EmitVertex() appears in the shader, the current contents of
output variables need to be emitted to the URB, and the vertex
counter needs to be incremented
(vec4_gs_visitor::visit(ir_emit_vertex *)).
- When generating a URB_WRITE message to output vertex data, the
current state of the vertex counter needs to be used to store a
write offset in the message header
(vec4_gs_visitor::emit_urb_write_header()).
- The URB_WRITE message that outputs vertex data needs to be sent
using GS_OPCODE_URB_WRITE, since VS_OPCODE_URB_WRITE would overwrite
the offsets in the message header
(vec4_gs_visitor::emit_urb_write_opcode()).
- At the end of a geometry shader, the final vertex count needs to be
delivered using a URB WRITE message
(vec4_gs_visitor::emit_thread_end()).
- EndPrimitive() functionality is not implemented yet
(vec4_gs_visitor::visit(ir_end_primitive *)).
- There is no support for assembly shaders
(vec4_gs_visitor::emit_program_code()).
v2: Make num_input_vertices const. Refer to registers as rN rather
than gN, for consistency with the PRM. Fix misspelling. Improve
comment in the ir_emit_vertex visitor explaining why we emit vertices
inside a conditional. Enclose the conditional code in the
ir_emit_vertex visitor between curly braces.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This will be used by geometry shaders to implement the EmitVertex()
function, since it requires writing data to a dynamically-determined
offset within the geometry shader's URB entry.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The arguments to brw_urb_WRITE() were getting pretty unwieldy, and we
have to add more flags to support geometry shaders anyhow.
Also plumb these flags through brw_clip_emit_vue(),
brw_set_urb_message(), and the vec4_instruction class.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
When I initially generalized the vec4_visitor class in preparation for
geometry shaders, I assumed that the setup_attributes() function would
need to be different between vertex and geometry shaders, but its
caller, setup_payload(), could be shared. So I made
setup_attributes() a virtual function.
It turns out this isn't true; setup_payload() needs to be different
too, since the geometry shader payload sometimes includes an extra
register (primitive ID) that has to come before uniforms.
So setup_payload() needs to be the virtual function instead of
setup_attributes().
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control,
which determines the register where the hardware delivers data sourced
from the URB (push constants followed by per-vertex input data).
For vertex shaders, we always set dispatch_grf_start_reg to 1, since
R1 is always the first register available for push constants in vertex
shaders.
For geometry shaders, we'll need the flexibility to set
dispatch_grf_start_reg to different values depending on the behvaiour
of the geometry shader; if it accesses gl_PrimitiveIDIn, we'll need to
set it to 2 to allow the primitive ID to be delivered to the thread in
R1.
This patch eliminates the assumption that dispatch_grf_start_reg is
always 1. In vec4_visitor, we record the regnum that was passed to
vec4_visitor::setup_uniforms() in prog_data for later use. In
vec4_generator, we consult this value when converting an abstract
UNIFORM register to a concrete hardware register. And in the code
that emits 3DSTATE_VS, we set dispatch_grf_start_reg based on the
value recorded in prog_data.
This will allow us to set dispatch_grf_start_reg to the appropriate
value when compiling geometry shaders. Vertex shaders will continue
to always use a dispatch_grf_start_reg of 1.
v2: Make dispatch_grf_start_reg "unsigned" rather than "GLuint".
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This patch moves the following things into brw_vec4.{cpp,h}:
- struct brw_vec4_compile
- struct brw_vec4_prog_key
- brw_vec4_prog_data_compare()
- brw_vec4_prog_data_free()
This will allow us to avoid having to include brw_vs.h in
geometry-shader-specific files.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The patch that follows will move the definition of struct
brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for
brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct
brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since
brw_vs.h is included from C source files, that means that brw_vec4.h
will need to be safe to include from C. Same for brw_shader.h, since
it is included by brw_vec4.h.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is backwards from what we are going to want in the long term, which is:
- brw_vec4.h declares general-purpose vec4 infrastructure needed by
both VS and GS
- brw_vs.h includes brw_vec4.h and adds VS-specific parts.
- brw_gs.h includes brw_vec4.h and adds GS-specific parts.
Note that at the moment brw_vec.h contains a fair amount of
VS-specific declarations--I plan to address that in a later patch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Otherwise any GS that requires lowering (e.g. one that uses
gl_ClipDistance as an input or output) will fail to work.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This patch extracts the following logic from
validate_vertex_shader_executable():
(a) Generate an error if the shader writes to both gl_ClipDistance and
gl_ClipVertex.
(b) Record whether the shader writes to gl_ClipDistance in
gl_shader_program for use by the back-end.
(c) Record the size of gl_ClipDistance in gl_shader_program for use by
transform feedback logic.
And moves it into a function that is shared between vertex and
geometry shaders.
Strictly speaking we only need to have shared logic for (b) and (c)
right now (since (a) only matters in compatibility contexts, and we're
only implementing geometry shaders in core contexts right now). But
the three are closely related enough that it seems sensible to keep
them together.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
enums were being converted twice resulting in incorrect values.
The extra conversion has been removed and the redundant assert is
removed also.
Cc: 9.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Brian Paul <brianp@vmware.com>
The previous value of (GLuint64) ~0 has some problems:
GL_MAX_SERVER_WAIT_TIMEOUT is supposed to be a GLuint64 value, but has
to be queried via GetInteger64v(), which returns a GLint64. This means
that some applications are likely to treat it as a signed integer, where
~0 means -1. Negative values are nonsensical and problematic.
When interpreted correctly, ~0 translates to about 0.58 million years,
which seems rather excessive.
This patch changes it to 0x1fff7fffffff, which is about 1.11 years.
This is still plenty long, and is the same as both an int64 and uint64.
Applications that accidentally store it in a 32-bit int/unsigned also
get a non-negative value, which is again the same as both int and
unsigned. This value was suggested by Ian Romanick.
v2: Add the ULL prefix on the constant (suggested by Ian).
Fixes Piglit's spec/!OpenGL 3.2/get-integer-64v.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
_mesa_meta_begin() sets up an orthographic project and initializes the
viewport based on the current drawbuffer's width and height. This is
likely the window size, since it occurs before the meta operation binds
any temporary buffers.
decompress_texture_image needs the viewport to be the size of the image
it's trying to draw. Otherwise, it may only draw part of the image.
v2: Actually set the projection properly too.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68250
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Mak Nazecic-Andrlon <owlberteinstein@gmail.com>
Fixes inconsistent failure of gles2conform/GL2Tests/glUniform/glUniform.test
under gnome-shell. What follows is a description of the bug and its fix.
When intel_update_renderbuffers() allocates a miptree for a winsys
renderbuffer, it propagates the renderbuffer's format to become also the
miptree's format.
If the winsys color buffer format is SARGB, then, in the first call to
eglMakeCurrent, intel_gles3_srgb_workaround() changes the renderbuffer's
format to ARGB. That is, it changes the format from sRGB to non-sRGB.
However, it changes the renderbuffer's format *after*
intel_update_renderbuffers() has allocated the renderbuffer's miptree.
Therefore, when eglMakeCurrent returns, the miptree format (SARGB)
differs from the renderbuffer format (ARGB).
If the X server reallocates the color buffer,
intel_update_renderbuffers() will create a new miptree for the
renderbuffer. The new miptree's format (ARGB) will differ from old
miptree's format (SARGB). This mismatch between old and new miptrees
causes bugs.
Fix the bug by moving intel_gles3_srgb_workaround() to occur *before*
intel_update_renderbuffers().
CC: "9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67934
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Except for explicit derivs with cube maps which are very bogus anyway.
Just like explicit lod this is only used if no_quad_lod is set in
GALLIVM_DEBUG env var.
Minification is terrible on cpus which don't support true vector shifts
(but should work correctly). Cannot do the min/mag filter decision (if
they are different) per pixel though, only selecting different mip levels
works.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
block size depth is always 1 even for compressed formats (unless someone
invents true 3d compressed formats at least which we can't represent).
Nearest (and soa) path had it right.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We have set up 3DSTATE_SBE (or 3DSTATE_SF on GEN6) in
ilo_shader_select_kernel_routing(). There is no need to pass the last shader
stage to the GPE function.
The Gallium implementation is apparently not ready for regular
consumption, so as much as I hate adding more build-time options, here's
another.
Acked-by: Brian Paul <brianp@vmware.com>
The variable means that UBO qualifiers are allowed in a particular
context (e.g., not allowed in a struct field declaration), rather than a
particular set of UBO qualifiers are valid.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This was invaluable when debugging the global copy propagation
algorithm. We may as well commit it in case someone needs to print
out the sets in the future.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The (complicated!) math is all identical, there's just minimal differences how
sign bit is calculated plus there's an additional subtraction for the argument
going into the polynomial for cos.
The logic stays 100% the same (with a small exception, sign bit calculation for
sin is minimally simplified, applying sign mask after xoring the arguments
instead of applying it to each argument).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
IVB/BYT also has the same L3 cacheability control in MOCS as HSW,
so let's make use of it.
pts/xonotic and pts/reaction @ 1920x1080 gain ~4% on my IVB GT2. Most
other things show less gains/no regressions, except furmark which
loses some 10 points.
I didn't have a BYT at hand for testing.
v2: Don't check (brw->gen == 7) in gen7 functions. (chadv)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Just spotted these unpopulated MOCS fields when comparing the code
against BSpec. Set the MOCS to the same as everywhere else in Haswell:
L3-cacheable.
v2: Annotate state packet fields (chadv).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The NVIDIA driver doesn't expose them, and piglit's
arb_texture_compression-invalid-formats expects them to not be there.
This, with the previous commit, fixes piglit
arb_texture_compression-invalid-formats.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
This is required by the spec, and it's a bit tricky because the default
precision is scoped. As a result, I'm slightly abusing the symbol
table.
Fixes piglit no-default-float-precision.frag tests and the piglit
default-precision-nested-scope-0[1234].frag tests that are currently on
the piglit mailing list for review.
On IRC I got confirmation from cwabbot that ARM (Mali T6xx and T400)
enforces this requirement and from kusma that NVIDIA (Tegra2) enforces
this requirement. We should be safe from regressing shipping
applications.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
We never noticed this before because we previously didn't enfoce GLSL ES
fragement shader requirements that precision be defined. There may also
have been some interaction here with the addition of
GL_ARB_shading_language_420pack, but it doesn't appear to me that it
added any new bugs (just perhaps uncovered some old ones).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Going to need this soon (not going to bother with avx2 intrinsics at this time
but don't want to do workarounds for true vector shifts if llvm itself can use
them just fine and won't need the gazillion instruction emulation).
Not really tested other than my cpu returns 0 for these features...
(I have no idea if llvm actually would emit avx2/xop instructions neither...)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Need to check the wrap mode of the actually used coords not a fixed 2.
While checking more than necessary would only potentially disable aos and
not cause any harm I'm pretty sure for 3d textures it could have caused
assertion failures (if s,t coords have simple filter and r not).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Turns out it is actually very complicated to figure out what a format really
is wrt range, as using channel information for determining unorm/snorm etc.
doesn't work for a bunch of cases - namely compressed, subsampled, other.
Also while here add clamping for uint/sint as well - d3d10 doesn't actually
need this (can only use ld with these formats hence no border) and we could
do this outside the shader for GL easily (due to the fixed texture/sampler
relation) do it here too just so I can forget about it.
v2: move border color clamping out of fetch texel. Also change it to clamp
the whole border vector at once (and use vectorized load of border color),
which saves a couple of instructions - needs some different handling of
mixed signed/unsigned formats so skip the per channel stuff and just derive
this from first channel except for special formats.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
There's a new debug value used to disable per-quad lod optimizations
in fragment shader (ignored for vs/gs as the results are just too wrong
typically). Also trying to detect if a supplied lod value is really a
scalar (if it's coming from immediate or constant file) in which case
sampler code can use this to stay on per-quad-lod path (in fact for
explicit lod could simplify even further and use same lod for both
quads in the avx case but this is not implemented yet).
Still need to actually implement per-element lod bias (and derivatives),
and need to handle per-element lod in size queries.
v2: fix comments, prettify.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The rules were writing files to e.g. util/u_indices_gen.py, but in an
out-of-tree build this directory doesn't exist in the build directory. So,
create the directories just in case.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
The LLVM R600 backend currently always uses separate VGPRs for these.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68162
(Centroid interpolation is identical to center interpolation without
multisampling, so the shader hardware was only pre-loading one set of
interpolation coefficients, and the pixel shader code was using
uninitialized values as the centroid interpolation coefficients)
Cc: mesa-stable@lists.freedesktop.org
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Now that we have the number of samplers available, we don't need to
iterate over all 16. This should be particularly helpful for vertex
shaders.
v2: Use the correct shader program (caught by Paul Berry).
This needs to initialize the exact same set of sampler swizzles as
the actual key setup, or else we end up doing recompiles due to some
being XYZW and others being 0.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The first field of a record in a UBO has the aligment of the record
itself.
Fixes piglit vs-struct-pad, fs-struct-pad, and (with the patch posted to
the piglit list that extends the test) layout-std140.
NOTE: The bit of strangeness with the version of visit_field without the
record_type poitner is because that method is pure virtual in the base
class. The original implementation of the class did this to ensure
derived classes remembered to implement that flavor. Now they can
implement either flavor but not both. I don't know a C++ way to enforce
that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68195
Cc: "9.2 9.1" mesa-stable@lists.freedesktop.org
The outer-most record is passed into the visit_field method for
the first field. In other words, in the following structure:
struct S1 {
vec4 v;
float f;
};
struct S {
S1 s1;
S1 s2;
};
uniform Ubo {
S s;
};
s.s1.v would get record_type = S (because s1.v is the first non-record
field in S), and s.s2.v would get record_type = S1. s.s1.f and s.s2.f
would get record_type = NULL becuase they aren't the first field of
anything.
This new overload isn't used yet, but the next patch will add several
uses.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: "9.2 9.1" mesa-stable@lists.freedesktop.org
For some reason, we didn't use this information even though the VS
backend has computed it (albeit poorly) for ages.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Unlike the FS, the VS backend already computed the binding table size.
However, it did so poorly: after compilation, it looked to see if any
pull constants/textures/UBOs were in use, and set num_surfaces to the
maximum surface index for that category. If the VS only used a single
texture or UBO, this overcounted by quite a bit.
The shader time surface was also noted at state upload time (during
drawing), not at compile time, which is inefficient. I believe it also
had an off by one error.
This patch computes it accurately, while also simplifying the code.
It also renames num_surfaces to binding_table_size, since num_surfaces
wasn't actually the number of surfaces used. For example, a VS that
used one UBO and no other surfaces would have set num_surfaces to
SURF_INDEX_VS_UBO(1) == 18, rather than 1. A bit of a misnomer there.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Computing the minimum size was easy, and done at compile-time for no
extra overhead here. Making the binding table smaller wastes less batch
space.
Adding the CACHE_NEW_WM_PROG dirty bit isn't strictly necessary, since
other atoms depend on it and flag BRW_NEW_SURFACES. However, it's best
to add it for clarity and safety. It shouldn't add any new overhead.
v2: Use binding_table_size, rather than max_surface_index.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
By tracking the maximum surface index used by the shader, we know just
how small we can make the binding table.
Since it depends entirely on the shader program, we can just compute
it once at compile time, rather than at binding table emit time (which
happens during drawing).
v2: Store binding_table_size, rather than max_surface_index, for
consistency with the VS (which needs to be able to represent 0
surfaces).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
SURF_INDEX_DRAW() has been the identity function since the dawn of time,
and both the shader code and binding table upload code relied on that,
simply using X rather than SURF_INDEX_DRAW(X).
Even if that continues to be true, using the macro clarifies the code.
The comment about draw buffers needing to be first in order for
headerless render target writes to work turned out to be wrong; with
this change, SURF_INDEX_DRAW can be changed to arbitrary indices and
everything continues working.
The confusion was over the "Render Target Index" field in the FB write
message header. If it were a binding table index, then RT 0 would have
to be at index 0 for headerless FB writes to work. However, it's
actually an index into the blend state table, so there's no problem.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Paul Berry <stereotype441@gmail.com>
Now that we have the number of samplers available, we don't need to
iterate over all 16. This should be particularly helpful for vertex
shaders.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Previously, we computed sampler counts when generating the SAMPLER_STATE
table. By computing it earlier, we should be able to shorten a bunch of
loops.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This allows us to avoid uploading the VS sampler state table if only the
fragment program changes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Now, each shader stage has a sampler state table that only refers to the
samplers actually used by that problem. This should make the VS table
non-existant or very small.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Also upload separate sampler default/texture border color entries.
At the moment, this is completely idiotic: both tables contain exactly
the same contents, so we're simply wasting batch space and CPU time.
However, soon we'll only upload data for textures actually /used/ in
a particular stage, which will usually make the VS table empty and
very likely eliminate all redundancy. This is just a stepping stone.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Like the previous patch, this simply pushes direct access to brw->wm up
one level in the call chain. Rather than passing the whole array, we
just pass a pointer to the correct spot in the array, similar to what we
do for the actual sampler state structure.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
When we begin uploading separate sampler state tables for VS and FS,
we won't be able to use &brw->wm.sdc_offset[ss_index]. By passing it in
as a parameter, we push the problem up to the caller.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Currently, we only have a single sampler state table shared among all
stages, so we just copy wm.sampler_count into vs.sampler_count.
In the future, each shader stage will have its own SAMPLER_STATE table,
at which point we'll need these separate sampler counts.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
I believe the data flow analysis actually works now, and it should be
safe to re-enable global copy propagation. It even does things now.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Since the initial value for livein is an overestimation (0xffffffff),
it's extremely likely that it will shrink, which means we can't simply
OR in new bits - we need to fully recompute it based on the current
liveout values.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Since we start with an overestimation of livein (0xffffffff), successive
steps can actually take away values. This means we can't simply OR in
new liveout values; we need to recompute it from scratch at each
iteration of the fixed-point algorithm.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The starting block always has livein = 0 and liveout = copy. Since we
start with real data, not estimates, there's no need to refine it with
the fixed point algorithm.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The previous commit properly initialized liveout. This previous
(and incorrect) initialization is no longer necessary.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Previously, livein was initialized to 0 for all blocks. According to
the textbook, it should be the universal set (~0) for all blocks except
the one representing the start of the program (which should be 0).
liveout also needs to be initialized to COPY for the initial block.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
According to page 360 of the textbook, the proper formula for liveout
is:
CPout(n) = COPY(i) union (CPin(i) - KILL(i))
Previously, we omitted COPY.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Excluding the existing liveout bits is a deviation from the textbook
algorithm. The reason for doing so was to determine if the value
changed, which means the fixed-point algorithm needs to run for another
iteration.
The simpler way to do that is to save the value from step (N-1) and
compare it to the new value at step N.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This is the "COPY" set from Muchnick's textbook, which is necessary
to do the dataflow algorithm correctly.
v2: Simplify initialization based on Paul Berry's observation that
out_acp contains exactly what needs to be in the COPY set.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Although this function currently only initializes the KILL set, it will
soon initialize other data flow sets as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
To compute the actual liveout/livein data flow values, we start with
some initial values and apply a fixed-point algorithm until they settle.
Previously, we iterated through all blocks, updating both liveout and
livein together in one pass. This is awkward, since computing livein
for a block requires knowing liveout for all parent blocks. Not all
of those parent blocks may have been processed yet.
This patch separates the two. First, we update liveout for all blocks.
At iteration N of the fixed-point algorithm, this uses livein values
from iteration N-1. Secondly, we update livein for all blocks. At
step N, this uses the liveout information we just computed (in step N).
This ensures each computation has a consistent picture of the data,
rather than seeing an random mix of data from steps N-1 and N depending
on the order of the blocks in the CFG data structure.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This variable indicates that the fixed-point algorithm made changes to
the data at this step, so it needs to run for another iteration.
"progress" seems a nicer name for that.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The fixed-point algorithm needs to run at least once, so a do-while loop
is more natural.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The dataflow analysis used for global copy propagation is severely
broken, and I believe it doesn't actually do anything. Fixing it will
require a lot of changes, each of which might break things.
Once all the fixes land, we can re-enable this.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Any decent compiler will do this for us, although doing this
will make grepping through the code alot easier.
v2: In both mixer and query interface
v3: rebase
Reviewed-by: Christian König <christian.koenig@amd.com> [v1]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Code should loop through and cleanup the three (VL_NUM_COMPONENTS) idct
buffers, rather than doing the first one three times.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Free any allocated memory and return BadAlloc if create_video_buffer()
has failed to create a buffer.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Not seen in the wild yet, but seems like a reasonable thing to do.
[suggested by Christian]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
I was looking into some minor 422 issues/discrepencies I noticed long
ago using vdpau on my rv790.
I noticed that there is code that is halving height rather than width -
422 is full height AFAIK.
Making the changes below doesn't actually make any noticable difference
to what I was looking into.
Maybe there are more but here's three I've found so far
Reviewed-by: Christian König <christian.koenig@amd.com>
We are getting close to the maximum number of BRW_NEW_* bits that can
be stored in brw->state.dirty.brw without overflowing 32 bits, and
geometry shaders are going to add more. Add a STATIC_ASSERT so that
we will be alerted when we need to switch to 64 bits.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we were asserting that each driver specified an NConfigOptions
exactly equal to the number of options they supplied, leading to frequent
bugs when people would forget to adjust the value when adjusting driver
options. Instead, just overallocate the table by a bit and leave sanity
checking to the assert in findOption().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Consistently using a "The ___ driver hook." line at the the top of each
function's comment block makes it easy to see at a glance what function
is being implemented.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This code upload performs batched uploads via a BO. By moving it out to
a separate file, intel_buffer_objects.c only provides the core buffer
object functionality.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
GL_APPLE_object_purgeable creates a mechanism for marking OpenGL objects
as "purgeable" so they can be thrown away when system resources become
scarce. It specifically applies to buffer objects, textures, and
renderbuffers.
The intel_buffer_objects.c file provides core functionality for GL
buffer objects, such as MapBufferRange and CopyBufferSubData. Having
texture and renderbuffer functionality in that file is a bit strange.
The 2010 copyright on the new file is because Chris Wilson first added
this code in January 2010 (commit 755915fa).
v2: Actually remember to call the new dd table setup function.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The surface allocator understands the scanout flag just fine.
This seems to improve performance for Ubuntu Unity on top of st/xorg
and it fixes the cursor.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This started as an attempt to add support for MSAA texture transfers and
MSAA depth-stencil decompression for the DB->CB copy path.
It has gotten a bit out of control, but it's for the greater good.
Some changes do not make much sense, they are there just to make it look
like the other driver.
With a few cosmetic modifications, r600_texture.c can be shared with
a symlink.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This is glBlitFramebuffer support for MSAA surfaces as required by GL 3.0
and texturing as required by GL 3.2 and GL_ARB_texture_multisample.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This is basic MSAA support which should work with most apps.
Some features are missing, those will be implemented by other commits.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It moves all sampler view descriptors to a buffer.
It supports partial resource updates and it can also unbind resources
(required for FMASK texturing).
The buffer contains all sampler view descriptors for one shader stage,
represented as an array. On top of that, there are N arrays in the buffer,
which are used to emulate context registers as implemented by the previous
ASICs (each array is a context).
This uses the RCU synchronization approach to avoid read-after-write hazards
as discussed in the thread:
"radeonsi: add FMASK texture binding slots and resource setup"
CP DMA is used to clear the descriptors at context initialization and to copy
the descriptors from one context to the next.
v2: - use PKT3_DMA_DATA on CIK (I'll test CIK later)
- turn the bool CP DMA parameters into self-explanatory flags
- add a nice simple API for packet emission to radeon_winsys.h
- use 256 contexts, 128 causes texture corruption in openarena
It shouldn't be necessary to call radeon_winsys::cs_flush() from
radeonsi_launch_grid(), because the state tracker is responsible for
flushing the pipeline at the appropriate time. The current behavior is
also wrong, because radeonsi_launch_grid() submits packets to the
compute ring, but when the state tracker calls pipe->flush() everything
is submitted to the graphics ring. This has the potential to create a
race condition.
The downside of removing this flush is that the compute dispatch packets
will be sent to the graphics ring rather than the compute ring.
In the future we will need to come up with a way to detect 'compute'
command streams and submit them to the appropriate ring.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Previously, INTEL_DEBUG=bat would dump messages like:
intel_mipmap_tree.c:1643: Batchbuffer flush with 456b used
This only reported the space used for command packets, and didn't
report any information on the space used for indirect state.
Now it dumps:
intel_context.c:366: Batchbuffer flush with 6128b (pkt) + 4288b (state)
= 10416b (31.8%)
This conveniently shows the breakdown of space used for packets vs.
state, as well as the percentage of batchbuffer space.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We emit these before configuring depth in the normal path, or actually
using the depth buffer in BLORP - we just failed to emit them when
disabling depth altogether.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We emit these before configuring depth in the normal path, or actually
using the depth buffer in BLORP - we just failed to emit them when
disabling depth altogether.
On Sandybridge, this also requires the post_sync_nonzero flush.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, copy propagation would cause bitcast_f2u(abs(float)) to
be performed in a single step, but the application of source modifiers
(abs, neg) happens after type conversion, leading to incorrect results.
That is, for bitcast_f2u(abs(float)) we would in fact generate code to
do abs(bitcast_f2u(float)).
For example, whereas bitcast_f2u(abs(float)) might result in a register
argument such as
(abs)g2.2<0,1,0>UD
v2: Set interfered = true and break in register_coalesce instead of
returning false.
Reviewed-by: Paul Berry <stereoytpe441@gmail.com>
Necessary to avoid combining a bitcast and a modifier into a single
operation. Otherwise if safe, the MOV should be removed by
copy-propagation or register coalescing.
With this and the next patch, there are only four changes in shader-db:
all a single extra instruction. The code does something like
mov a.w, -b.x
and copy propagation doesn't work because it only handles no-op
swizzles. Seems acceptable, given the known limitation of our copy
propagation.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereoytpe441@gmail.com>
Currently single sample scaled blits with GL_LINEAR filter falls
back to meta path. Patch removes this limitation in BLORP engine
and implements single sample scaled blit with bilinear filter.
No piglit, gles3 regressions are observed with this patch on Ivybridge.
V2: Use "sample" message to utilize the linear filtering functionality
built in to hardware.
V3: Define a bool variable (bilinear_filter) to handle the conditions
for GL_LINEAR blits.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
New function clamp_tex_coords() clamps the texture coordinates
to texture boundaries. This function will also be utilized later
for the BLORP implementation of single-sample scaled blit with
bilinear filter.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
When we talk about both multi-sample and single-sample scaled blits,
rect_grid_{x1, y1} are more appropriate variable names as compared
to sample_grid_{x1, y1}. There are no functional changes in this patch.
It just prepares for the BLORP implementation of single-sample scaled
blit with bilinear filter.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This patch fixes a case of framebuffer blitting with renderbuffer
as color attachment and GL_LINEAR filter. Meta implementation of
glBlitFrambuffer() converts source color buffer to a texture and
uses it to do the scaled blitting in to destination buffer. Using
the exact source rectangle to create the texture does incorrect
linear filtering along the edges. This patch makes the changes to
extend the texture edges by one pixel in x, y directions. This
ensures correct linear filtering.
It fixes failing piglit fbo-attachments-blit-scaled-linear test.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
CC: "9.2" <mesa-stable@lists.freedesktop.org>
CC: "9.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
h264/mpeg4 remain disabled for pre-nvc0, there's some minor
bug/difference which causes the decoding to hang after some frames.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
The error code was changed from INVALID_VALUE to INVALID_OPERATION
in OpenGL 3.3. We should also generate an error when size is BGRA
and normalized is FALSE.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Sandybridge is the only platform that supports an IF instruction
with an embedded comparison. In this case, we need to emit a CMP
to go along with the SEL.
Fixes regressions in Piglit's glsl-fs-atan-3, fs-unpackHalf2x16,
fs-faceforward-float-float-float, isinf-and-isnan fs_basic, and
isinf-and-isnan fs_fbo.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68086
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: lu hua <huax.lu@intel.com>
If clipdistance for one of the vertices is nan (or inf) then the
entire primitive should be discarded.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Doing the comparisons pre-filter is highly recommended by OpenGL (and d3d9)
and definitely required by d3d10.
This actually doesn't do it pre-filter but more "in-filter" as otherwise
need to push the comparisons even further down into fetch code and this
also trivially allows using a somewhat cheaper lerp.
Doing it pre-filter would actually have some performance advantage for UNORM
formats (because the comparisons should be done in texture format, we'd only
need to convert the shadow ref coord to texture format once, but in turn would
save converting the per-sample texture values to floats) but this gets a bit
messy as this has implications for border color handling as well (which needs
to be done prior to depth comparisons, hence would also need to convert border
color to texture format too or use some other tricks like doing separate border
color / shadow ref comparison and simply using that result directly when doing
border replacement).
Should make no difference for nearest filtering, and performance for linear
filtering should be mostly the same too (essentially have one more comparison
instruction per sample, and replace the sub/mul/add lerp with a sub/and/and/add
special "lerp" which all in all shouldn't be much of a difference).
v2: get rid of old code completely
Reviewed-by: Zack Rusin <zackr@vmware.com>
E.g. the Source engine seems to always write to gl_ClipVertex, but normally
doesn't enable any GL_CLIP_DISTANCEn states. This change removes some
irrelevant parts from the generated vertex shader code in such cases.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
This is a very well hidden bug found by accident (only the fixed glean
tstencil2 test so far seems to hit it).
We must use new mask with combined s_pass values and orig_mask values
for zpass/zfail stencil ops, otherwise both the sfail op and one of
zpass/zfail op are applied (probably not hit in most tests because
some of the ops tend to be KEEP usually).
Note: this is a candidate for the 9.2 branch.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Should get rid of some float-to-int conversions (with negation).
No piglit regressions (with llvmpipe).
v2: fix bogus formatting spotted by Brian.
Reviewed-by: Brian Paul <brianp@vmware.com>
This also allows people who don't want to install the binary blobs
required for VP2 to still get MPEG decoding.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
There's no need to use a clip flag for NEGW on these gens, so
no reason we can't just enable 8 planes.
V2: - Bump (and document!) MAX_VERTS in the clip code.
- Fix clip flag masks in the clip unit state and in the shader
prolog
- Move this to the end of the series for less breakage.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This does the same thing as we do for triangle clipping -- select the
appropriate source (either dot(hpos,fixed plane) or a clipdistance
slot).
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Nothing in the clipper uses gl_ClipVertex any more, so we don't care
where it is.
V2: Don't bother fishing out the clipvertex offset either.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Soon the dp4 is only going to be used for fixed clip planes.
V2: Remove old inaccurate comment about the behavior of this function;
add a better explanation above.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
V2: - Use the new VS_OPCODE_UNPACK_FLAGS_SIMD4X2 to correctly split the
flags for the two vertices being processed together.
- Don't apply bogus masking of clip flags. The set of plane enables
aren't included in the shader key, and we wouldn't want the
recompiles anyway.
V3: - Tidy up spurious instructions, name temps properly.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
[V2] Reviewed-by: Paul Berry <stereotype441@gmail.com>
Splits the bottom 8 bits of f0.0 for further wrangling
in a SIMD4x2 program. The 4 bits corresponding to the channels in each
program flow are copied to the LSBs of dst.x visible to each flow.
This is useful for working with clipping flags in the VS.
V3: - Fixup immediate types
- Teach scheduler about the hidden dep on flags
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
V2: Reviewed-by: Paul Berry <stereotype441@gmail.com>
We're about to have an instruction that depends on the flags but isn't
predicated. This lays the groundwork.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Previously we had disabled interpolation of the clip distances as a
special case, since they were unused.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We need to produce clip flags for the vertex header on Gen4/5, so
clip plane lowering has to be done before we try to emit the flags/psiz
attribute.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
V2: We don't particularly care where they fall in the VUE map, as long
as they are allocated somewhere, and occupy two contiguous slots. Don't
fiddle with the SF layout at all -- there's no need.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Fixes build error introduced with commit
d1ba1055d9.
CC nouveau_video.lo
nouveau_video.c: In function 'nouveau_screen_get_video_param':
nouveau_video.c:866:33: error: 'screen' undeclared (first use in this function)
nouveau_video.c:866:33: note: each undeclared identifier is reported only once for each function it appear
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
This makes things a bit nicer, and more importantly it fixes an issue
where a "downgraded" array texture (due to view reduced to 1 layer and
addressed with (non-array) samplec instruction) would use the wrong
coord as shadow reference value. (This could also be fixed by passing
target through the sampler interface much the same way as is done for
size queries, might do this eventually anyway.)
And if we'd ever want to support (shadow) cube map arrays, we'd need
5 coords in any case.
v2: fix bugs (texel fetch using wrong layer coord for 1d, shadow tex
using wrong shadow coord for 2d...). Plus need to project the shadow
coord, and just for fun keep projecting the layer coord too.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Instead of passing s,t,r coordinates pass a coord array - the reason is that
I need to pass more coords (in particular for shadow "coord", future will also
need another one for cube map arrays) so just pass them as an array.
Also, to simplify things, use fixed location for the shadow reference value I
want to get rid of the silly "where is the right coord value" game.
Keep old-style however for aos sampling (which is not going to need shadow
coord, though for cube map arrays it still would need fixing).
(Next patch will pass those through using the new arrangement directly from
sampler interface.)
v2: fix up soa split path (unreachable currently but still...)
Reviewed-by: Zack Rusin <zackr@vmware.com>
We need to put border color into texture format color space which
essentially means clamping for non-float, normalized formats (not entirely
sure if we're also meant to quantize the float but it's probably ok not to
do it thankfully).
For OpenGL we could do this easily outside generated code due to the
1:1 sampler/texture correspondence but not for d3d10 which is terrible
(as we recalculate a constant over and over again per shader invocation).
Fortunately border color should be rare enough that we don't care THAT much.
Reviewed-by: Zack Rusin <zackr@vmware.com>
If the fragment shader is null then pixel shader invocations have
to be equal to zero. And if we're running a null ps then clipper
invocations and primitives should be equal to zero but only
if both stancil and depth testing are disabled.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Calling the prepare outputs cleans up the slot assignments
for outputs, unfortunately aapoint and aaline didn't have
code to reset their slots after the initial setup, this
was messing up our slot assignments. The unfilled stage
was just missing the initial assignment of the face slot.
This fixes all of the reported piglit failures.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
In commit 8fc41df (glsl: Modify ir_set_program_inouts to handle
geometry shaders), when attempting to pattern match the "foo" part of
expressions such as:
foo[i][j]
foo[i]
I incorrectly called as_dereference_variable() on the subexpression
foo[i] instead of foo. As a result, the pattern never matched, so
ir_set_program_inouts would fall back on marking the entire variable
as used, rather than just the portion indexed by the array.
This didn't result in incorrect behaviour, but it could have resulted
in inefficiency by causing the back-end to allocate resources for
unused parts of an input or output array.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch adds the level query support to the video decoders
and uses some more reasonable defaults.
v2: (ck) add commit message
Reviewed-by: Christian König <christian.koenig@amd.com>
Previously we would emit a warning for empty declarations like
float;
We would also emit the same warning for things like
highp float;
However, this second case is most likely the application trying to set
the default precision. This makes the compiler generate a stronger
warning with some suggestion of a fix.
It really seems like this should be an error. I'll bet that 100% of the
time someone writes 'highp float;' the actually meant 'precision highp
float;'. Alas, both AMD and NVIDIA accept this syntax, and the spec
doesn't explicitly forbid it.
This makes piglit's precision-05.vert generate the following warnings:
0:12(11): warning: empty declaration with precision qualifier, to set the default precision, use `precision lowp float;'
0:13(12): warning: empty declaration with precision qualifier, to set the default precision, use `precision mediump int;'
v2: Add { } around a one-line if body and fix a comment. Suggested by
Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Previously, we were accidentally calling
handle_geometry_shader_input_decl() on non-input interface block
declarations, resulting in bogus error checking.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, if a geometry shader input was declared as a non-array, we
would flag the proper compiler error, but then before we got a chance
to report it to the client, handle_geometry_shader_input_decl() would
assertion fail.
With this patch, handle_geometry_shader_input_decl() ignores
non-arrays.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Move the arrays to the new header brw_multisample_state.h, which will be
shared with Broadwell code.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Place each array in the brw namespace by renaming it:
sample_positions_4x -> brw_multisample_positions_4x
sample_positions_8x -> brw_multisample_positions_8x
This prepares for moving the arrays to a header shared by gen6 and gen8.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
GLSL ES does not allow unsized arrays, and GLSL ES 1.00 does not allow
array initializers. However, GLSL ES 3.00 allows array initializers,
and the initializer can explicitly size the array. The specification
even includes some examples of this:
float x[] = float[2] (1.0, 2.0); // declares an array of size 2
float y[] = float[] (1.0, 2.0, 3.0); // declares an array of size 3
float a[5];
float b[] = a;
Move the unsized array check to after the initializer has been
processed. If the array is still unsized, generate the error. This
should have no effect in GLSL ES 1.00 because, as previously mentioned,
array initializers are not allowed.
Fixes piglit "glsl-es-3.00 compiler array-sized-by-initializer.vert".
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.1 9.2" <mesa-stable@lists.freedesktop.org>
The functional change is that now invalidate_framebuffer is called if
the texture is actually detached from one of the currently bound FBOs.
Previously this was only done for renderbuffers.
The remaining changes make the texture delete path look more similar to
the renderbuffer delete path. This includes adding relevant spec
quotations to justify the behavior.
Fixes piglit fbo-incomplete "delete texture of bound FBO" test.
v2: Move 'fb->Attachment[i].Texture == att' check from previous patch to
this patch... where it was intended to be in the first place. Noticed
by Chad.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Also add a return value indicating whether any work was done.
This will be used by the next patch.
v2: Move 'fb->Attachment[i].Texture == att' check to the next
patch... where it was intended to be in the first place. Noticed by
Chad.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Looks like the same issue that was seen with MULADD in trans slot on
R7xx also affects MULADD_IEEE (maybe all OP3 instructions and MULADD is
just a most frequently used?). So the workaround is to not allow affected
instructions to be placed into the trans slot.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67927
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
FSEQ/FSGE/FSLT/FSNE work just the same as SEQ/SGE/SLT/SNE except skip the
select.
And just for consistency use the same appropriate ordered/unordered comparisons
for the old opcodes as well.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Also while here add a bunch of other forgotten (integer) instructions to
tgsi_util_get_inst_usage_mask() (which isn't used for much except optimizing
away unused input components), though it may still be incomplete.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Newer graphic languages don't want messy float mask results but instead true
"boolean" mask results for float comparisons. Otherwise just need to convert
the floats back to integers. Need to keep the old opcodes however due to both
legacy (gl and d3d9) needing them and because older hw can't really deal with
integers. These new FSEQ/FSGE/FSLT/FSNE opcodes are part of integer API and
hence must be supported if a driver claims to support glsl 1.30 (or
PIPE_SHADER_CAP_INTEGERS).
Reviewed-by: Zack Rusin <zackr@vmware.com>
Because we must maintain an exec_mask even if there's currently nothing
on the mask stack, we can still have an exec_mask at the end of the program.
Effectively, this mask should be set back to default when returning from main.
Without relying on END/RET opcode (I think it's valid to have neither) it is
actually difficult to do this, as there doesn't seem any reasonable place to
do it, so instead let's just say the exec_mask is invalid outside main (which
it really is effectively).
The problem is that geometry shader called end_primitive outside the shader
(in the epilogue), and as a result used a bogus mask, leading to bugs if we
had to set the (somewhat misnamed) ret_in_main bit anywhere. So just avoid
the mask combining function when called from outside the shader.
Reviewed-by: Zack Rusin <zackr@vmware.com>
The code was quite weird, the second comparison was in fact a complete no-op
and we can also do the comparison with the vector directly instead of scalar,
which should not also be faster but it is way more obvious how that mask
is actually going to look like.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Instead of reducing masks to 0/1 simply use the mask directly as -1.
Also use some signed comparison instead of unsigned (as far as I understand
these values have to be (very) small and signed means llvm doesn't have to
apply additional logic to do the unsigned comparisons the cpu can't do).
Saves a couple of instructions in some test geometry shader here.
v2: that was a bit to much optimization, don't skip combining the masks...
Reviewed-by: Zack Rusin <zackr@vmware.com>
CMP instructions use BRW_ARF_NULL as a destination. Prior to this
patch, dump_instruction() decoded the destination as "???".
Now it decodes BRW_ARF_NULL as "(null)" and other ARFs numerically.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This resulted in printouts like:
246: cmp.cmod.f0.0
???, vgrf152, 0.000000f, (null),
With this patch, CMP is properly printed on one line.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Many GLSL shaders contain code of the form:
x = condition ? foo : bar
The compiler emits an ir_if tree for this, since each subexpression
might be a complex tree that could have side-effects and short-circuit
logic operations.
However, the common case is to simply pick one of two constants or
variable's values---which is exactly what SEL is for. Replacing IF/ELSE
with SEL also simplifies the control flow graph, making optimization
passes which work on basic blocks more effective.
The shader-db statistics:
total instructions in shared programs: 1655247 -> 1503234 (-9.18%)
instructions in affected programs: 949188 -> 797175 (-16.02%)
2,970 shaders were helped, none hurt. Gained 181 SIMD16 programs.
This helps Valve's Source Engine games (max -41.33%), The Cave
(max -33.33%), Serious Sam 3 (max -18.64%), Yo Frankie! (max -30.19%),
Zen Bound (max -22.22%), GStreamer (max -6.12%), and GLBenchmark 2.7
(max -1.94%).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The instruction
(+f0.0) SEL dst, src0, src1
will write either src0 or src1 to dst, depending on the predicate.
Unlike most predicated instructions, it always writes to dst.
fs_inst::is_partial_write() is supposed to return true if the whole
register is guaranteed to be written. The !inst->predicated check makes
sense for most instructions, which might not write the whole register,
but SEL is a special case.
This caused live interval analysis to ignore the destination of
predicated SEL instructions when computing "def" information.
Requires the previous commit to avoid regressions.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The existing inst->is_partial_write() already disallows predicated
instructions, so this has no functional change. However, it's worth
doing explicitly since the CSE pass does not consider the flag register.
This means it could blindly factor out operations that use the same
sources, but which have different condition codes set.
This prevents a regression in the next commit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Usually, the driver creates both 8-wide and 16-wide variants of every
fragment shader. When 16-wide compilation fails, it logs a performance
warning explaining why only an 8-wide program exists.
However, when there are pull parameters, the driver won't even bother
trying the 16-wide compile (since it would fail). In this case, it
failed to emit a performance warning, leaving no explanation for the
missing 16-wide program.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fix ilo_gpe_init_view_surface_for_buffer to allow buffer to be NULL, and add
ilo_gpe_set_view_surface_bo to set it later. This allows us to set up
SURFACE_STATE early for constant buffers backed by user buffers.
In finalize_index_buffer(), when the current index buffer was destroyed due to
u_upload_data(), it may happen that the new index buffer is at the same
address as the old one. Comparing the pointers to the two buffers could fail
to work, and 3DSTATE_INDEX_BUFFER would be incorrectly skipped.
Holding a reference to the current index buffer before calling u_upload_data()
should fix the problem.
Makes this flag appear in the output for INTEL_DEBUG=state
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
INTEL_DEBUG=vue now emits a listing of each slot in the VUE map,
and the corresponding interpolation mode.
V2: Fix whitespace issues.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
My previous attempt at doing so double-failed miserably (minification of
zero still gives one, and even if it would not the value was never written
anyway).
While here also rename the confusingly named int_vec bld as we have int vecs
of different sizes, and rename need_nr_mips (as this also changes out-of-bounds
behavior) to is_sviewinfo too.
Reviewed-by: Zack Rusin <zackr@vmware.com>
d3d10 has no notion of distinct array resources neither at the resource nor
sampler view level. However, shader dcl of resources certainly has, and
d3d10 expects resinfo to return the values according to that - in particular
a resource might have been a 1d texture with some array layers, then the
sampler view might have only used 1 layer so it can be accessed both as 1d
or 1d array texture (I think - the former definitely works). resinfo of a
resource decleared as array needs to return number of array layers but
non-array resource needs to return 0 (and not 1). Hence fix this by passing
the target from the shader decl to emit_size_query and use that (in case of
OpenGL the target will come from the instruction itself).
Could probably do the same for actual sampling, though it may not matter there
(as the bogus components will essentially get clamped away), possibly could
wreak havoc though if it REALLY doesn't match (which is of course an error
but still).
Reviewed-by: Zack Rusin <zackr@vmware.com>
Specifically, must return 0 for non-existent mip levels (and non-existent
textures which is an unsolved problem) for everything but total mip count.
Reviewed-by: Zack Rusin <zackr@vmware.com>
GLSL 1.50 incorporates the functionality of the
ARB_fragment_coord_conventions extension, so we need to make this
functionality available even if the extension isn't enabled.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
From section E.1 (Profiles and Deprecated Features of OpenGL 3.0)
of the OpenGL 3.0 spec:
"LineWidth is not deprecated, but values greater than 1.0
will generate an INVALID VALUE error"
From context it is clear that values greater than 1.0 should only
generate an INVALID VALUE error in a forward-compatible context.
The code was correctly quoting this spec text, but it was disallowing
all line widths in forward-compatible contexts, instead of just widths
greater than 1.0.
This patch introduces the correct check, so that setting a line width
of 1.0 or less is permitted.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We can't be injecting the primitive id's in the pipeline because
by that time the primitives have already been decomposed. To
properly number the primitives we need to handle the adjacency
primitives by hand. This patch moves the prim id injection into
the original primitive assembler and completely removes the
useless pipeline stage.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Without reseting the vertex id, with primitives where the same
vertex is used with different primitives (e.g. tri/lines strips)
our vbuf module won't re-emit those vertices with the changed
primitive id. So lets reset the vertex id whenever injecting
new primitive id to make sure that the vertex data is correctly
emitted.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Before inserting new front face and prim id outputs cleanup
the old extra outputs, otherwise our cache will use previous
output slots which will break as soon as outputs of the current
shader don't match the last.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
libEGL was incorrectly exporting *all* symbols, public and private.
This patch adds -fvisibility=hidden to libEGL's linker flags to ensure
that only symbols annotated with __attribute__((visibility("default")))
get exported.
Sanity-checked with libEGL's builtin DRI2 driver and the i965 DRI driver
by running Piglit on X/EGL and by running weston-gears on Weston as an
X client.
Sanity-checked with libEGL's Gallium driver (which is not built-in) and
the swrast Gallium driver by running es2gears_x11.
Kristian reviewed the symbol diff in `nm libEGL.so`.
CC: "9.2" <mesa-stable@lists.freedesktop.org>
CC: Ian Romanick <idr@freedesktop.org>
Acked-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This is wrong both for OpenGL and d3d. (In fact clamping is a side effect
of converting to depth format, so this should really do quantization too
at least in d3d10 for the comparisons to be truly correct.)
Reviewed-by: Zack Rusin <zackr@vmware.com>
Clearly the returned values need to be per-element if the lod is per element.
Does not actually change behavior yet.
Reviewed-by: Zack Rusin <zackr@vmware.com>
This opcode is quite problematic in tgsi, while it tries to mirror
d3d10 resinfo it can't really do what's stated there due to missing
the crazy return type modifiers. Hence specify this is ignored along
with the swizzle.
(Other options would be to have multiple opcodes or specify the ret
type modifier maybe in dst_reg as there's padding bits left there but
it is the only instruction allowing this.)
Reviewed-by: Zack Rusin <zackr@vmware.com>
For d3d10 and ARB_robust_buffer_access_behavior, we are required to return
0 for out-of-bounds coordinates (for which we can just enable the code already
there was just disabled). Additionally, also need to return 0 for
out-of-bounds mip level and out-of-bounds layer. This changes the logic
so instead of clamping the level/layer, an out-of-bound mask is computed
instead in this case (actual clamping then can be omitted just like with
coordinates, since we set the fetch offset to zero if that happens anyway).
Reviewed-by: Zack Rusin <zackr@vmware.com>
While so far this only causes some harmless test failures, there's lots more
cpus with DAZ. All 64bit capable ones can do it (particularly relevant for
AMD cpus as they supported sse3 very very late) but if really necessary we
can check support for that for real with some more magic.
(In fact just about ANY cpu with sse2 can support DAZ, I believe the only
exception are first gen P4 (Willamette) and from those only early steppings
which can't do it it's almost like intel forgot to add it... - a real pity
though docs say you can't just try to set it as they will throw a GPF.)
While this was meant to address https://bugs.freedesktop.org/show_bug.cgi?id=67672
it does not fix it. Most likely the tests need fixing as I don't think
there's any guarantee about denorm handling in the reference math library
functions if the flags aren't set to standard values. Nevertheless enabling
DAZ on all cpus which can do it should be the right thing to do.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Should be much faster, seems to work in softpipe.
While here (also it's now disabled) fix up the pow factor - the former value
is what is in GL core it is however not actually accurate to fp32 standard
(as it is 1.0/2.4), and if someone would do all the accurate math there's no
reason to waste 8 mantissa bits or so...
v2: use real table generating function instead of just printing the values
(might take a bit longer as it does calculations on some 3+ million floats
but much more descriptive obviously).
Also fix up another inaccurate pow factor (this time in the python code) -
wondering where the couple one bit errors came from :-(.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Since Wayland 1.2, struct wl_buffer and a few functions are deprecated.
References to wl_buffer are replaced with wl_resource and some getter
functions and calls to deprecated functions are replaced with the proper
new API. The latter changes are related to resource versioning.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
A listener is added just after the interface is bound, in
registry_handle_global().
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
The helper provides a series of functions to easy the implementation
of the WL_bind_wayland_display extension on different platforms. But
even with the helpers there was still a bit of duplicated code between
platforms, with the drm authentication being the only part that
differs.
This patch changes the bufmgr interface to provide a self contained
object with a create function that takes a drm authentication callback
as an argument. That way all the helper functions are made static and
the "_helper" suffix was removed from the sources file name.
This change also removes the mix of Wayland client and server code in
the wayland drm platform source file. All the uses of libwayland-server
are now contained in native_wayland_drm_bufmgr.c.
Changes to the drm platform are only compile tested.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Since llvm -3.4svn r187618, TargetOptions doesn't provide
RealignStack, so only enable it with llvm<3.4
This option must now be specified using function attributes, see LLVM
commit r187618
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
This command reads a value from memory and writes it to a register (the
opposite of MI_STORE_REGISTER_MEM). It's only available on Gen7+.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This prevents a crash in a future patch.
_mesa_initialize_context() creates a default transform feedback object
by calling the NewTransformFeedbackObject() driver hook. Eventually,
we'll want to subclass that and allocate a buffer object. This means
passing brw->bufmgr to drm_intel_alloc_bo(), and crashing if it isn't
initialized yet.
The buffer manager is actually already initialized; we just hadn't
copied the pointer from intel_screen to intel_context quite early
enough.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Gen7+ supports four transform feedback streams. Using a function-like
macro makes it easy to access them by stream number or loop over them.
"GEN7_" prefixes are more common than "_IVB" suffixes, so use that.
Gen6 only supports a single stream, so the single #define should be
fine. However, SO_NUM_PRIM_STORAGE_NEEDED was a poor name. For one,
the word "NUM" doesn't appear in the actual name of the register.
It's also confusingly generic, as it doesn't exist on Gen7+. Add a
"GEN6_" prefix for clarity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Gen7+ supports four transform feedback streams. Using a function-like
macro makes it easy to access them by stream number or loop over them.
"GEN7_" prefixes are more common than "_IVB" suffixes, so we use that.
Gen6 only supports a single stream, so the single #define should be
fine. However, SO_NUM_PRIMS_WRITTEN was confusingly generic, as it
doesn't exist on Gen7+. Add a "GEN6_" prefix for clarity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Previously only the slice of a 3D texture was validated in the FBO
completeness check. This fixes the failure in the 'invalid layer of an
array texture' subtest of piglit's fbo-incomplete test.
v2: 1D_ARRAY textures have Depth == 1. Instead, compare against Height.
v3: Handle CUBE_MAP_ARRAY textures too. Noticed by Marek.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.1 9.2" mesa-stable@lists.freedesktop.org
This fixes the segfault in the 'invalid slice of 3D texture' and
'invalid layer of an array texture' subtests of piglit's fbo-incomplete
test.
The 'invalid layer of an array texture' subtest still fails.
v2: Fix off-by-one comparison error noticed by Chris Forbes. Also,
1D_ARRAY textures have Depth == 1. Instead, compare against Height.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Cc: "9.1 9.2" mesa-stable@lists.freedesktop.org
Allow user-generated names for glBindFramebufferEXT on desktop GL.
Disallow its use altogether for core profiles.
Names bound with glBindFramebuffer in desktop OpenGL are still
(incorrectly) shared across the share group instead of being
per-context. This gets us a bit closer to being strictly conformant.
v2: Disallow glBindFramebufferEXT in 3.1 by not installing it in the
dispatch table. Suggested by Jordan.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [v1]
Cc: mesa-stable@lists.freedesktop.org
Allow user-generated names for glBindRenderbufferEXT on desktop GL.
Disallow its use altogether for core profiles.
v2: Disallow glBindRenderbufferEXT in 3.1 by not installing it in the
dispatch table. Suggested by Jordan.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [v1]
Cc: mesa-stable@lists.freedesktop.org
These are only used on Gen4-5. Why waste the 8kB of space?
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
If gs is null, then freeing state->shader.tokens would result in a null
dereference.
Fixes "Dereference after null check" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Fixes "Uninitialized pointer read" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
unfilled_stage::face_slot is of type int.
Fixes "Unsigned compared against 0" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
pp_free_bos dereferences ppq without a null check.
Fixes "Dereference before null check" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
the issue is that stream output is run before the pipeline, which
means that unless we decompose the primitives before the so
then things crash. we could convert the entire stream output
code into a pipeline stage but it will take a bit, so for now
fix the crashes by simply re-adding the old input assembler
which is run before the SO.
Signed-off-by: Zack Rusin <zackr@vmware.com>
we used to have a face primitive assembler that we ran after if
the gs was missing but we had adjacency primitives in the pipeline,
lets convert it to a pipeline stage, which allows us to use it
to inject outputs (primitive id) into the vertices. it's also
a lot cleaner because the decomposition is already handled for us.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Inject front face only if the fragment shader uses it and
propagate through all channels because otherwise we'll
need to figure out the exact swizzle that the fs expects and
it's just simpler to make sure all the components within
the front face register are correctly set.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Replace "fulldecl->Semantic.Name/Index" with semName/semIndex.
Simplify if/else logic for TGSI_FILE_OUTPUT code.
Remove old comment.
Fix indentation.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Previously we would mark a renderbuffer as needing a depth resolve.
But, to support layered rendering, we need to look at the attachment
instead, since the attachment knows if layered rendering is being
used.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This function is needed to support layered rendering. With
layered rendering, the attachment stores the state of whether
layered rendering is being used.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
When layered rendering is being used, we should not set
FORCE_ZERO_RTAINDEX in the clip state to allow render target
array values other than zero to be used.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This restriction was related to programming the offset fields
of the depth buffer packet. We are now setting these offsets
to 0 now, so this restriction should no longer be required.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Previously we would always find the 2D sub-surface of interest,
and then program the surface to this location. Now we always
program the 3DSTATE_DEPTH_BUFFER at the start of the surface.
To select the lod/slice, we utilize the lod & minimum array
element fields.
As part of this change, we must revert 1f112ccf:
Revert "i965/gen7: Align all depth miplevels to 8 in the X direction."
We also must disable brw_workaround_depthstencil_alignment for
gen >= 7. Now the hardware will handle alignment when rendering
to additional slices/LODs.
v2:
* Merge with recent MOCS changes
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
For gen >= 7, we will use the lod/minimum-array-element fields to
support layered rendering. This means that we must restrict
the depth & stencil attachments to match in various more retrictive
ways. (Now the width, height, depth, LOD and layer must match)
The reason width, height, and depth must match is that the hardware
has a single set of width, height, and depth settings (in
3DSTATE_DEPTH_BUFFER) that affect both the depth and stencil buffers.
Since these controls determine the miptree layout, they need to be
set correctly in order for lod and minimum-array-element to work
properly. So the only way rendering can work is if the width,
height, and depth match.
In the future, if this restriction proves to be a problem (say
because some crucial client application relies on rendering to
different levels/layers of stencil and depth buffers), then we can
always work around the restriction by copying depth and/or stencil
data to a temporary buffer prior to rendering (much in the same way
that brw_workaround_depthstencil_alignment() does today for
gen < 7), but hopefully that won't be necessary.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
When performing hiz ops, we must ensure that the region sizes
have an 8 aligned width and 4 aligned height. We can tweak the
size for blorp hiz operations at LOD 0, but for the others we
can't. Therefore, we disable hiz for these miplevels if they
don't meet the size alignment requirements.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
In a future pass this will allow us to exit-early from this
routine to disable it for gen >= 7.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Some videos specify mb_adaptive_frame_field_flag instead of
field_pic_flag. This implies that the pic height needs to be halved, and
this field needs to be passed to the VP engine.
Cc: "9.2" mesa-stable@lists.freedesktop.org
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
The loop was iterating over all the fs inputs and setting them
to perspective interpolation, then after the loop we were
creating extra output slots with the correct interpolation. Instead
of injecting bogus extra outputs, just set the interpolation
on front face and prim id correctly when doing the initial scan
of fs inputs.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
clipping would drop the extra outputs because it always
used the number of standard vertex shader outputs, without
geometry shader or extra outputs. The commit makes sure
that clipping with geometry shaders which have more outputs
than the current vertex shader and with extra outputs correctly
propagates the entire vertex.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Draw module can decompose primitives into wireframe models, which
is a fancy word for 'lines', unfortunately that decomposition means
that we weren't able to preserve the original front-face info which
could be derived from the original primitives (lines don't have a
'face'). To fix it allow draw module to inject a fake face semantic
into outputs from which the backends can figure out the original
frontfacing info of the primitives.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Draw sometimes injects extra shader outputs (aa points, lines or
front face), unfortunately most of the pipeline and llvm code
didn't handle them at all. It only worked if number of inputs
happened to be bigger or equal to the number of shader outputs
plus the extra injected outputs. In particular when running
the pipeline which depends on the vertex_id in the vertex_header
things were completely broken. The patch adjust the code to
correctly use the total number of shader outputs (the standard
ones plus the injected ones) to make it all stop crashing and
work.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Instead of using the magical 4 use the above computed
vertex size. Doesn't change the behavior, just makes the code
a bit cleaner.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
when dumping shader outputs it's nice to have the integer
values of the outputs, in particular because some values
are integers.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Adding code to detect the usage of prim id and front face
semantics in fragment shaders.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
we forgot to add ucmp to the list of opcodes, so it was never
generated for ureg.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The spec says that front-face is true if the value is >0 and false
if it's <0. To make sure that we follow the spec, lets just
subtract 0.5 from our value (llvmpipe did 1 for frontface and 0
otherwise), which will get us a positive num for frontface and
negative for backface.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We'll need proper values for max_gs_threads when we eventually support
geometry shaders. Also, we initialize it for every other platform.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Commit 2548092ad8 switched the sense of interpolation qualifier
checks in order to permit them on geometry shader in/out variables.
In doing so, it accidentally allowed interpolation qualifiers to be
applied to ordinary variables and function parameters.
Fixes a regression in Piglit's local-smooth-01.frag.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Commit 7cfefe6965 introduced a check for whether linked->Type equals
GL_GEOMETRY_SHADER. However, linked may be NULL due to an earlier error
condition.
Since the entire function after the error path is (or should be) guarded
by linked != NULL checks, we may as well just return early and remove
the checks.
Fixes crashes in 9 Piglit tests.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
v2:
- upon success close the given file descriptors
v3:
- use specific entry for dma buffers instead of the basic for
primes, and enable the extension based on the availability
of the hook
v4 (Chad):
- use ARRAY_SIZE
- improve the comment about the number of file descriptors
- in case of invalid format report EGL_BAD_ATTRIBUTE instead
of EGL_BAD_MATCH
- take into account specific error set by the driver.
v5:
- fix error handling
v6 (Chad):
- fix invalid plane count checking
v7 (Chad):
- fix indentation and reset loop counter before checking
for excess attributes
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Memory originating outside mesa stack is meant to be for reading
only. In addition, the restrictions imposed by the image external
extension should apply. For example, users shouldn't be allowed
to generare mip-trees based on these images.
v2 (Chad): document using full extension names, fix the comment
style itself and emit description of error
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
As specified in:
http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
Checking for the valid fourcc values is left for drivers avoiding
dependency to drm header files here.
v2: enforce EGL_NO_CONTEXT
v3: declare the extension as EGL (not GLES)
v4: do not update eglext.h manually but rely on update from
Khronos instead
v5: (Eric) report invalid context as EGL_BAD_PARAMETER instead of as
EGL_BAD_CONTEXT
v6: (Chad) fix the checking for valid hints. Before all values were
rejected.
v7: (Chad) comment style change from
/**
* Multi-
* line
into
/* Multi-
* line
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
v2: do not break ABI, but instead introduce new entry point for
dma buffers and bump up the dri-interface version to eight
v3 (Chad): allow the hook to specify an error originating from the
driver. For now only unsupported format is considered.
I thought about rejecting the hints also as they are
addressing only YUV sampling which is not supported at
the moment but then thought against it as the spec is
not saying one way or the other.
v4 (Eric, Chad): restrict to rgb formatted only
v5: rebased on top of i915/i965 split
v6 (Chad): document using full extension name
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Geometry shader support in the Mesa front end is still fairly
preliminary. Many features are untested, and the following things are
known not to work:
- The gl_in interface block
- The gl_ClipDistance input
- Transform feedback of geometry shader outputs
- Constants that are new in GLSL 1.50 (e.g. gl_MaxGeometryInputComponents)
This isn't a problem, since no back-end drivers currently enable
geometry shaders. However, to make sure no one gets the wrong
impression, emit a nasty warning to let the user know that geometry
shader support isn't complete.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Section 4.3.8.1 (Input Layout Qualifiers) of the GLSL 1.50 spec
contains some tricky rules for how the sizes of geometry shader input
arrays are related to the input layout specification. In essence,
those rules boil down to the following:
- If an input array declaration does not specify a size, and it
follows an input layout declaration, it is sized according to the
input layout.
- If an input layout declaration follows an input array declaration
that didn't specify a size, the input array declaration is given a
size at the time the input layout declaration appears.
- All input layout declarations and input array sizes must ultimately
match. Inconsistencies are reported as soon as they are detected,
at compile time if the inconsistency is within one compilation unit,
otherwise at link time.
- At least one compilation unit must contain an input layout
declaration.
(Note: the geom_array_resize_visitor class was contributed by Bryan
Cain <bryancain3@gmail.com>.)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
From the GLSL ES 3.00 spec:
"All indexes used to index a uniform block array must be constant
integral expressions."
Similar text exists in GLSL specs since 1.50.
When we implemented this, the only type of interface block supported
by Mesa was uniform blocks, so we required all indexes used to index
any interface block to be constant integral expressions.
Now that we are adding interface block support for GLSL 1.50, we need
a more specific check.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This gets piglit's geometry-basic test running.
TODO: Still need to validate that the GS layout qualifiers don't get used
in places they shouldn't (like an interface block, or a particular shader
input or output)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Next step is to validate them at link time.
v2 (Paul Berry <stereotype441@gmail.com>): Don't attempt to export the
layout qualifiers in the event of a compile error, since some of them
are set up by ast_to_hir(), and ast_to_hir() isn't guaranteed to have
run in the event of a compile error.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v3 (Paul Berry <stereotype441@gmail.com>): Use PRIM_UNKNOWN to
represent "not set in this shader".
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Limited semantic checking (compatibility between declarations, checking
that they're in the right shader target, etc.) is done.
v2: Remove stray debug printfs.
v3 (Paul Berry <stereotype441@gmail.com>): Process input layout
qualifiers at ast_to_hir time rather than at parse time, since certain
error conditions depend on the relative ordering between input layout
qualifiers, declarations, and calls to .length().
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We do some tests of qualifiers using a union containing an int and the
struct full of bitfields, so make sure the bitfields don't spill
outside the int.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
From section 2.15 (Geometry Shaders) the OpenGL 3.2 spec:
A program object that includes a geometry shader must also include
a vertex shader; otherwise a link error will occur.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
ARB_geometry_shader4 spec Errors:
"The error INVALID_VALUE is generated by ProgramParameteriARB if <pname>
is GEOMETRY_VERTICES_OUT_ARB and <value> is negative."
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In geometry shaders, outputs are consumed at the time of a call to
EmitVertex() (as opposed to all other shader types, where outputs are
consumed when the shader exits). Therefore, when packing geometry
shader output varyings using lower_packed_varyings, we need to do the
packing at the time of the EmitVertex() call.
This patch accomplishes that by adding a new visitor class,
lower_packed_varyings_gs_splicer, which is responsible for splicing
the varying packing code into place wherever EmitVertex() is found.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch modifies lower_packed_varyings to store the packing code it
generates in a temporary exec_list, and then splice that list into the
shader's main() function when it's done. This paves the way for
supporting geometry shader outputs, where we'll have to splice a clone
of the packing code before every call to EmitVertex().
As a side benefit, varying packing code is now emitted in the same
order for inputs and outputs; this should make debug output a little
easier to read.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since geometry shader inputs are arrays (where the array index
indicates which vertex is being examined), varying packing needs to
treat them differently.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From section 4.3.4 (Inputs) of the GLSL 1.50 spec:
Geometry shader input variables get the per-vertex values written
out by vertex shader output variables of the same names. Since a
geometry shader operates on a set of vertices, each input varying
variable (or input block, see interface blocks below) needs to be
declared as an array.
Therefore, the element type of each geometry shader input array should
match the type of the corresponding vertex shader output.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The documentation for gl_shader_program.Geom and gl_geometry_program
says that the former is copied to the latter at link time, but this
wasn't happening. This patch causes _mesa_ir_link_shader() to perform
the copy, and updates comment accordingly.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch creates a single function to copy the the UsesClipDistance
flag from gl_shader_program.Vert to gl_vertex_program. Previously
this logic was duplicated in the i965-specific function
brw_link_shader() and the core mesa function _mesa_ir_link_shader().
This logic will have to be expanded to support geometry shaders, and I
don't want to have to update it in two separate places.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This commit adds all of the parsing and semantics for GLSL 150 style
geometry shaders.
v2 (Paul Berry <stereotype441@gmail.com>): Add a few missing calls to
get_pipeline_stage(). Fix some signed/unsigned comparison warnings.
Fix handling of NULL consumer in assign_varying_locations().
v3 (Bryan Cain <bryancain3@gmail.com>): fix indexing order of 2D
arrays. Also, allow interpolation qualifiers in geometry shaders.
v4 (Paul Berry <stereotype441@gmail.com>): Eliminate
get_pipeline_stage()--it is no longer needed thanks to 030ca23 (mesa:
renumber shader indices according to their placement in pipeline).
Remove 2D stuff. Move vertices_per_prim() to ir.h, so that it will be
accessible from outside the linker. Remove
inject_num_vertices_visitor. Rework for GLSL 1.50.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v5 (Paul Berry <stereotype441@gmail.com>): Split out
do_set_program_inouts() argument refactoring to a separate patch.
Move geom_array_resizing_visitor to later in the series.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There's no reason to be clever about this. By making separate
allocations for vertex and fragment shaders, we'll allow geometry
shaders to be added without introducing any complication.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (Paul Berry <stereotype441@gmail.com>): Account for rework of
builtin_variables.cpp. Use INTERP_QUALIFIER_FLAT for gl_PrimitiveID
so that it will obey provoking vertex conventions. Convert to GLSL
1.50 style geometry shaders.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v3 (Paul Berry <stereotype441@gmail.com>): Be less obscure about
setting interpolation field of gl_Primitive variables.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These correspond to the EmitVertex and EndPrimitive functions in GLSL.
v2 (Paul Berry <stereotype441@gmail.com>): Add stub implementations of
new pure visitor functions to i965's vec4_visitor and fs_visitor
classes.
v3 (Paul Berry <stereotype441@gmail.com>): Rename classes to be more
consistent with the names used in the GL spec.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we assumed that the only way Mesa would expose geometry
shader support was via the ARB_geometry_shader4 extension. But this
extension has some extra complications over GL 3.2 (interactions with
compatibility-only features, and link-time initialization of the
constant gl_VerticesIn). So we want to allow for the possibility of
supporting GL 3.2 (with GLSL 1.50 style geometry shaders) even if
ctx->Extensions.ARB_geometry_shader4 is false.
This patch adds a new function, _mesa_has_geometry_shaders(), which
returns true if either ARB_geometry_shader4 is supported or the GL
version is at least 3.2 desktop. Since compute_version() only enables
GL 3.2 functionality when GLSL 1.50 support is present, a sufficient
way for a back-end to advertise geometry shader support is to set
ctx->Const.GLSLVersion >= 150.
v2: Remove unnecessary ctx->Const.GeometryShaders150 constant.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We can't just use a ".glsl" file since the Lod variants are only
available in vertex and geometry shaders, while the bias variants are
only available in the fragment shader.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Commit 586b4b5 (glsl: Also update implicit sizes of varyings at link
time) extended update_array_sizes() to apply to both uniforms and
shader ins/outs. However, doing creates problems for geometry
shaders, because update_array_sizes() assumes that variables with
matching names in different parts of the pipeline should have the same
sizes. With the addition of geometry shaders, this is no longer true
(e.g. both vertex and geometry shaders have a gl_ClipDistance output
variable, but there's no reason these variables should have the same
sizes).
The original reason for commit 586b4b5 (avoid problems with
gl_TexCoord being 0 length) has since been addressed by commit 6f53921
(linker: Ensure that unsized arrays have a size after linking). So go
ahead and switch update_array_sizes() back to only acting on uniforms.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
According to GLSL, indexing into an array or matrix with an
out-of-range constant results in a compile error. However, indexing
with an out-of-range value that isn't constant merely results in
undefined results.
Since optimization passes (e.g. loop unrolling) can convert
non-constant array indices into constant array indices, it's possible
that ir_set_program_inouts will encounter a constant array index that
is out of range; if this happens, just mark the whole array as used.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The code in ir_set_program_inouts that marks just a portion of a
variable as used (rather than the whole variable) only works on a few
kinds of indexing operations:
- Indexing into matrices
- Indexing into arrays of matrices, vectors, or scalars.
Fortunately these are the only kinds of indexing operations that we
expect to see; everything else is either handled by a
previously-executed lowering pass or prohibited by GLSL.
However, that could conceivably change in the future (the GLSL rules
might change, or we might modify the lowering passes). To avoid
mysterious bugs in the future, let's have ir_set_program_inouts report
an assertion failure if it ever encounters an unexpected kind of
indexing operation (and in release builds, fall back to just marking
the whole variable as used).
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch extracts the functions mark_whole_variable() and
try_mark_partial_variable() from the ir_set_program_inouts visitor
functions. This will make the code easier to follow when we add
geometry shader support.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Our previous justification for leaving this function out of glsl_type
was that it implemented counting rules that were specific to GLSL
1.50. However, these counting rules also describe the number of
varying slots that Mesa will assign to a varying in the absence of
varying packing. That's useful to be able to compute from outside of
the linker code (a future patch will use it from
ir_set_program_inouts.cpp). So go ahead and move it to glsl_type.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will allow us to add geometry shader support without having to
add another boolean argument.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
llvm shifts are undefined for shift counts exceeding (or matching) bit width,
so need to apply a mask for the tgsi shift instructions.
v2: only use mask for the tgsi shift instructions, not for the build shift
helpers. None of the internal callers need this behavior, and while llvm can
optimize away the masking for constants there are legitimate cases where it
might not be able to do so even if we know that shift count must be smaller
than type width (currently all such callers do not use the build shift
helpers).
Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
c shifts are undefined for shift counts exceeding (or matching) bit width,
so need to apply a mask (on x86 it actually would usually probably work as
shifts do masking on int domain shifts - unless some auto-vectorizer would
come along at last as simd domain does not mask the shift count).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Previously, nothing was said what happens with shift counts exceeding
bit width of the values to shift. In theory 3 behaviors are possible:
1) undefined (classic c definition)
2) just shift out all bits (so result is zero, or -1 potentially for ashr)
3) mask the shift count to bit width - 1
API's either require 3) or are ok with 1). In particular, GLSL (as well as a
couple uninteresting legacy GL extensions) is happy with undefined, whereas
both OpenCL and d3d10 require 3). Consequently, most hw also implements 3).
So, for simplicity we just specify that 3) is required rather than saying
undefined and then needing state trackers to work around it.
Also while here specify shift count as a vector, not scalar. As far as I
can tell this was a doc bug, neither state trackers nor drivers used scalar
shift count.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This hasn't done anything in a long time, and it's only used in a couple
places...which means we couldn't use it without doing a bunch of work
anyway.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Previously, if TEXTURE_IMMUTABLE_FORMAT was TRUE, the levels were allowed to
be set like usual, but ARB_texture_storage states:
> if TEXTURE_IMMUTABLE_FORMAT is TRUE, then level_base is clamped to the range
> [0, <levels> - 1] and level_max is then clamped to the range [level_base,
> <levels> - 1], where <levels> is the parameter passed the call to
> TexStorage* for the texture object
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Corey Richardson <corey@octayn.net>
This patch ensures that integers will pass through unscathed. Doing
(useless) computations on them is risky, especially when their bit
patterns correspond to values like inf or nan.
[V1-2]: Signed-off-by: Olivier Galibert <galibert at pobox.com>
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Adds support for interpolating noperspective varyings linearly in screen
space when clipping.
Based on Olivier Galibert's patch from last year:
http://lists.freedesktop.org/archives/mesa-dev/2012-July/024341.html
At this point all -fixed and -vertex interpolation tests work.
V5: Add brw_clip_compile.has_noperspective_shading rather than another
key flag.
V6: Real bools.
[V1-2]: Signed-off-by: Olivier Galibert <galibert at pobox.com>
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously we only gave special treatment to the builtin color varyings.
This patch adds support for arbitrary flat-shaded varyings, which is
required for GLSL 1.30.
Based on Olivier Galibert's patch from last year:
http://lists.freedesktop.org/archives/mesa-dev/2012-July/024340.html
V5: Move key.do_flat_shading to brw_clip_compile.has_flat_shading
V6: Real bools.
[V1-2]: Signed-off-by: Olivier Galibert <galibert at pobox.com>
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously the SF only handled the builtin color varying specially.
This patch generalizes that support to cover user-defined varyings,
driven by the interpolation mode array set up alongside the VUE map.
Based on the following patches from Olivier Galibert:
- http://lists.freedesktop.org/archives/mesa-dev/2012-July/024335.html
- http://lists.freedesktop.org/archives/mesa-dev/2012-July/024339.html
With this patch, all the GLSL 1.3 interpolation tests that do not clip
(spec/glsl-1.30/execution/interpolation/*-none.shader_test) pass.
V5: Move key.do_flat_shading to brw_sf_compile.has_flat_shading; drop
vestigial hunks.
V6: Real bools.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The interpolation map (in brw->interpolation_mode) is a new auxiliary
structure alongside the post-GS VUE map, which describes the
interpolation modes for each VUE slot, for use by the clip and SF
stages.
This patch introduces a new state atom to compute the interpolation map,
and adjusts the program keys for the clip and SF stages, but it is not
actually used yet.
[V1-2]: Signed-off-by: Olivier Galibert <galibert at pobox.com>
V3: Updated for vue_map changes, intel -> brw merge, etc. (Chris Forbes)
V4: Compute interpolation map as a new state atom rather than tacking it
on the front of the clip setup
V5: Rework commit message, make interpolation_mode_map a struct.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We recently proposed a new syntax for stable-patch nominations such as:
CC: "9.2 and 9.1" <mesa-stable@lists.freedesktop.org>
and this has already appeared in the wild.
So we extend the regular expression to pick this up as well.
MP_TEMP_SIZE must be aligned to 0x8000, while TEMP_SIZE on NVE4_3D
must be aligned to 0x20000, so perform both alignments to be sure
we allocate enough space (actually the bo will most likely use 128
KiB pages and not aligning to that would be a waste anyway).
Cc: "9.2" mesa-stable@lists.freedesktop.org
YYLEX_PARAM is no longer supported as of Bison 3.0. Instead, the Bison
developers recommend using %lex-param.
%lex-param takes a type and variable name, similar to %parse-param,
so you can't pass an arbitrary expression like state->scanner. But Flex
insists on passing the actual scanner object, not an arbitrary object
like state.
To solve this, the parser defines a wrapper lex() function which accepts
"state," and calls Flex's lex() function with state->scanner.
Fixes the build with Bison 3.0. Also works with Bison 2.7.1.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Cc: "9.2" mesa-stable@lists.freedesktop.org
YYLEX_PARAM is no longer supported as of Bison 3.0. Instead, the Bison
developers recommend using %lex-param.
%lex-param takes a type and variable name, similar to %parse-param,
so you can't pass an arbitrary expression like state->scanner. But Flex
insists on passing the actual scanner object, not an arbitrary object
like state.
To solve this, the parser defines a wrapper lex() function which accepts
"state," and calls Flex's lex() function with state->scanner.
Fixes the build with Bison 3.0. Also works with Bison 2.7.1.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Cc: "9.2" mesa-stable@lists.freedesktop.org
I had removed it in commit 1e7776ca2b
because it was obviously wrong -- why do we care whether the server is a
version that emits events, if we're not watching for the server's events,
anyway? And why would you only invalidate on a server that emits
invalidate events, when the comment said to emit invalidates if the server
*doesn't*? Only, I missed that we otherwise don't flag that our buffers
might have changed at swap time at all, so the driver was only checking
for new buffers when triggered by the Viewport hack. Of course you don't
expect Viewport to be called after a swap.
So, this is effectively a revert of the previous commit, except that I
dropped the check for only emitting invalidates on a new server -- we
*always* need to invalidate if we're doing a SwapBuffers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63435
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.1 and 9.2" <mesa-stable@lists.freedesktop.org>
Previously we were using truncation, which gives the correct result
only for numbers in [0.5-1.0] range (because there's no mantissa bits
to do any rounding there).
This is frequently hit (and probably only used there) when converting
fragment depth to depth format (d24s8 etc.) or otherwise dealing with
depth format.
v2: as spotted by Jose, get rid of extra type (src_type is already unsigned).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The code that checks if some texture target is valid for
glGetTexLevelParameter*() was not programmed to check for multisampling
proxy textures. This made it impossible(?) to use the proxy textures
for their intended purpose as glGetTexLevelParameter*() would just fail
on you.
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: mesa-stable@lists.freedesktop.org
glTexStorage*() functions make textures immutable. This carries on to
proxy textures. Error checking in texture storage functions prevents
proxy textures from working after first time because internally, they
became immutable.
This commit makes the error checking ignore the immutability flag when
working with proxy textures.
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: mesa-stable@lists.freedesktop.org
When working with the glTexStorage*() functions, the error checking
checks that a non-default (i.e., non-zero) texture is currently bound.
However, this check made glTexStorage*() functions fail with proxy
textures when the default texture is bound. Proxy textures do not care
about the current texture bindings so for them this check should not
be done.
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: mesa-stable@lists.freedesktop.org
The function _mesa_get_tex_max_num_levels() is supposed to calculate
the number of mipmap levels but it was not written to handle proxy
textures, at best returning a maximum of 1 mipmap level. Because of
this, at least glTexStorage*() calls would incorrectly fail when used
with proxy textures with more than one mipmap level.
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: mesa-stable@lists.freedesktop.org
Free all our temporary buffers in one place at the end of the
function. Fixes memory leak detected by Coverity.
Note: This is a candidate for the 9.x branches
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The variable 'usage' was being used for two different things.
Sometimes for PIPE_USAGE_x and other times for PIPE_TRANSFER_x.
This renames usage to access when we're talking about PIPE_TRANSFER_x
flags. Plus, add a bunch of comments to remind us what's going on.
Also, use unsigned for PIPE_TRANSFER_x bitmask to be consistent with
other places. And add a missing const qualifier.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We should probably be using map()/unmap() when accessing resource
data, but this is a little better.
v2: assert that the resource is not a display target, per Jose.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This was never a problem since the Mesa state tracker always gives
us a user-space constant buffer with buffer_offset=0. But if another
state tracker ever gave us a "HW" constant buffer with non-zero
buffer_offset we'd mis-render.
Also, use the correct buffer size. And move an assertion to the
top of the function.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The cap means _can_ accept user-space constant buffers; it doesn't
mean _only_ accepts user-space constant buffers.
v2: also update the PIPE_CAP_USER_VERTEX_BUFFERS and
PIPE_CAP_USER_INDEX_BUFFERS descriptions as well. Per Jose.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
vblank_mode is read by dri_util.c and falls under the "dri2" driver name,
which is not connected to the actual Mesa/Gallium driver in any way.
Reviewed-by: Brian Paul <brianp@vmware.com>
PP saves current states to cso_context and then util_blit_pixels does
the same. cso_context doesn't like that and the original state is not
correctly restored.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
Surprisingly all drivers supporting MSAA can already do this (r300g and r600g
for sure) and I think Christoph wanted to have this feature for his Nouveau
drivers anyway.
We recently adopted a new convention that patches can be nominated for the
stable branch by including a line in the commit message as follows:
CC: mesa-stable@lists.freedesktop.org
This is a convenient syntax as "git send-email" will notice this line and
automatically copy the resulting patch email to the mesa-stable mailing list.
Here we extend the regular expression in the get-pick-list.sh script to also
notice this pattern, (as well as the traditional "NOTE: This patch is a
candidate..." form.
The linker_error() function sets prog->LinkStatus to false. There's
no reason for the caller of linker_error() to also do so.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We're now emitting this error from a point where we have easy access
to the name of the block that failed to match, so go ahead and include
that in the error message, as we do for intrastage interface block
mismatches.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch changes link_shaders() so that it sets prog->LinkStatus to
true when it starts, and then relies on linker_error() to set it to
false if a link failure occurs.
Previously, link_shaders() would set prog->LinkStatus to true halfway
through its execution; as a result, linker functions that executed
during the first half of link_shaders() would have to do their own
success/failure tracking; if they didn't, then calling linker_error()
would add an error message to the log, but not cause the link to fail.
Since it wasn't always obvious from looking at a linker function
whether it was called before or after link_shaders() set
prog->LinkStatus to true, this carried a high risk of bugs.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously we failed to link (which is correct), but we did not output
an error message, which could have been confusing for users.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
A comment in link_intrastage_shaders(), and an if-test that followed
it, seemed to indicate that link_uniform_blocks() would return a
negative value in the event of an error. But this is not the
case--all error checking has already been performed by
validate_intrastage_interface_blocks(), and link_uniform_blocks() can
only return unsigned values.
So get rid of the if-test and change the return type of
link_intrastage_shaders() to clarify that it can only return unsigned
values.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
To have non-static buffers in local memory, it is necessary to pass them
as arguments to the kernel.
For r600, the correct lds size must be set to the SQ_LDS_ALLOC register.
The correct size is the clover size plus the size reported by the
compiler.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Here is an updated patch with no line wrapping and respecting 80-column limit (for my changes).
v2: Tom Stellard
- Create global arguments for constant buffers so we don't break
r600g.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
For GLSL programs, enabledTargets can have more than one bit set. For
example, a shader that uses sampler2D and samplerCube uniforms will have
both TEXTURE_2D_BIT and TEXTURE_CUBE_BIT set.
The code that sets _ReallyEnabled already handles this, selecting the
"highest priority" texture target. We should simply use that.
Fixes new Piglit test incomplete-textures-of-multiple-types.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62698
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Rather than having to keep track of all the build systems and their respecitve
definition of the mesa version, use a single top file VERSION. Every build
system is responsible for reading/parsing the file and using it
v2:
* remove useless bulletpoint from the documentation, suggested by Matt
* "Androing is Linux. Use '/' in stead of '\'", spotted by Chad V
* use cleaner code to get the version in scons, suggested by Chad V
v3:
* ensure leading and trailing whitespace characters are stripped while parsing
* android: handle GNU shell commands approapriately
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
We already skip this for API_OPENGL_CORE; ES2+ is very similar.
The primary user of the swrast context is GL_SELECT and GL_FEEDBACK,
which have never existed in ES.
This saves approximately 18MB of memory in GLBenchmark 2.7 Egypt (ES2).
No regressions in es3conform on Ivybridge.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Certain extensions only add functionality to particular shader stages.
(For example, ARB_draw_instanced only adds variables to the vertex
shader stage.)
Previously, we only allowed such extensions to be enabled in the shader
stages where they're useful. However, I've never found any text which
mandates that behavior; in my opinion, you should be able to turn on
extensions in any shader stage, even if they have no effect.
Fixes Piglit tests glslparsertest/glsl2/draw_buffers-05.vert and
ARB_draw_instanced/preprocessor/feature-macro-enabled.frag.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29185
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
EGL_KHR_surfaceless_context extension allows contexts to be made current
without a default winsys fbo. This extension specifies what ES 1.1 and
2.0 should do (the ES 3.0 spec already does).
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Commit 8c3d3622d9 introduced a new assertion,
but since it causes lp_test_conv failures remove it again and let's hope
we don't really hit bugs caused by the potentially bogus code (it is possible
the assert() caught some cases which work correctly too).
The second 'const' says that the pointer itself is constant. This in
unenforcible in C++, so GCC emits a warning (see) below for each of
these functions in every file that includes glsl_types.h. It's a lot of
warning spam.
../../../src/glsl/glsl_types.h:176:58: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
The majority of calls to _mesa_glsl_error(), _mesa_glsl_warning(), and
_mesa_glsl_parse_state::check_version() use a message that begins with
a lower case letter and ends without a period. This patch makes all
messages follow that convention.
Also, error/warning messages shouldn't end in '\n', since
_mesa_glsl_msg() automatically adds '\n' at the end of the message.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Just like the UNORM case we need to use round to nearest, not trunc.
(There's also another problem, we're using the formula for SNORM->float
which will produce a value below -1.0 for the most negative value which
according to both OpenGL and d3d10 would need clamping. However, no actual
failures have been observed due to that hence keep cheating on that.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
I am not able to find _any_ rounding behavior specified for OpenGL for
float to half-float conversions. However, it is specified for fp11/fp10
which suggests round to next finite value but round-to-zero would also
be allowed, but finite values must not be flushed to infinity in either
case.
Hence I believe it makes sense to do the same for half-floats too.
We could probably also use round-to-zero consistently, which is in fact
required by d3d10 (but it doesn't seem to matter much).
Does not match the mesa core function doing the same though (which is
saying it was built to match intel gpus which I don't believe for a
second as it would cause failures in d3d10, moreover the PRM (for
ivy bridge, not listed in older manuals) while not specifying rounding
behavior clearly states finite numbers are never flushed to infinity).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
unlike OpenGL, the texel swizzle is embedded in the instruction, so honor
that.
(Technically we now execute both the sampler_view swizzle and the
per-instruction swizzle but this should be quite ok.)
v2: add documentation note as it's not obvious.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
GL_EXT_framebuffer_object differs from GL_ARB_framebuffer_object in ways
that we can't and don't implement in core profiles. Exposing it is a
lie, so we shouldn't do that.
It's possible the some other GL_EXT_framebuffer_* extensions should be
disabled, but it's not quite so clear cut.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If any component used the ZERO or ONE swizzle, its corresponding member
in the `swizzle` array would never be initialized. We *mostly* got away
with this, except when that memory happened to contain a value that
clobbered another channel when combined using BRW_SWIZZLE4().
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes the dri2 opening to check if DRI_PRIME is set,
and picks the correct drm device path to open, this along
with a change to libvdpau allows vdpauinfo to work at least,
Martin Peres tested with nouveau, and there seems to be a
further issue with final displaying, it only works sometimes,
but this patch is at least necessary to help debug further.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67283
Tested-by: Armin K. <krejzi@email.com>
This reverts commit c9db037dc9.
Eric believes that the viewport hacks are still necessary for EGL;
invalidate events aren't hooked up properly.
This commit caused a regression where EFL applications wouldn't show
anything other than window decorations; GLBenchmark also showed issues.
The revert had conflicts due to the intel_context/brw_context merge.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66606
Cc: mesa-stable@lists.freedesktop.org
Wrapping every character of an email address in <em> looks bizarre, and
makes it impossible to read the text. Apparently Brian did this in 2003
to try and obfuscate email addresses and avoid spam.
Of course, mesa-*@lists.freedesktop.org are public mailing lists and
trivial to find on the internet. So obfuscation buys us nothing
(assuming the <em> technique even works at all, which I doubt).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
LOLed-at-by: Matt Turner :)
Bump major version, as the change to require explicit
xa_context_flush(), the addition of the handle-type parameter to
xa_surface_handle(), and change of surface to ref/unref will require a
minor change in DDX.
For freedreno DDX, we have to create the scanout GEM bo in a special way
(until we have our own KMS/DRM kernel driver.. and even then for
phones/tablets you probably need to use the android drivers if you don't
want to port the lcd panel driver support). The easiest way to handle
this is let the DDX create the scanout bo, and then create the xa
surface from that.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
TargetOptions::NoFramePointerElimNonLeaf was removed in LLVM 3.4
r187093.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The is_loop_terminator() function was asserting that the following
kind of if statement could never occur:
if (...) { } else { }
(presumably based on the assumption that such an if statement would be
eliminated by previous optimization stages). But that isn't the
case--it's possible that previous optimization stages might simplify
more complex code down to this empty if statement, in which case it
won't be eliminated until the next time through the optimization loop.
So is_loop_terminator() needs to handle it. Fortunately it's easy to
handle--it's not a loop terminator because it does nothing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64330
CC: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Two callers of brw_search_cache() weren't initializing that function's
inout_offset parameter: brw_blorp_const_color_params::get_wm_prog()
and brw_blorp_const_color_params::get_wm_prog().
That's a benign problem, since the only effect of not initializing
inout_offset prior to calling brw_search_cache() is that the bit
corresponding to cache_id in brw->state.dirty.cache may not be set
reliably. This is ok, since the cache_id's used by
brw_blorp_const_color_params::get_wm_prog() and
brw_blorp_blit_params::get_wm_prog() (BRW_BLORP_CONST_COLOR_PROG and
BRW_BLORP_BLIT_PROG, respectively) correspond to dirty bits that are
not used.
However, failing to initialize this parameter causes valgrind to
complain. So let's go ahead and fix it to reduce valgrind noise.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66779
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The linker matches up variables in interface blocks according to their
block name and variable name. When support for interface block arrays
was added in commit d6863acb, we renamed variables appearing in
interface blocks so that their name included the array size. For
example, in a block like this:
out foo {
float bar
} baz[3];
The variable "bar" would get renamed to "bar[3]".
This is unnecessary, and leads to problems in supporting geometry
shaders, since geometry shaders require vertex shader outputs which
are non-arrays to be linked up to geometry shader inputs which are
arrays.
This patch makes the behaviour of interface block arrays the same as
simple non-array interface blocks; in both cases, the variables
contained within them are not renamed.
Reviewed-by: Matt Turner <mattst88@gmail.com>
vertex id has to be unaffected by the start index (i.e. when calling
draw arrays with start_index = 5, the first vertex_id has to still
be 0, not 5) and it has to be equal to the index when performing
indexed rendering (in which case it has to be unaffected by the
index bias). This fixes our behavior.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The instance id system value always starts at 0, even if the
specified start instance is larger than 0. Instead of implicitly
setting instance id to instance id plus start instance and then
having to subtract instance id when computing the buffer offsets
lets just set instance id to the proper instance id. This fixes
instance id computation and cleansup buffer offset computation.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
There are earlier returns for PIPE_FUNC_NEVER and PIPE_FUNC_ALWAYS. The
switch value of 'func' cannot be either of those values.
Fixes "Logically dead code" defects reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Looks like a thinko, "Hey, constant buffers can be at most 64 KiB
in size, offset can't be larger." But it can, of course.
I think piglit lacks a test for UBO and BindBufferRange that
tests if it actually works.
Since disabling denorms in draw_vbo() we require the util_cpu_caps to be
initialized there. Hence add another util_cpu_detect() call in
draw_create_context() which should ensure this.
(There is another call in draw_get_option_use_llvm() which only gets called
with x86 (not x86_64) but calling it always there wouldn't help since it most
likely wouldn't get called when compiling without llvm, so leave it alone
there.)
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=66806.
(Because util_cpu_caps wasn't initialized when first calling util_fpstate_get()
hence it returning zero, but it would later get initialized by rtasm translate
code hence when draw call returned it unmasked all exceptions by calling
util_fpstate_set(). This was happening only with DRAW_USE_LLVM=0 or not
compiling with llvm, otherwise the llvm init code was calling it on time too.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Tested-by: Vinson Lee <vlee@freedesktop.org>
The codeword must be unsigned (otherwise will shift in 1's from above when
merging low/high parts so some texels decode wrong).
This also affects gallium's util/u_format_rgtc.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
supports these extensions, but the OS doesn't, issuing these insns will
trigger an undefined opcode exception.
In addition to the AVX cpuid bit we also need to:
* test cpuid for OSXSAVE support
* XGETBV to check if the OS saves/restores AVX regs on context switches
See "Detecting Availability and Support" at
http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions
Signed-off-by: Andre Heider <a.heider@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Test infs, zeros and nans with our arith functions to assure
correct/defined behavior with those values.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Same as log2_safe, which means that it can handle infs, 0s and
nans.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Only the floating point operarators change everything else
is the same so it makes sense to share the code.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
sin/cos for anything not finite is nan and everything else has
to be between [-1, 1].
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
That means that if input is:
* - less than zero (to and including -inf) then NaN will be returned
* - equal to zero (-denorm, -0, +0 or +denorm), then -inf will be returned
* - +infinity, then +infinity will be returned
* - NaN, then NaN will be returned
It's a separate function because the checks are a little bit costly
and in most cases are likely unnecessary.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
exp(0) has to be exactly 1, exp(-inf) has to be 0, exp(inf) has
to be inf and exp(nan) has to be nan, this fixes all of those
cases.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Both D3D10 and OpenCL say that if one the inputs is nan then
the other should be returned. To preserve that behavior
the patch fixes both the sse and the non-sse paths in both
functions and adds helper code for handling nans.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
It's not the first time that, due to missing build dependencies or
incomplete commits, we end up with a broken libGL.so that's missing
symbols, causing all tests to fail catastrophically.
Instead try to catch this sort of issues earlier.
2013-07-19 13:08:07 +01:00
2517 changed files with 152392 additions and 87432 deletions
<li><ahref="http://www.cs.unc.edu/~olano/papers/2dh-tri/">Triangle Scan Conversion using 2D Homogeneous Coordinates</a></li>
<li><ahref="http://www.drdobbs.com/parallel/rasterization-on-larrabee/217200602">Rasterization on Larrabee</a> (<ahref="http://devmaster.net/posts/2887/rasterization-on-larrabee">DevMaster copy</a>)</li>
<li><ahref="http://devmaster.net/posts/6133/rasterization-using-half-space-functions">Rasterization using half-space functions</a></li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=64323">Bug 64323</a> - Severe misrendering in Left 4 Dead 2</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68838">Bug 68838</a> - GLSL: struct declarations produce a "empty declaration warning" in 9.2</li>
Note: some of the new features are only available with certain drivers.
</p>
<ul>
<li>GL_AMD_seamless_cubemap_per_texture on i965.</li>
<li>GL_ARB_conservative_depth on i965.</li>
<li>GL_ARB_texture_gather on i965.</li>
<li>GL_ARB_texture_query_levels on i965.</li>
<li>GL_ARB_texture_mirror_clamp_to_edge.</li>
<li>GL_ARB_transform_feedback2, GL_ARB_transform_feedback3, and GL_ARB_transform_feedback_instanced on i965/Gen7 (with appropriate kernel support).</li>
<li>GL_ARB_sample_shading on i965.</li>
<li>GL_ARB_shader_atomic_counters on i965.</li>
<li>GL_ARB_vertex_attrib_binding</li>
<li>GL_ARB_vertex_type_10f_11f_11f_rev on i965 and r600g</li>
<li>GL_KHR_debug</li>
<li>GLX_MESA_query_renderer</li>
</ul>
<h2>Bug fixes</h2>
<p>Attempts have been made to <b>not</b> include bugs fixed in previous 9.2
releases or bugs that were regressions during 10.0 development. This list is
likely incomplete.</p>
<ul>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=47755">Bug 47755</a> - [glsl-compiler] no error checking when Interpolation qualifier for built-in variable is different in vertex and fragment shader</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=52171">Bug 52171</a> - [gallium/r600/clover] Simple benchmarks failed to run</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=53077">Bug 53077</a> - [IVB] Output error with msaa when both of framebuffer and source color's alpha are not 1</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=54867">Bug 54867</a> - bug in r300 compiler</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=60929">Bug 60929</a> - [r600-llvm] mono games with opengl are blocking on start</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=62142">Bug 62142</a> - Mesa/demo mipmap_limits upside down with running by SOFTWARE</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66213">Bug 66213</a> - Certain Mesa Demos Rendering Inverted (vertically)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66806">Bug 66806</a> - [softpipe] glxgears floating point exception</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=67921">Bug 67921</a> - [bisected commit 883987] crosscompiling fails with util/u_cpu_detect.c:247:4: error: 'asm' undeclared (first use in this function)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68162">Bug 68162</a> - [radeonsi] texture rendering is broken in Source-Engine games</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68451">Bug 68451</a> - Texture flicker in native Dota2 in mesa 9.2.0rc1</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68503">Bug 68503</a> - Graphical glitches in Serious Sam 3 when SB is enabled</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68792">Bug 68792</a> - Problems during playback of h264 files using UVD and VLC on AMD E-350 CPU</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=70042">Bug 70042</a> - Major texture flickering in Dota 2 (r600g on HD 6950)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=70088">Bug 70088</a> - Glamor on r600g crashes Xserver</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=70123">Bug 70123</a> - Freeze caused by 'winsys/radeon: remove cs_queue_empty' commit</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=70327">Bug 70327</a> - Casting floating point variable to integer not working properly while constant gets converted properly</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=70891">Bug 70891</a> - CL_INVALID_BUILD_OPTIONS results in CL_INVALID_DEVICE when asking for build log</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=71022">Bug 71022</a> - configure: error: Expat required for DRI.</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=71110">Bug 71110</a> - xorg_driver.c:1030:2: error: too many arguments to function ‘DamageUnregister’</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=78225">Bug 78225</a> - Compile error due to undefined reference to `gbm_dri_backend', fix attached</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=78537">Bug 78537</a> - no anisotropic filtering in a native Half-Life 2</li>
</ul>
<h2>Changes</h2>
<p>Brian Paul (1):</p>
<ul>
<li>mesa: fix double-freeing of dispatch tables inside glBegin/End.</li>
</ul>
<p>Carl Worth (3):</p>
<ul>
<li>docs: Add MD5 sums for 10.1.3</li>
<li>cherry-ignore: Roland and Michel agreed to drop these patches.</li>
<li>VERSION: Update to 10.1.4</li>
</ul>
<p>Emil Velikov (1):</p>
<ul>
<li>configure: error out if building GBM without dri</li>
</ul>
<p>Eric Anholt (1):</p>
<ul>
<li>i965/vs: Use samplers for UBOs in the VS like we do for non-UBO pulls.</li>
</ul>
<p>Ilia Mirkin (3):</p>
<ul>
<li>nv50/ir: make sure to reverse cond codes on all the OP_SET variants</li>
<li>nv50: fix setting of texture ms info to be per-stage</li>
<li>nv50/ir: fix integer mul lowering for u32 x u32 -> high u32</li>
</ul>
<p>Michel Dänzer (1):</p>
<ul>
<li>radeonsi: Fix anisotropic filtering state setup</li>
</ul>
<p>Tom Stellard (2):</p>
<ul>
<li>configure.ac: Add LLVM_VERSION_PATCH to DEFINES</li>
<li>radeonsi: Enable geometry shaders with LLVM 3.4.1</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=47824">Bug 47824</a> - osmesa using --enable-shared-glapi depends on libgl</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=62362">Bug 62362</a> - Crash when using Wayland EGL platform</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=63435">Bug 63435</a> - [Regression since 9.0] Flickering in EGL OpenGL full-screen window with swap interval 1</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=64087">Bug 64087</a> - Webgl conformance shader-with-non-reserved-words crash when mesa is compiled without --enable-debug</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=65236">Bug 65236</a> - [i965] Rendering artifacts in VDrift/GL2</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66558">Bug 66558</a> - RS690: 3D artifacts when playing SuperTuxKart</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66847">Bug 66847</a> - compilation broken with llvm 3.3</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66850">Bug 66850</a> - glGenerateMipmap crashes when using GL_TEXTURE_2D_ARRAY with compressed internal format</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66921">Bug 66921</a> - [r300g] Heroes of Newerth: HiZ related corruption</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=67283">Bug 67283</a> - VDPAU doesn't work on hybrid laptop through DRI_PRIME</li>
</ul>
<h2>Changes</h2>
<p>The full set of changes can be viewed by using the following GIT command:</p>
<pre>
git log mesa-9.1.5..mesa-9.1.6
</pre>
<p>Andreas Boll (1):</p>
<ul>
<li>configure.ac: Require llvm-3.2 for r600g/radeonsi llvm backends</li>
</ul>
<p>Brian Paul (4):</p>
<ul>
<li>mesa: handle 2D texture arrays in get_tex_rgba_compressed()</li>
<li>meta: handle 2D texture arrays in decompress_texture_image()</li>
<li>mesa: implement mipmap generation for compressed 2D array textures</li>
<li>mesa: improve free() cleanup in generate_mipmap_compressed()</li>
</ul>
<p>Carl Worth (7):</p>
<ul>
<li>docs: Add 9.1.5 release md5sums</li>
<li>Merge 'origin/9.1' into stable</li>
<li>cherry-ignore: Drop 13 patches from the pick list</li>
<li>get-pick-list.sh: Include commits mentionining "CC: mesa-stable..." in pick list</li>
<li>get-pick-list: Allow for non-whitespace between "CC:" and "mesa-stable"</li>
<li>get-pick-list: Ignore commits which CC mesa-stable unless they say "9.1"</li>
<li>Bump version to 9.1.6</li>
</ul>
<p>Chris Forbes (5):</p>
<ul>
<li>i965/Gen4: Zero extra coordinates for ir_tex</li>
<li>i965/vs: Fix flaky texture swizzling</li>
<li>i965/vs: set up sampler state pointer for Gen4/5.</li>
<li>i965/vs: Put lod parameter in the correct place for Gen4</li>
<li>i965/vs: Gen4/5: enable front colors if back colors are written</li>
</ul>
<p>Christoph Bumiller (1):</p>
<ul>
<li>nv50,nvc0: s/uint16/uint32 for constant buffer offset</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=61635">Bug 61635</a> - glVertexAttribPointer(id, GL_UNSIGNED_BYTE, GL_FALSE,...) does not work</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=65958">Bug 65958</a> - GPU Lockup on Trinity 7500G</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=67548">Bug 67548</a> - glGetAttribLocation seems to be broken</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68195">Bug 68195</a> - piglit tests vs-struct-pad and fs-struct-pad both fail</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68250">Bug 68250</a> - Automatic mipmap generation with texture compression produces borders that fade to black</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66779">Bug 66779</a> - Use of uninitialized stack variable with brw_search_cache()</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68233">Bug 68233</a> - Valgrind errors in mesa</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68250">Bug 68250</a> - Automatic mipmap generation with texture compression produces borders that fade to black</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=53077">Bug 53077</a> - [IVB] Output error with msaa when both of framebuffer and source color's alpha are not 1</li>
<li>Fix freedreno to compile with recent libdrm.</li>
</ul>
<h2>Changes</h2>
<p>The full set of changes can be viewed by using the following GIT command:</p>
<pre>
git log mesa-9.2.3..mesa-9.2.4
</pre>
<p>Brian Paul (1):</p>
<ul>
<li>st/mesa: fix GL_FEEDBACK mode inverted Y coordinate bug</li>
</ul>
<p>Paul Berry (2):</p>
<ul>
<li>i965: Fix vertical alignment for multisampled buffers.</li>
<li>glsl: Fix lowering of direct assignment in lower_clip_distance.</li>
</ul>
<p>Rob Clark (17):</p>
<ul>
<li>freedreno/a3xx: fix color inversion on mem->gmem restore</li>
<li>freedreno/a3xx: fix viewport on gmem->mem resolve</li>
<li>freedreno: add debug option to disable scissor optimization</li>
<li>freedreno: update register headers</li>
<li>freedreno/a3xx: some texture fixes</li>
<li>freedreno/a3xx/compiler: fix CMP</li>
<li>freedreno/a3xx/compiler: handle saturate on dst</li>
<li>freedreno/a3xx/compiler: use max_reg rather than file_count</li>
<li>freedreno/a3xx/compiler: cat4 cannot use const reg as src</li>
<li>freedreno: fix segfault when no color buffer bound</li>
<li>freedreno/a3xx/compiler: make compiler errors more useful</li>
<li>freedreno/a3xx/compiler: bit of re-arrange/cleanup</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=62142">Bug 62142</a> - Mesa/demo mipmap_limits upside down with running by SOFTWARE</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=64323">Bug 64323</a> - Severe misrendering in Left 4 Dead 2</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66213">Bug 66213</a> - Certain Mesa Demos Rendering Inverted (vertically)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=68838">Bug 68838</a> - GLSL: struct declarations produce a "empty declaration warning" in 9.2</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=44618">Bug 44618</a> - Cross-compilation broken by glsl builtin_compiler</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=46632">Bug 46632</a> - Make the alignment checks for the readpixel blit fastpath a bit more lenient</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=47116">Bug 47116</a> - Enemy territory freezes with rs880 and commit fbebd431ec4e2e461a0cbcd5f3a04a000b8f6bbf</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=47248">Bug 47248</a> - autogen missing dependency on flex and bison, causes infinite loop in glsl build</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=50655">Bug 50655</a> - [r600g][RV670 HD3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=51471">Bug 51471</a> - [965gm] Corrupted graphics in corners of screen with pixel shaders enabled</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=51782">Bug 51782</a> - mesa-8.0.3: fails to compile against uclibc</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=58680">Bug 58680</a> - [IVB] Graphical glitches in 0 A.D</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=58872">Bug 58872</a> - Mac OS X configure: error: Couldn't find clock_gettime</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=59322">Bug 59322</a> - r300g MSAA breaks Half-Life 2 in Wine</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=59364">Bug 59364</a> - [bisected] Mesa build fails: clientattrib.c:33:22: fatal error: indirect.h: No such file or directory</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=59439">Bug 59439</a> - glCopyPixels generates no fragments (occlusion_query_meta_fragments test fails)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=59440">Bug 59440</a> - glBitmap generates no fragments (occlusion_query_meta_fragments test fails)</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=60086">Bug 60086</a> - Wayland platform backend crashes if there's no back buffer during dri2_swap_buffers</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=60633">Bug 60633</a> - EXT_texture_sRGB does not work in game The Cave on IvyBridge</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=60737">Bug 60737</a> - In GLSL ES, a missing FS precision qualifier does not generate an error</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=60866">Bug 60866</a> - GLSL performance issues for uniform buffer objects</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=61036">Bug 61036</a> - Shader fails to build in LLVMpipe, aborts program</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=61200">Bug 61200</a> - insufficient linking of libxatracker.so</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=61635">Bug 61635</a> - glVertexAttribPointer(id, GL_UNSIGNED_BYTE, GL_FALSE,...) does not work</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=62466">Bug 62466</a> - r600g hyperz lockups with KSP 0.19</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=62669">Bug 62669</a> - HyperZ freeze when playing PrBoom-Plus demo with lots of monsters</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=62721">Bug 62721</a> - GPU lockup in Minecraft 1.5.1 with HyperZ</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=64959">Bug 64959</a> - Cannot build against EGL without X11</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=65112">Bug 65112</a> - glcpp hangs parsing line continuations</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=65958">Bug 65958</a> - GPU Lockup on Trinity 7500G</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66450">Bug 66450</a> - JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66606">Bug 66606</a> - [i965 bisected]GLBenchmark 2.5.1/2.7.0 sometimes render error with gnome-session enabling SNA</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=66713">Bug 66713</a> - Team Fortress 2 crashes with r600-sb on HD4850</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=67354">Bug 67354</a> - glsl_parser.cpp is broken with bison 3.0</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=67548">Bug 67548</a> - glGetAttribLocation seems to be broken</li>
<li><ahref="https://bugs.freedesktop.org/show_bug.cgi?id=67927">Bug 67927</a> - R600_DEBUG=sb: Celestia show 2 earths, one wrongly rendered</li>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
