These are unnecessary and are likely just left overs from prior
work.
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
On SM20 this gives:
total instructions in shared programs : 6299222 -> 6294240 (-0.08%)
total gprs used in shared programs : 944139 -> 944068 (-0.01%)
total local used in shared programs : 54116 -> 54116 (0.00%)
local gpr inst bytes
helped 0 126 2781 2781
hurt 0 55 11 11
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This way $r1 = $r0 + 4; c1[$r1] becomes c1[$r0+4].
On SM35:
total instructions in shared programs : 6206257 -> 6185058 (-0.34%)
total gprs used in shared programs : 911045 -> 910722 (-0.04%)
total local used in shared programs : 39072 -> 39072 (0.00%)
local gpr inst bytes
helped 0 417 4195 4195
hurt 0 280 0 0
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This works when the add also has an immediate. This often happens in
address calculations. These addresses can then be inlined as well.
On code targeted to SM35:
total instructions in shared programs : 6223346 -> 6206257 (-0.27%)
total gprs used in shared programs : 911075 -> 911045 (-0.00%)
total local used in shared programs : 39072 -> 39072 (0.00%)
local gpr inst bytes
helped 0 119 3664 3664
hurt 0 74 15 15
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Even if the rasterizer has scissor disabled, we'll have whatever
vc4->scissor bounds were last set when someone set up a scissor, so we
shouldn't clip to them in that case.
Fixes piglit fbo-blit-rect, and a lot of MSAA tests once they're enabled.
We could potentially handle scissored blits when they're tile aligned, but
it doesn't seem worth it. If you're doing a scissored blit, you're
probably a testcase.
Fixes piglit's fbo-scissor-blit fbo
This implements more performance metrics than the previous support,
but some other metrics still need to be figured out.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
These performance metrics will be re-introduced in an upcoming
patch that will follow the same design as Fermi.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
inst_issued is performance metric not a hardware event on Kepler (SM30).
It will be re-introduced in an upcoming patch.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
SM30 is the compute capability version for GK104/GK106/GK107.
This also introduces a new signal group selection called UNK0F.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Move these to 'disasm' instead of the more verbose 'optmsgs' since, like
the tgsi dumps, it is useful without the more verbose compiler logging
enabled.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
For MSAA, we store full resolution tile buffer contents, which have their
own tiling format. Since they're full resolution buffers, we have to
align their size to full tiles.
We were checking that the blit started at 0 and was 1:1, but not that it
went to the full width of the surface, or that the width was aligned to a
tile. We then told it to blit to the full width/height of the surface,
causing contents to be stomped in a bunch of MSAA tests that happen to
include half-screen-width blits to 0,0.
I've played with a few different approaches to tweak instruction
priority according to how much they increase/decrease register pressure,
etc. But nothing seems to change the fact that compared to original
(pre-multiple-block-support) scheduler, in some edge cases we are
generating shaders w/ 5-6x higher register usage.
The problem is that the priority queue approach completely looses the
dependency between instructions, and ends up scheduling all paths at the
same time.
Original reason for switching was that recursive approach relied on
starting from the shader outputs array. But we can achieve more or less
the same thing by starting from the depth-sorted list.
shader-db results:
total instructions in shared programs: 113350 -> 105183 (-7.21%)
total dwords in shared programs: 219328 -> 211168 (-3.72%)
total full registers used in shared programs: 7911 -> 7383 (-6.67%)
total half registers used in shader programs: 109 -> 109 (0.00%)
total const registers used in shared programs: 21294 -> 21294 (0.00%)
half full const instr dwords
helped 0 322 0 711 215
hurt 0 163 0 38 4
The shaders hurt tend to gain a register or two. While there are also a
lot of helped shaders that only loose a register or two, the more
complex ones tend to loose significanly more registers used. In some
more extreme cases, like glsl-fs-convolution-1.shader_test it is more
like 7 vs 34 registers!
Signed-off-by: Rob Clark <robclark@freedesktop.org>
It causes confusion in sched if we need to split_addr() since otherwise
we wouldn't easily know which block the new addr instr will be scheduled
in. So just side-step the whole situation.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
We'll need to add similar for ir3_instruction, but following the pattern
to use 'id' seems confusing. Let's just go w/ generic 'data' as the
name.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Undefining the NDEBUG is relevant for release build, as they are the
ones that set it.
[Emil Velikov: split from previous patch]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This follows the src/util/u_atomic_test.c model of undefining NDEBUG
unconditionally throughouth the XvMC tests, to force asserts regardless
of debug mode.
The comment on u_atomic_test.c is also fixed (read 'debug' where it
should have been 'release').
v2: s/debug/release/ in relevant comments
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
[Emil Velikov: keep the src/util/ hunk as separate patch]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Add missing `const` specifier for pointer pointing to a const struct.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Should have been part of commit f53f9eb8d4 "glapi: add GetPointervKHR
to the ES dispatch".
v2: comment out the ES1.1 symbol and use the same description (pattern)
as elsewhere (Matt)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93235
Fixes: f53f9eb8d4 "glapi: add GetPointervKHR to the ES dispatch".
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Vinson Lee <vlee@freedesktop.org> (v1)
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Since we're using nir_lower_outputs_to_temporaries to shadow all our
outputs, it's impossible to actually get an indirect store. The code we
had to "handle" this was pretty bogus as it created a register with a
reladdr and then stuffed it in a fixed varying slot without so much as a
MOV. Not only does this not do the MOV, it also puts the indirect on the
wrong side of the transaction. Let's just delete the broken dead code.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It's not really buying us anything at this point. It's just a way of
remapping one offset namespace onto another. We can just use the location
namespace the whole way through.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The original change to put zeroes directly into instructions created
conditional mov's with the zero immediate. However that can't be
emitted, so make sure to replace the zero with r63.
Fixes: 52a800a68 (nv50/ir: allow immediate 0 to be loaded anywhere)
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
A situation where there's a 128-bit load where the last component gets
DCE'd causes a 96-bit load to be generated, which no GPU can actually
emit. Avoid generating such instructions by scaling back to 64-bit on
the first load when splitting.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
This was just plain broken. It used always the value from v0 (for vp_index)
but would pass the value from the provoking vertex to later stages - but only
if there was a corresponding fs input, otherwise the layer/vp index would get
lost completely (as it would try to interpolate the (unsigned) values as
floats).
So, make it obey provoking vertex rules (drivers relying on draw will need to
do the same). And make sure that the default interpolation mode (when no
corresponding fs input is found) for them is constant.
Also, change the code a bit so constant inputs aren't interpolated then
copied over later.
Fixes the new piglit test gl-layer-render-clipped.
v2: more consistent whitespaces fixes for function defs, and more tab killing
(overall still not quite right however).
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Same as for llvmpipe, albeit softpipe only really handles multiple layers,
not multiple viewports/scissors.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
d3d10 actually requires using provoking (first) vertex. GL is happy with
any vertex (as long as we say it's undefined in the corresponding queries).
Up to now we actually used vertex 0 for viewport index, and vertex 1 for
layer (for tris), which really didn't make sense (probably a typo). Also,$
since we reorder vertices of clockwise triangle, that actually meant we used
a different vertex depending if the traingle was cw or ccw (still ok by gl).
However, it should be consistent with what draw (clip) does, and using
provoking vertex seems like the sensible choice (draw clip will be fixed
next as it is totally broken there).
While here, also use the correct viewport always even when not needed
in setup (we pass it down to jit fragment shader it might be needed there
for getting correct near/far depth values).
No piglit changes.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We can't dump it in the real driver, since the kernel doesn't give us a
handle to it (except after a GPU hang, using a root ioctl). In the
simulator we can.
No need to dereference again, fixup for clarity.
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
It should be MSVC2008_COMPAT_CFLAGS and not MSVC2008_COMPAT_CXXFLAGS.
This is why the recent util_blitter breakage went unnoticed on autotools
builds.
Trivial.
nir is the exception among gallium/auxiliary -- we don't need to compile
it with MSVC2008 yet. And this enables us to use
-Werror=declaration-after-statement in the next commit as we should,
without complicated fixes to tgsi_to_nir module.
Trvial. Tested with GCC and Clang.
Currently it stores strlen(buf) whenever the user originally provided a
negative value for length.
Although I've not seen any explicit text in the spec, CTS requires that
the very same length (be that negative value or not) is returned back on
Pop.
So let's push down the length < 0 checks, tweak the meaning of
gl_debug_message::length and fix GetDebugMessageLog to add and count the
null terminators, as required by the spec.
v2: return correct total length in GetDebugMessageLog
v3: rebase (drop _mesa_shader_debug hunk).
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We're about to rework the meaning of gl_debug_message::length to only
store the user provided data. Thus we should add an explicit validation
for null terminated strings.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
These new (relative to ARB_debug_output) tokens, have been explicitly
separated from the existing ones in the spec text. With the reference
to glDebugMessageInsert was dropped.
At the same time, further down the spec says:
"The value of <type> must be one of the values from Table 5.4"
... and these two are listed in Table 5.4.
The GL 4.3 and GLES 3.2 do not give any hints on the former
'definition', plus CTS requires that the tokens are valid values for
glDebugMessageInsert.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
As per the spec quote:
"All messages are initially enabled unless their assigned severity
is DEBUG_SEVERITY_LOW"
We already had MEDIUM and HIGH set, let's toggle NOTIFICATION as well.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We already have one group (the default) as specified in the spec. So
lets return its size, rather than the index of the current group.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The variable is used as the actual index, rather than the size of the
group stack - rename it to reflect that.
Suggested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The extension requires (cough implements) GetPointervKHR (alias of
GetPointerv) which in itself is available for ES 1.1 enabled mesa.
Anyone willing to fish around and implement it for ES 1.0 is more than
welcome to revert this commit. Until then lets restrict things.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93048
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The KHR_debug extension implements this.
Strictly speaking it could be used with ES 1.0, although as the original
function is available on ES 1.1, I'm inclined to lift the KHR_debug
requirement to ES 1.1.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93048
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Commit a16ffb743c, which introduced
gl_extensions::Version, updates the field when the context version
is computed and when entering/exiting meta. Update this field when
the version is overridden as well.
Cc: "11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
There are a few legacy OpenGL apps on Windows which need this extension.
We basically use glCopyTex[Sub]Image to implement wglBindTexImageARB (see
the implementation notes for details).
v2: refactor code to use st_copy_framebuffer_to_texture() helper function.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
This helper is used by the WGL state tracker to implement the
wglBindTexImageARB() function.
This is basically a new "meta" function. However, we're not putting
it in the src/mesa/drivers/common/ directory because that code is not
linked with gallium-based drivers.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
match_explicit_outputs_to_inputs() cannot get null inputs and if it ever did
triggering first null check would later in the function cause segfault.
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
CC: timothy.arceri@collabora.com
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Atomic counters and Images were using ctx::Shader that does not take in
to account program pipeline changes, ctx::_Shader must be used for SSO to
work. Commit c0347705 already changed ubo's to use this.
Fixes failures seen with following Piglit test:
arb_separate_shader_object-atomic-counter
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Noticed this when looking at a trace that caused flags to spill to/from
registers. The flags source/destination wasn't encoded correctly
according to both envydis and nvdisasm.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
For example if it's $r63 (aka 0), there won't be a definition.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
The algorithm expects the entire CFG to be reachable, so make sure that
we hit every node. Otherwise we will end up with uninitialized data,
memory corruption, etc.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
For example if there are only returns, the break bb will not end up part
of the CFG. However there will have been a prebreak already emitted for
it, and when hitting the RET that comes after, we will try to insert the
current (i.e. break) BB into the graph even though it will be
unreachable. This makes the SSA code sad.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
SM20-SM50 can't emit a post-factor in the presence of a long immediate.
Make sure to fold it in.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
There's a post-RA fixup to replace 0's with $r63 (or $r127 if too many
regs are used), so just as nvc0, let an immediate 0 be loaded anywhere.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Surprisingly, this didn't exist at all.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This appeared in brw_vs.c and brw_wm.c, should have appeared in
brw_gs.c, and was soon going to have to be in brw_tcs.c and brw_tes.c as
well.
So, instead, move it to a central location (which has to know about both
struct brw_context and perf_debug()).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
That texture mask thing doesn't seem to be needed for surface ops, so
just as nve4+, let do that only for texture ops.
This fixes a segfault with 'test_surface_st' from
gallium/tests/trivial/compute.c on Fermi because this test uses sustp.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Previously util_blitter_clear_depth_stencil() could not clear more
than the first layer. We need to generalise this as we did for
util_blitter_clear_render_target().
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Previously util_blitter_clear_render_target() could not clear more
than the first layer. We need to generalise this so that
ARB_clear_texture can pass the 3d piglit test.
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
These are implementation-dependent queries, but so far we just returned the
value of whatever the current provoking vertex convention was set to, which
was clearly wrong.
Just make this a variable in the context constants like for other things
which are implementation dependent (I assume all drivers will want to set
this to the same value for both queries), and set it to GL_UNDEFINED_VERTEX
which is correct for everybody (and drivers can override it).
Reviewed-by: Brian Paul <brianp@vmware.com>
CC: <mesa-stable@lists.freedesktop.org>
The NVIDIA binary driver and Intel's closed source driver both expose
14 here, rather than the GL minimum of 12. Let's follow suit.
Without this, Shadow of Mordor fails to render correctly and triggers
OpenGL errors:
Mesa: User error: GL_INVALID_VALUE in glBindBufferBase(index=68)
Mesa: User error: GL_INVALID_VALUE in glUniformBlockBinding(block binding 68 >= 60)
There are 5 stages (VS, TCS, TES, GS, FS), and 12 * 5 = 60 is too small.
14 * 5 = 70 will work just fine.
Tapani believes this will also help Alien Isolation.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
The first pass marked dead instructions as opcode = NOP, and a second
pass deleted those instructions so that the live ranges used in the
first pass wouldn't change.
But since we're walking the instructions in reverse order, we can just
do everything in one pass. The only thing we have to do is walk the
blocks in reverse as well.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Removes dead code from glsl-mat-from-int-ctor-03.shader_test.
Reported-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The docs say we should send the emit after the ring writes,
so lets do that and not have an ALU in between.
Signed-off-by: Dave Airlie <airlied@redhat.com>
streamout, gs rings bug on certain r600s, requires a wait idle
before each surface sync.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: "10.6 11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to insert a SQ_NON_EVENT when ever geometry
shaders are enabled.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: "10.6 11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For the compute support, we might stick buffers as surfaces. This fixes
an assertion when executing src/gallium/tests/trivial/compute.
To avoid using these "restricted" surfaces as render targets, these
assertions have been moved. Note that it's already handled for the
framebuffer thing on nvc0.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
String literals cannot exceed 65535 characters for MSVC. Instead of
emiting a string, emit an array of characters.
v2: fix indentation and add comment in the gl_enums.py file about this
ugliness.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now when people need new extensions, they can skip the entire
enum-definition process, and we can stop reviewing new extension XML for
its enum content.
This also brings in a new enum that I wanted to use in enum_strings.cpp
for testing the code generator.
v2: Drop comment about disabled GL_1PASS_EXT test.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
With GLES 3.1, GL 4.5, and many new vendor extensions about to get their
enums added, we jump up to 85k of table.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Sometimes GL likes to rename an old enum when it grows a more general
purpose, and we should prefer the new name. Changes from this:
GL_POINT/LINE_SIZE_* (1.1) -> GL_SMOOTH_POINT/LINE_SIZE_* (1.2)
GL_FOG_COORDINATE_* (1.4) -> GL_FOG_COORD_* (1.5)
GL_SOURCE[012]_RGB/ALPHA (1.3) -> GL_SRC0_RGB (1.5)
GL_COPY_READ/WRITE_BUFFER (3.1) -> GL_COPY_READ_BUFFER_BINDING (4.2)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Asking the table for bitfield names doesn't make any sense. For 0x10, do
you want GL_GLYPH_HORIZONTAL_BEARING_ADVANCE_BIT_NV or
GL_COLOR_BUFFER_BIT4_QCOM or GL_POLYGON_STIPPLE_BIT or
GL_SHADER_GLOBAL_ACCESS_BARRIER_BIT_NV? Giving a useful answer would
depend on a whole lot of context.
This also fixes a bad enum table entry, where we chose GL_HINT_BIT instead
of GL_ABGR_EXT for 0x8000, so we can now fix its entry in the enum_strings
test.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I've used a bunch of python code to cut out new enums so that the two
generated files can be diffed. I'll remove all that hardcoding in the
following commits. All remaining differences between the generated code:
- GL_TEXTURE_BUFFER_FORMAT didn't appear in GL3 when TBOs got merged to
core, so it now gets an _ARB suffix instead.
- Blacklisting can't keep EXT_sso's GL_ACTIVE_PROGRAM_EXT from becoming
GL_ACTIVE_PROGRAM -- in our hash table, GL_ACTIVE_PROGRAM_EXT points at
the GLES2 enum's value (aka GL_CURRENT_PROGRAM). By not blacklisting
the core name, we get both enums translated.
- GL_DRAW_FRAMEBUFFER_BINDING and GL_FRAMEBUFFER_BINDING both appeared in
GL3 as synonyms, and the new code happens to choose
GL_FRAMEBUFFER_BINDING instead.
- GL_TEXTURE_COMPONENTS and GL_TEXTURE_INTERNAL_FORMAT both appear in 1.1,
and the new code chooses GL_TEXTURE_INTERNAL_FORMAT instead (which seems
better, to me)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
emacs whines at me every time I open the file about these unsafe
variables, and the file was reformatted from 8 space to 4 space long ago.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
GL_ALL_ATTRIB_BITS is a thing, and GL_CLIENT_ALL_ATTRIB_BITS, but I don't
see GL_ALL_CLIENT_ATTRIB_BITS in my grepping of khronos XML, GL extension
specs, GL 1.1, GL 2.2, and GL 4.4.
Reviewed-by: Brian Paul <brianp@vmware.com>
Mesa hasn't been using these enums and the finalized specs don't reference
them, so losing them from our generated enum-to-string code should be
fine. Reduces diffs to generating from Khronos XML, which has these enums
noted defined but commented out from any consumers.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
In converting to using the Khronos XML, I found that our XML had these two
swapped, and the text spec agreed.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The intention here is to keep a pristine copy of the upstream gl.xml that
can be updated at any time with a new version, and use that to generate
Mesa code from instead of our private XML.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The previous contents appeared to be the output of some form of code
generation for all enums, with a few entries hand-edited to deal with
oddness. The downside to this was that when an enum gets promoted from
vendor to _EXT or _EXT to _ARB or _ARB to core, make check starts failing
even when the commiter has done nothing wrong. Instead of black-box
testing the code generation, pick a few enums that intentionally poke the
interesting cases of code generation.
People editing the code generator should be diffing the generated code
anyway. This should catch when they fail to do so, without throwing false
negatives when people update the GL XML.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
When probing for devices, clover will call pipe_loader_probe() twice.
The first time to retrieve the number of devices, and then second time
to retrieve the device structures.
We currently assume that the return value of both calls will be the
same, but this will not be the case if a device happens to disappear
between the two calls.
When a device disappears, the pipe_loader_probe() will add a NULL
device to the device list, so we need to handle this.
v2:
- Keep range for loop
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
Correct some occurrences of -ldl and -lpthread to use
$(DLOPEN_LIBS) and $(PTHREAD_LIBS) respectively.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Improves register pressure, since otherwise we end up emitting
loads for all the elements in the RHS and them emitting
stores for all elements in the LHS.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Improves register pressure, since otherwise we end up emitting
loads for all the elements in the RHS and them emitting
stores for all elements in the LHS.
v2:
- Mark progress properly. This also fixes some instances where the added
nodes with individual element copies where not being lowered, which is
expected behavior as explained in the documentation for
visit_list_elements.
- Only need to do this if the RHS is a buffer-backed variable.
- We can also have arrays inside structs. A later patch will make it so
we also split struct copies and end up with multiple
ir_dereference_record assignments, so make sure that if any of these
is an array copy, we also split it.
Fixes the following piglit tests:
tests/spec/arb_shader_storage_buffer_object/execution/large-field-copy.shader_test
tests/spec/arb_shader_storage_buffer_object/linker/copy-large-array.shader_test
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Other hardwares than AMD require to parse:
VAPictureParameterBufferH264.ReferenceFrames[16]
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
In general max_references cannot be based on num_render_targets.
This patch allows to allocate buffers with an accurate size.
I.e. no more than necessary. For other codecs it is a fixed
value 2.
This is similar behaviour as vaapi/vdpau-driver.
For now HEVC case defaults to num_render_targets as before.
But it could also benefits this change by setting a more
accurate max_references number in handlePictureParameterBuffer.
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
The current implementation looks for array dereferences on gl_FragData and
immediately proceeds to lower them, however this is not enough because we
can have array access on vector variables too, like in this code:
out vec4 color;
void main()
{
int i;
for (i = 0; i < 4; i++)
color[i] = 1.0;
}
Fix it by making sure that the actual variable being dereferenced is an array.
Fixes a crash in:
spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-ldexp-dvec4.shader_test
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
We need to emit at least one cut/emit in every
geometry shader, the easiest workaround it to
stick a single CUT at the top of each geom shader.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: "10.6 11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is specified in the docs for rv670 to work properly.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: "10.6 11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On some chips the GSVS itemsize needs to be aligned to a cacheline size.
This only applies to some of the r600 family chips.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: "10.6 11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes an issue where the addition of the FLAT qualifier in
varying_matches::record() can break the expected varying order.
It also avoids a future issue with the relaxing of interpolation
qualifier matching constraints in GLSL 4.50.
V2: (by Timothy Arceri)
* reworked comment slightly
Signed-off-by: Gregory Hainaut <gregory.hainaut@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
GL_ARB_separate_shader_objects allow matching by name variable or block
interface. Input varyings can't be removed because it is will impact the
location assignment.
This fixes the bug 79783 and likely any application that uses
GL_ARB_separate_shader_objects extension.
V2 (by Timothy Arceri):
* simplify now that builtins are not set as always active
Signed-off-by: Gregory Hainaut <gregory.hainaut@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
https://bugs.freedesktop.org/show_bug.cgi?id=79783
The value will be set in separate-shader program when an input/output
must remains active. e.g. when deadcode removal isn't allowed because
it will create interface location/name-matching mismatch.
v3:
* Rename the attribute
* Use ir_variable directly instead of ir_variable_refcount_visitor
* Move the foreach IR code in the linker file
v4:
* Fix variable name in assert
v5 (by Timothy Arceri):
* Rename functions and reword comments
* Don't set always active on builtins
Signed-off-by: Gregory Hainaut <gregory.hainaut@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
This change allows used defined inputs/outputs with explicit locations
to be removed if they are detected to not be used between shaders
at link time.
To enable this we change the is_unmatched_generic_inout field to be
flagged when we have a user defined varying. Previously
explicit_location was assumed to be set only in builtins however SSO
allows the user to set an explicit location.
We then add a function to match explicit locations between shaders.
V2: call match_explicit_outputs_to_inputs() after
is_unmatched_generic_inout has been initialised.
Cc: Gregory Hainaut <gregory.hainaut@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
When working on tessellation shaders, I created some vec4 virtual
opcodes for creating message headers through a sequence like:
mov(8) g7<1>UD 0x00000000UD { align1 WE_all 1Q compacted };
mov(1) g7.5<1>UD 0x00000100UD { align1 WE_all };
mov(1) g7<1>UD g0<0,1,0>UD { align1 WE_all compacted };
mov(1) g7.3<1>UD g8<0,1,0>UD { align1 WE_all };
This is done in the generator since the vec4 backend can't handle align1
regioning. From the visitor's point of view, this is a single opcode:
hs_set_output_urb_offsets vgrf7.0:UD, 1U, vgrf8.xxxx:UD
Normally, there's no hazard between sources and destinations - an
instruction (naturally) reads its sources, then writes the result to the
destination. However, when the virtual instruction generates multiple
hardware instructions, we can get into trouble.
In the above example, if the register allocator assigned vgrf7 and vgrf8
to the same hardware register, then we'd clobber the source with 0 in
the first instruction, and read back the wrong value in the last one.
It occured to me that this is exactly the same problem we have with
SIMD16 instructions that use W/UW or B/UB types with 0 stride. The
hardware implicitly decodes them as two SIMD8 instructions, and with
the overlapping regions, the first would clobber the second.
Previously, we handled that by incrementing the live range end IP by 1,
which works, but is excessive: the next instruction doesn't actually
care about that. It might also be the end of control flow. This might
keep values alive too long. What we really want is to say "my source
and destinations interfere".
This patch creates new infrastructure for doing just that, and teaches
the register allocator to add interference when there's a hazard. For
my vec4 case, we can determine this by switching on opcodes. For the
SIMD16 case, we just move the existing code there.
I audited our existing virtual opcodes that generate multiple
instructions; I believe FS_OPCODE_PACK_HALF_2x16_SPLIT needs this
treatment as well, but no others.
v2: Rebased by mattst88.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We've apparently always been botching JIP for sequences such as:
do
cmp.f0.0 ...
(+f0.0) break
...
if
...
else
...
endif
...
while
Normally, UIP is supposed to point to the final destination of the jump,
while in nested control flow, JIP is supposed to point to the end of the
current nesting level. It essentially bounces out of the current nested
control flow, to an instruction that has a JIP which bounces out another
level, and so on.
In the above example, when setting JIP for the BREAK, we call
brw_find_next_block_end(), which begins a search after the BREAK for the
next ENDIF, ELSE, WHILE, or HALT. It ignores the IF and finds the ELSE,
setting JIP there.
This makes no sense at all. The break is supposed to skip over the
whole if/else/endif block entirely. They have a sibling relationship,
not a nesting relationship.
This patch fixes brw_find_next_block_end() to track depth as it does
its search, and ignore anything not at depth 0. So when it sees the
IF, it ignores everything until after the ENDIF. That way, it finds
the end of the right block.
I noticed this while reading some assembly code. We believe jumping
earlier is harmless, but makes the EU walk through a bunch of disabled
instructions for no reason. I noticed that GLBenchmark Manhattan had
a shader that contained a BREAK with a bogus JIP, but didn't measure
any performance improvement (it's likely miniscule, if there is any).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
This will allow adding tess stuff much cleaner later.
Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just splits out a common pattern into an inline function
to make things cleaner to read.
Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We really should initialise HS/LS_2 and SQ_LDS_ALLOC exists
on all evergreen not just cayman, so we should initialise
it as well.
Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the defines for a bunch of registers and shader
values that are required to implement tessellation.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Move some common code into one place, tess will also need
to use this function.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This helps in debugging unknown instructions.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
There was only a single user which was using strlen(buf).
As this function is not user facing (i.e. we don't need to feed back
original length via a callback), we can simplify things.
Suggested-by: Timothy Arceri <timothy.arceri@collabora.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
As glsl_types.{cpp,h} were moved out of the sconscript (commit
b23a4859f4 "scons: Build nir/glsl_types.cpp once.") remove the dangling
includes.
Cc: Jose Fonseca <jfonseca@vmware.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The header is already included by glsl_types.{cpp,h}.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Dead since
5e9aa9926b (2011) - _mesa_ir_compile_shader
69e07bdeb4 (2009) - _mesa_get_program_register
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Brian Paul <brianp@vmware.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Analogous to previous commit, minus the extra dup. We are the one
opening the device thus we can directly use the fd.
Spotted by Coverity (CID 1339867, 1339877)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Analogous to previous commit.
Spotted by Coverity (CID 1339868)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Analogous to previous commit.
Spotted by Coverity (CID 1339866)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Add some checks if the original/dup'd fd is valid and ensure that we
don't leak it on error. The former is implicitly handled within the
pipe_loader, although let's make things explicit and check beforehand.
Spotted by Coverity (CID 1339865)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
In theory this wouldn't be an issue, as we'll find the correct name and
break out of the loop before we hit the sentinel.
Let's fix this and avoid issues in the future.
Spotted by Coverity (CID 1339869, 1339870, 1339871)
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Earlier commit factored out the mpeg4 IQ matrix handling into separate
function, although it forgot to add a break in its case statement.
Thus the data ended up partially overwritten as the mpeg4 and h265
structs are members of the desc union.
Spotted by Coverity (CID 1341052)
Fixes: 64761a841d "st/va: move MPEG4 functions into separate file"
Cc: Julien Isorce <j.isorce@samsung.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Non-timer queries are suspended during blits. When the blits end, the queries
are resumed, but this resume operation itself might run out of CS space and
trigger a flush. When this happens, we must prevent a duplicate suspend during
preflush suspend, and we must also prevent a duplicate resume when the CS flush
returns back to the original resume operation.
This fixes a regression that was introduced by:
commit 8a125afa6e
Author: Nicolai Hähnle <nhaehnle@gmail.com>
Date: Wed Nov 18 18:40:22 2015 +0100
radeon: ensure that timing/profiling queries are suspended on flush
The queries_suspended_for_flush flag is redundant because suspended queries
are not removed from their respective linked list.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reported-by: Axel Davy <axel.davy@ens.fr>
Cc: "11.1" <mesa-stable@lists.freedesktop.org>
Tested-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Zero length arrays are non standard:
warning C4200: nonstandard extension used : zero-sized array in struct/union
Cannot generate copy-ctor or copy-assignment operator when UDT contains a zero-sized array
And all code does `N * sizeof query_result->batch[0]`, so it should work
exactly the same.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
From Section 11.1.3.11 (Validation) of the GLES 3.1 spec:
"An INVALID_OPERATION error is generated by any command that trans-
fers vertices to the GL or launches compute work if the current set
of active program objects cannot be executed, for reasons including:"
It then goes on to list the rules we validate in the
_mesa_validate_program_pipeline() function.
For ValidateProgramPipeline the only mention of generating an error is:
"An INVALID_OPERATION error is generated if pipeline is not a name re-
turned from a previous call to GenProgramPipelines or if such a name has
since been deleted by DeleteProgramPipelines,"
Which we handle separately.
This fixes:
ES31-CTS.sepshaderobjs.PipelineApi
No regressions on the eEQP 3.1 tests.
Cc: Gregory Hainaut <gregory.hainaut@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Rather than assigning inloc up front, when we don't yet know if it will
be unused, assign it last thing before the legalize pass.
Also, realize when inputs are unused (since for frag shader's we can't
rely on them being removed from ir->inputs[]). This doesn't make sense
if we don't also dynamically assign the inloc's, since we could end up
telling the hw the wrong # of varyings (since we currently assume that
the # of varyings and max-inloc are related..)
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Make the interpolation / point-sprite replacement mode setup deal with
varying packing.
In a later commit, we switch to packing just the varying components that
are actually used by the frag shader, so we won't be able to assume
everything is vec4's aligned to vec4. Which would highly confuse the
previous vinterp/vpsrepl logic.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The thread scratch space is thread-local so using the full IA-coherent
stateless surface index (255 since Gen8) is unnecessary and
potentially expensive. On Gen8 and early steppings of Gen9 this is
not a functional change because the kernel already sets bit 4 of
HDC_CHICKEN0 which overrides all HDC memory access to be non-coherent
in order to workaround a hardware bug.
This happens to fix a full system hang when running any spilling code
on a pre-production SKL GT4e machine I have on my desk (forcing all
HDC access to non-coherent from the kernel up to stepping F0 might be
a good idea though regardless of this patch), and improves performance
of the OglPSBump2 SynMark benchmark run with INTEL_DEBUG=spill_fs by
33% (11 runs, 5% significance) on a production SKL GT2 (on which HDC
IA-coherency is apparently functional so it wouldn't make sense to
disable globally).
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Unfortunately Gen7 scratch block reads and writes seem to be hardwired
to BTI 255 even on Gen9+ where that index causes the dataport to do an
IA-coherent read or write. This change is required for the next patch
to be correct, since otherwise we would be writing to the scratch
space using non-coherent access and then reading it back using
IA-coherent reads, which wouldn't be guaranteed to return the value
previously written to the same location without introducing an
additional HDC flush in between.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Since the query names are not very enlightening, and there are thousands
of them, GALLIUM_HUD=help should only show the first and last query name
for each hardware block.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Otherwise assert is raised from vlVaQueryConfigProfiles's for loop.
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
No drivers currently implement ARB_geometry_shader4, nor are there
any plans to implement it. We only support the version of geometry
shaders that was incorporated into OpenGL 3.2 / GLSL 1.50.
Signed-off-by: Marta Lofstedt <marta.lofstedt@linux.intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Patch adds additional mask for tracking which vertex arrays have
associated vertex buffer binding set. This array can be directly
compared to which vertex arrays are enabled and should match when
drawing.
Fixes following CTS tests:
ES31-CTS.draw_indirect.negative-noVBO-arrays
ES31-CTS.draw_indirect.negative-noVBO-elements
v2: update mask in vertex_array_attrib_binding
v3: rename mask and make it track _BoundArrays which matches what
was actually originally wanted (Fredrik Höglund)
v4: code cleanup, check for GLES 3.1 (Fredrik Höglund)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
This was missed in commit 59cfb21d ("targets: use the non-inline sw
helpers").
Fixes build failure:
CXXLD libXvMCgallium.la
../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_static.a(libpipe_loader_static_la-pipe_loader_sw.o):(.data.rel.ro+0x0): undefined reference to `sw_screen_create'
collect2: error: ld returned 1 exit status
Makefile:756: recipe for target 'libXvMCgallium.la' failed
make[3]: *** [libXvMCgallium.la] Error 1
Trivial.
Analogous to previous commit. As we no longer have anyone who uses NIR
we can drop the link.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Unused as of commit 23fb11455b "{st,targets}/dri: use static/dynamic
pipe-loader"
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Previously (with the inline ones) things were embedded into the
pipe-loader, which means that we cannot control/select what we want in
each target.
That also meant that at runtime we ended up with the empty
sw_screen_create() as the GALLIUM_SOFTPIPE/LLVMPIPE were not set.
v2: Cover all the targets, not just dri.
Cc: "11.1" <mesa-stable@lists.freedesktop.org>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Oded Gabbay <oded.gabbay@gmail.com>
Tested-by: Nick Sarnie <commendsarnex@gmail.com>
Feeling rather dirty copying the inline ones, yet we need the inline
ones for swrast only targets like libgl-xlib, osmesa.
Cc: "11.1" <mesa-stable@lists.freedesktop.org>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Oded Gabbay <oded.gabbay@gmail.com>
Tested-by: Nick Sarnie <commendsarnex@gmail.com>
With earlier commit we've dropped the manual iteration over the fixed
size array and prepemtively set the variable storing the size, that is
to be returned. Yet we forgot to adjust the comparison, as before we
were comparing the index, now we're comparing the size.
Fixes: ff9cd8a67c "pipe-loader: directly use
pipe_loader_sw_probe_null() at probe time"
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93091
Reported-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Swap core.h with macros.h, as the latter provides the required MAX2
macro.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
While we correctly set output[] for composite varyings, we set completely
bogus values for output_components[], making emit_urb_writes() output
zeros instead of the actual values.
Unfortunately, our simple approach goes out the window, and we need to
recurse into structs to get the proper value of vector_elements for each
field.
Together with the previous patch, this fixes rendering in an upcoming
game from Feral Interactive.
v2: Use pointers instead of pass-by-mutable-reference (Jason, Matt).
Cc: "11.1 11.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Apparently we have literally no support for FS varying struct inputs.
This is somewhat surprising, given that we've had tests for that very
feature that have been passing for a long time.
Normally, varying packing splits up structures for us, so we don't see
them in the backend. However, with SSO, varying packing isn't around
to save us, and we get actual structs that we have to handle.
This patch changes fs_visitor::emit_general_interpolation() to work
recursively, properly handling nested structs/arrays/and so on.
(It's easier to read with diff -b, as indentation changes.)
When using the vec4 VS backend, this fixes rendering in an upcoming
game from Feral Interactive. (The scalar VS backend requires additional
bug fixes in the next patch.)
v2: Use pointers instead of pass-by-mutable-reference (Jason, Matt).
Cc: "11.1 11.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The compiler has more information and is able to optimize the bits
it sets in these registers.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
CC: <mesa-stable@lists.freedesktop.org>
Expose most of the performance counter groups that are exposed by Catalyst.
Ideally, the driver will work with GPUPerfStudio at some point, but we are not
quite there yet. In any case, this is the reason for grouping multiple
instances of hardware blocks in the way it is implemented.
The counters can also be shown using the Gallium HUD. If one is interested to
see how work is distributed across multiple shader engines, one can set the
environment variable RADEON_PC_SEPARATE_SE=1 to obtain finer-grained performance
counter groups.
Part of the implementation is in radeon because an implementation for
older hardware would largely follow along the same lines, but exposing
a different set of blocks which are programmed slightly differently.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Performance monitor queries can become very big, especially considering that
instances of a block in different shader engines are queried separately.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The enable of AMD_performance_monitor is no longer related to whether
queries are run by the GPU since the commit mentioned below.
Suggested-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
commit ddf27a3dd0
Author: Nicolai Hähnle <nhaehnle@gmail.com>
Date: Tue Nov 10 13:35:01 2015 +0100
gallium: remove pipe_driver_query_group_info field type
Most applications never use performance counters, so allow drivers to
skip potentially expensive initialization steps.
A driver that wants to use this must enable the appropriate extension(s)
at context initialization and set the InitPerfMonitorGroups driver function
which will be called the first time information about the performance monitor
groups is actually used.
The init_groups helper is called for API functions that can be called before
a monitor object exists. Functions that require an existing monitor object
can rely on init_groups having been called before.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Previously pass did not traverse to those array dereferences which were
used as indices to arrays. This fixes Synmark2 Gl42CSCloth application
issues.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
templat->interlaced is 0 if not NV12 which is the case currently
when using VPP.
Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This will help avoid eliminating inputs/outputs needed by SSOs.
Cc: Gregory Hainaut <gregory.hainaut@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
This setting is only used by glTexCoordPointer and related glEnable
calls. Since the preceeding commits removed all of those, it is not
necessary to save, reset to default, or restore this state.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Nothing left in meta does anything with the VBO binding, so we don't
need to save or restore it. The VAO binding is still modified.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions. The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.
Here's the problem scenario:
- Application calls a meta function that generates a name. The first
Gen will probably return 1.
- Application decides to use the same name for an object of the same
type without calling Gen. Many demo programs use names 1, 2, 3,
etc. without calling Gen.
- Application calls the meta function again, and the meta function
replaces the data. The application's data is lost, and the app
fails. Have fun debugging that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions. The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.
Here's the problem scenario:
- Application calls a meta function that generates a name. The first
Gen will probably return 1.
- Application decides to use the same name for an object of the same
type without calling Gen. Many demo programs use names 1, 2, 3,
etc. without calling Gen.
- Application calls the meta function again, and the meta function
replaces the data. The application's data is lost, and the app
fails. Have fun debugging that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions. The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.
Here's the problem scenario:
- Application calls a meta function that generates a name. The first
Gen will probably return 1.
- Application decides to use the same name for an object of the same
type without calling Gen. Many demo programs use names 1, 2, 3,
etc. without calling Gen.
- Application calls the meta function again, and the meta function
replaces the data. The application's data is lost, and the app
fails. Have fun debugging that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The fixed-function attribute paths don't get the DSA treatment because
there are no DSA entry-points for fixed-function attributes. These
could have been added, but this is a temporary patch intended to make
later patches easier to review.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Meta currently does this, but future changes will make this impossible.
Explicitly do it as a step in the patch series now to catch any possible
kinks.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions. The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.
Here's the problem scenario:
- Application calls a meta function that generates a name. The first
Gen will probably return 1.
- Application decides to use the same name for an object of the same
type without calling Gen. Many demo programs use names 1, 2, 3,
etc. without calling Gen.
- Application calls the meta function again, and the meta function
replaces the data. The application's data is lost, and the app
fails. Have fun debugging that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Instead of going through the GL API implementation functions, use the
lower-level functions. This means that we have to keep track of a
pointer to the gl_buffer_object and the gl_vertex_array_object.
This has two advantages. First, it avoids a bunch of CPU overhead in
looking up objects and validing API parameters. Second, and much more
importantly, it will allow us to stop calling _mesa_GenBuffers /
_mesa_CreateBuffers and pollute the buffer namespace (next patch).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Future patches will use the brw_context instead. Keeping this
non-functional change separate should make the function changes easier
to review.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Pulls the parts of enable_vertex_array_attrib that aren't just parameter
validation out into a function that can be called from other parts of
Mesa (e.g., meta).
_mesa_enable_vertex_array_attrib can also be used to enable
fixed-function arrays.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Pulls the parts of update_array_format that aren't just parameter
validation out into a function that can be called from other parts of
Mesa (e.g., meta).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This reverts commit a280e83d71.
It breaks INTEL_DEBUG=fs output. For example,
glsl-fs-discard-01.shader_test has 11 instructions but only prints 5.
Acked-by: Matt Turner <mattst88@gmail.com>
Coverity noticed that we were passing this by value, and it's 152 bytes.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
It's only called from C, it compiles as C, so just compile it as C.
Notice the missing extern "C" on the definition of the function, which
would screw things up if the prototype wasn't parsed before the
definition.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We were including it in headers, which then caused it to be included in
tons of places it wasn't needed.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These functions' prototypes are marked with extern "C", which apparently
overrides a lack of extern "C" at the definition site if the prototype
has been seen first.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now that backend_reg inherits from brw_reg, we have to be careful to
avoid the object slicing problem.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
In the next patch, I make backend_reg's inheritance from brw_reg
private, which confuses clang when it sees the type "struct brw_reg" in
the derived class constructors, thinking it is referring to the
privately inherited brw_reg:
brw_fs.cpp:366:23: error: 'brw_reg' is a private member of 'brw_reg'
fs_reg::fs_reg(struct brw_reg reg) :
^
brw_shader.h:39:22: note: constrained by private inheritance here
struct backend_reg : private brw_reg
^~~~~~~~~~~~~~~
brw_reg.h:232:8: note: member is declared here
struct brw_reg {
^
Avoid this by marking brw_reg with the scope resolution operator.
In order to do this, we have to change the signature of the
backend_reg(brw_reg) constructor to take a reference to a brw_reg in
order to avoid unresolvable ambiguity about which constructor is
actually being called in the other modifications in this patch.
As far as I understand it, the rule in C++ is that if multiple
constructors are available for parent classes, the one closest to you in
the class heirarchy is closen, but if one of them didn't take a
reference, that screws things up.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
3333977556 added support for ASTC textures to
gallium. They don't have any helpers hooked up for software decoding, however,
so cannot support them in drivers relying on util code for decoding.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Edward O'Callaghan
Ilia Mirkin
Eric Anholt
Samuel Pitoiset
Rob Clark
Giuseppe Bilotta
Emil Velikov
Jason Ekstrand
Roland Scheidegger
Marek Olšák
Jose Fonseca
Nanley Chery
Brian Paul
Juha-Pekka Heikkila
Tapani Pälli
Kenneth Graunke
Matt Turner
Dave Airlie
Tom Stellard
Jonathan Gray
Iago Toral Quiroga
Julien Isorce
Gregory Hainaut
Timothy Arceri
Samuel Iglesias Gonsálvez
Emil Velikov
Nicolai Hähnle
Neil Roberts
Serge Martin
Francisco Jerez
Nicolai Hähnle
Marta Lofstedt
Michel Dänzer
Ian Romanick