Generate functions which determine if an extension is supported in the
current context. Initially, enums were going to be explicitly used with
_mesa_extension_supported(). The idea to embed the function and enums
into generated helper functions was suggested by Kristian Høgsberg.
For performance, the function body no longer uses
_mesa_extension_supported() and, as suggested by Chad Versace, the
functions are also declared static inline.
v2: Place function qualifiers on separate line (Chad)
v3: Move function curly brace to new line (Chad)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
The api_set field has no users outside of _mesa_extension_supported().
Remove it and allow the version field to take its place.
The brunt of the transformation was performed with the following vim commands:
s/\(GL [^,]\+\),\s*\d*,\s*\d*\(,\s*\d*\)\(,\s*\d*\)/\1, GLL, GLC\2\3/g
s/\(GLL [^,]\+\)\,\s*\d*/\1, GLL/g
s/\(GLC [^,]\+\)\(,\s*\d*\),\s*\d*\(,\s*\d*\)\(,\s*\d*\)/\1\2, GLC\3\4/g
s/\( ES1[^,]*\)\(,\s*\(\w\|\d\)\+\)\(,\s*\(\w\|\d\)\+\),\s*\d*/\1\2\4, ES1/g
s/\( ES2[^,]*\)\(,\s*\(\w\|\d\)\+\)\(,\s*\(\w\|\d\)\+\)\(,\s*\(\w\|\d\)\+\),\s*\d*/\1\2\4\6, ES2/g
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Replace open-coded checks for extension support with
_mesa_extension_supported().
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Create a function which determines if an extension is supported in the
current context.
v2: Use common variable names (Emil)
Insert new line between variables and return statement (Chad)
Rename api_set variable to api_bit (Chad)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Enable limiting advertised extension support by context version with
finer granularity. This new field is currently unused and is set to
0 everywhere. When it is used, a value of 0 will indicate that the
extension is supported for any version of a context.
v2: Use uint*t type for version and note the expected values (Emil)
Use an 8-bit data type
Reformat macro for better readability (Chad)
v3: Note preparatory nature of commit (Chad)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
With this infrastructure set in place, we can now reuse the entries to
generate useful code.
v2: Add the new file into Makefile.sources (Emil)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Now that we're using macros, remove the redundant text from each entry.
Remove comments between the entries to make editing easier and separate
the sections with blank lines. Structure the EXT macros in a way that
helps reviewers verify that no meaning has been altered.
v2: Indent the entries (Chad)
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Simplify future updates to the extension struct array by removing
the sentinel.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Initially just checks that sources are non-NULL, which would have
alerted us to the problem fixed by commit 6c846dc5.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Will allow annotations to contain error messages (indicating an
instruction violates a rule for instance) that are printed after the
disassembly of the block.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Often annotations are identical between sets of consecutive
instructions. We can perhaps avoid some memory allocations by reusing
the previous annotation.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
And why did IFF have a destination?
I suspect that once upon a time the disassembler used this information
to know which fields to find the jump targets in. The jump targets have
moved, so the disassembler has to know how to handle these
per-generation anyway.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Add some instructions: illegal, movi, sends, sendsc.
Remove some instructions with reused opcodes: msave, mrestore, push,
pop, goto. I did have some gross code for disassembling opcodes
per-generation, but there's very little meaningful overlap so it's
probably not needed.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This would have caught the locking bug that was fixed in the earlier
"st/wgl: fix locking issue in stw_st_framebuffer_present_locked()"
patch.
v2: minor coding style changes by Brian.
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
v2: update comments on the stw_framebuffer::mutex field regarding locking
order.
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
To get declaration for debug_printf() directly instead of getting it
indirectly through os_thread.h
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
This is Windows-only code so we can use the native Win32 functions for
critical sections. This will also allow us to (cleanly) add some mutex
check/debug code in subsequent patches.
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
We support "cpu" but not "cpu#" because there's no good way of querying
per-cpu usage. Also, the cpu usage is for the process, not the whole
system.
Original code cobbled together by Brian and then fixed/polished by Jose.
Signed-off-by: Brian Paul <brianp@vmware.com>
Patch sets matrix_stride as 0 for non matrix uniforms that are in a
atomic counter buffer. Matrix stride calculation for actual matrix
uniforms is done during link_assign_uniform_locations.
From ARB_program_interface_query specification:
GL_MATRIX_STRIDE:
"For active variables not declared as a matrix or array of matrices,
zero is written to <params>. For active variables not backed by a
buffer object, -1 is written to <params>, regardless of the variable
type."
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
This information will be used by cross stage validation of varyings
for pipeline objects.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
We will need this later on when we implement proper support for
precision qualifiers in the drivers and also to do link time checks for
uniforms as indicated by the spec.
This patch also adds compile-time checks for variables without precision
information (currently, Mesa only checks that a default precision is set
for floats in fragment shaders).
As indicated by Ian, the addition of the precision information to
ir_variable has been done using a bitfield and pahole to identify an
available hole so that memory requirements for ir_variable stay the
same.
v2 (Ian):
- Avoid if-ladders by defining arrays of supported sampler names and
indexing
into them with type->sampler_array + 2 * type->sampler_shadow
- Make the code that selects the precision qualifier to use an utility
function
- Fix a typo
v3 (Tapani):
- rebased
- squashed in "Precision qualifiers are not allowed on structs"
- fixed select_gles_precision for sampler arrays
- fixed precision_qualifier_allowed for arrays of structs
v4 (Tapani):
- add atomic_uint handling
- do not allow precision qualifier on images
(issues reported by Marta)
v5 (Tapani):
- support precision qualifier on image types
v6 (Tapani):
- set precision qualifier on interface block members
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
We will need this to build later patches
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Notice that the spec requires that a default precision has been set for every
type used by a shader that can use a precision qualifier and does not have a
predefined precision, however, at the moment, Mesa only checks this for floats
in the fragment shader. This is probably because the GLSL ES 1.0 specs mentions
this case specifically, but GLSL ES 3.0 clarifies that the same applies to
other types:
"The fragment language has no default precision qualifier for floating point
types. Hence for float, floating point vector and matrix variable
declarations, either the declaration must include a precision qualifier or
the default float precision must have been previously declared. Similarly,
there is no default precision qualifier for the following sampler types in
either the vertex or fragment language:
sampler3D;
samplerCubeShadow;
sampler2DShadow;
sampler2DArray;
sampler2DArrayShadow;
isampler2D;
isampler3D;
isamplerCube;
isampler2DArray;
usampler2D;
usampler3D;
usamplerCube;
usampler2DArray;"
we will fix this in a later patch.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
The GLSL ES spec specifies default precision qualifiers for certain types,
so populate the symbol table with these.
Notice that the desktop GLSL spec also indicates defaults for some types
but this is not really useful since precision qualifiers are completely
ignored in desktop GLSL.
v2: simplify and add samplerExternalOES, specified by
OES_EGL_image_external (Tapani)
v3: add atomic_uint (reported missing by Marta)
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
These have scoping rules that match the ones defined for other things such
as variables, so we want them in the symbol table.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
FS_OPCODE_GET_BUFFER_SIZE is calculated with a resinfo's sampler message.
This patch adjusts the number of registers written by the opcode
following what the PRM spec says about the number of registers written
by the SIMD8 and SIMD16's writeback messages for sampler messages.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
The comment in the code details the restriction. Thanks to Ken for having a very
helpful conversation with me, and spotting the blurb in the link I sent him :P.
There are still stability problems for me on GT4, but this definitely helps with
some of the failures.
v2: Comment fixes
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes the corruption on rendering that we are seeing in
certain geometry shaders.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91780
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested / Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com>
Cc: "10.6" "11.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Many intrinsics only apply to a particular stage (such as discard).
In other cases, we may want to interpret them differently based on
the stage (such as load_primitive_id or load_input).
The current method isn't that pretty - we handle all intrinsics in
one giant function. Sometimes we assert on stage, sometimes we forget.
Different behaviors are handled via if-ladders based on stage.
This commit introduces new nir_emit_<stage>_intrinsic() functions,
and makes nir_emit_instr() call those. In turn, those fall back to
the generic nir_emit_intrinsic() function for cases they don't want
to handle specially.
This makes it clear which intrinsics only exist in one stage, and makes
it easy to handle inputs/outputs differently for various stages.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
