| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Add missing `const` specifier for pointer pointing to a const struct.
Signed-off-by: Giuseppe Bilotta <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Giuseppe Bilotta <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Should have been part of commit f53f9eb8d49 "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: f53f9eb8d49 "glapi: add GetPointervKHR to the ES dispatch".
Signed-off-by: Emil Velikov <[email protected]>
Tested-by: Vinson Lee <[email protected]> (v1)
Tested-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, 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" <[email protected]>
Signed-off-by: Nanley Chery <[email protected]>
Reviewed-by: Marta Lofstedt <[email protected]>
|
|
|
|
| |
Trivial.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Charmaine Lee <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
Cc: "11.0 11.1" <[email protected]>
|
|
|
|
|
|
|
| |
Surprisingly, this didn't exist at all.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
| |
Trivial.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
CC: <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Alan Coopersmith <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Acked-by: Tapani Pälli <[email protected]>
Acked-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
| |
Removes dead code from glsl-mat-from-int-ctor-03.shader_test.
Reported-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Tested with scons (by both myself and Mark Janes), Android is just copy
and paste.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Correct some occurrences of -ldl and -lpthread to use
$(DLOPEN_LIBS) and $(PTHREAD_LIBS) respectively.
Signed-off-by: Jonathan Gray <[email protected]>
Cc: "11.0 11.1" <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Abdiel Janulgue <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
As glsl_types.{cpp,h} were moved out of the sconscript (commit
b23a4859f4d "scons: Build nir/glsl_types.cpp once.") remove the dangling
includes.
Cc: Jose Fonseca <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dead since
5e9aa9926b9 (2011) - _mesa_ir_compile_shader
69e07bdeb42 (2009) - _mesa_get_program_register
Cc: Kenneth Graunke <[email protected]>
Cc: Brian Paul <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93126
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Eduardo Lima Mitev <[email protected]>
Cc: "11.0 11.1" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
| |
Reviewed-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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" <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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" <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
commit ddf27a3dd062c78ff49a69a1396be4de9c1b5d37
Author: Nicolai Hähnle <[email protected]>
Date: Tue Nov 10 13:35:01 2015 +0100
gallium: remove pipe_driver_query_group_info field type
|
|
|
|
| |
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
|
|
|
| |
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Fixes a warning introduced by commit dcadd855.
|