In creating fixed function vertex shader hash keys do only
care for producing the varying output if fog is enabled and the
varing is consumed in the fragment stage.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Using lower alignment restrictions for the state key fields finally
yields to a smaller hashing state key.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Remove set but not read field from the state key used for hashing
fixed function vertex shaders.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Remove set but not read field from the state key used for hashing
fixed function vertex shaders.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
For the state key for hashing fixed function vertex shaders, the
texgen_enabled field requires only a single bit.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
For the state key for hashing fixed function
vertex shaders, encode the different fog modes, including
if fog is generally enabled or not, into a 2 bit field.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
For the state key for hashing fixed function
vertex shaders, the information is only evaluated
if lighting is generally switched on.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
For the state key for hashing fixed function
vertex shaders, The varying_vp_inputs bitmask already
contains the point size array enabled information.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
The patch removes a variable that is only written to.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
If a shader only writes to an output via a constant initializer we
need to lower it before we call nir_remove_dead_variables so that
this pass sees the stores from the initializer and doesn't kill the
output.
Fixes test failures in new work-in-progress CTS tests:
dEQP-VK.spirv_assembly.instruction.graphics.variable_init.output_vert
dEQP-VK.spirv_assembly.instruction.graphics.variable_init.output_frag
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Now every context refers to same disk_cache instance in screen.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
texture_format_error_check_gles() displays error like "glTexImage%dD".
This patch just replace the %d by the correct dimension.
Signed-off-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Inspired by Marek's earlier patch, but even smaller. Sort fields from
largest to smallest. Use bitfields for more fields (sometimes with an
extra bit for MSVC). Reduce Stride field to GLshort.
Note that some fields cannot be bitfields because they're accessed via
pointers (such as for glEnableClientState(GL_VERTEX_ARRAY) to set the
Enabled field).
Reduces size from 48 to 24 bytes.
Also reduces size of gl_vertex_array_object from 3632 to 2864 bytes.
And add some assertions in init_array().
v2: use s/GLuint/unsigned/, improve commit comments.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Inspired by Marek's earlier patch, but goes a little further.
Sort fields from largest to smallest. Use bitfields.
Reduced from 48 bytes to 32. Also reduces size of gl_vertex_array_object
from 4144 to 3632
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
v2: - fix glGet*
- also use GLenum16 for DrawBuffers
v3: - rebase to top of tree (BrianP) and incorporate Ian's suggestions
v4: - fix a GLenum16 bug in VBO/save code, add some STATIC_ASSERT()s
gl_context = 152432 -> 136840 bytes
vbo_context = 22096 -> 20608 bytes
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
get_value_size() returns -1 for an error. The similar check in
_mesa_GetUnsignedBytei_vEXT() is correct.
Found by chance. There are apparently no Piglit tests which exercise
glGetUnsignedBytei_vEXT() or glGetUnsignedBytevEXT().
Reviewed-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Sometimes rasterization state object could be empty. This is causing
segfault on hw8,9,10 for some traces.
This patch fixes enemy_territory_quake_wars_high,
enemy_territory_quake_wars_low, etqw-demo, lightsmark2008, quake1
glretrace crashes on hw 8,9,10.
Tested with mtt-glretrace and mtt-piglit.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
According to spec, S3TC_DXT1_EXT RGB formats are supposed to be
opaque. Correspoding svga formats are not handling it so explicitly
setting it to 1.0.
This fixes piglit test spec@ext_texture_compression_s3tc@s3tc-targeted
Note: This test is testcase for freedesktop bug 100925
Tested with mtt-piglit and mtt-glretrace on 8,9,10,11 and 15
Reviewed-by: Brian Paul <brianp@vmware.com>
In the register lifetime estimation if the first write is unconditional or
conditional but not within a loop then this is an unconditional dominant
write in the sense of register life time estimation.
Add a test case and record the write accordingly.
Fixes: 807e2539e5 ("mesa/st/glsl_to_tgsi: Add
tracking of ifelse writes in register merging")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104803
Signed-off-by: Gert Wollny <gw.fossdev@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The size/type query is always legal (if we made it that far).
Removing this causes a difference for GL_TEXTURE_BUFFER - the reason is that
these parameters are valid only with GetTexLevelParameter() if gl 3.1 is
supported, but not if only ARB_texture_buffer_object is supported.
However, while the spec says that these queries return "the same information
as querying GetTexLevelParameter" I believe we're not expected to return just
zeros here. By definition, these pnames are always valid (unlike for the
GetTexLevelParameter() function which would return an error without GL 3.1).
The spec is a bit inconsistent there and open to interpretation - while
mentioning the "same information as querying GetTexLevelParameter" is
returned, it also mentions that 0 is returned for size/type if the
target/format is not supported - implying correct results to be returned
if it is supported, regardless that GetTexLevelParameter would return
an error. (Also, the bit about this returning the same as
GetTexLevelParameter also includes querying stencil type, which isn't
even possible with GetTexLevelParameter.)
This breaks some piglit arb_internalformat_query2 tests (which I believe to
be wrong).
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>§
The code just considered all formats as being supported if they were either
a valid fbo or texture format.
This was quite awkward since then the query would return "supported" for
e.g. GL_RGB9E5 or compressed formats and target RENDERBUFFER (albeit the driver
could still refuse it in theory). However, when then querying for instance the
internalformat sizes, it would just return 0 (due to the checks being more
strict there).
It was also a problem for texture buffer targets, which have a more restricted
list of formats which are allowed (and again, it would return supported but
then querying sizes would return 0).
So only take validation of formats into account which make sense for a given
target.
Can also toss out some special checks for rgb9e5 later, since we'd never get
there if it wasn't supported in the first place.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Testing for gles there is just confusing - this is about target being
supported, if it was valid at all was already determined earlier
(in _legal_parameters). It didn't make sense at all in any case, since
it would only have said false there for gles for 2d but not 2d arrays etc.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
This fixes an assert in nir_lower_var_copies() for some bioshock
shaders where an unused clipdistance array has no size.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
c2acf97fcc changed the use of double_inputs_read to be
inconsitent with its previous meaning. Here we re-enable the
gather info code that was removed as the modified code from
c2acf97fcc now uses the double_inputs member rather than
double_inputs_read.
This change allows us to use double_inputs_read with gallium
drivers without impacting double_inputs which is used by i965.
We also make use of the compiler option vs_inputs_dual_locations
to allow for the difference in behaviour between drivers that handle
vs inputs as taking up two locations for doubles, versus those that
treat them as taking a single location.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Allows nir drivers to either use a single or dual locations for
vs double inputs.
i965 uses dual locations for both OpenGL and Vulkan drivers, for
now gallium OpenGL drivers only use a single location.
The following patch will also make use of this option when
calling nir_shader_gather_info().
Reviewed-by: Karol Herbst <kherbst@redhat.com>
First we move double_inputs_read into a vs struct in the union,
double_inputs_read is only used for vs inputs so this will
save space and also allows us to add a new double_inputs field.
We add the new field because c2acf97fcc changed the behaviour
of double_inputs_read, and while it's no longer used to track
actual reads in i965 we do still want to track this for gallium
drivers.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This ports a fix from amdvlk, to fix the sizing for mip levels
when block compressed images are viewed using uncompressed views.
My original fix didn't power the clamping, but it looks like
the clamping is required to stop the sizing going too large.
Fixes:
dEQP-VK.image.texel_view_compatible.graphic.extended*bc*
Doesn't crash DOW3 anymore.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Fixes: e38685cc62 'Revert "radv: disable support for VEGA for now."'
Signed-off-by: Dave Airlie <airlied@redhat.com>
It did not signal syncobjs in the fence, and also signalled too early
if there was work on the queue already, as we have to wait till that
work is done.
Fixes: d27aaae4d2 "radv: Add external fence support."
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
The arrays specified by ctx->Array._DrawArrays are used for all
vertex drawing via vbo_context::draw_prims(). Different arrays are
used for immediate mode, vertex arrays, display lists, etc. Changing
from one to another requires updating derived/driver array state.
Before, we indirectly specifid the arrays with the gl_draw_method values.
Now we just directly specify the arrays instead. This is simpler and
will allow a subsequent display list optimization.
In the future, it might make sense to get rid of ctx->Array._DrawArrays
entirely and just pass the arrays as another parameter to
vbo_context::draw_prims().
Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
To match the VERT_ATTRIB_COLOR_INDEX name.
Give a name to the previously anonymous enum of VBO_ATTRIB_x values.
Update the comment on the enum.
Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
Instead of NONE/ARB use FF/SHADER. Move the enum declaration to
vbo_private.h where it's used.
Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
This change cleans following scary warnings in valgrind output
when disk cache is being written:
==6532== Uninitialised byte(s) found during client check request
==6532== at 0x14423FAD: blob_write_bytes (blob.c:152)
==6532== by 0x144240FB: blob_write_uint32 (blob.c:194)
==6532== by 0x144001A5: write_tex (nir_serialize.c:613)
and later (loads of):
==6532== Use of uninitialised value of size 8
==6532== at 0x62FCD9E: crc32_z (in /usr/lib64/libz.so.1.2.11)
==6532== by 0x13F65014: util_hash_crc32 (crc32.c:127)
==6532== by 0x13F5DABA: cache_put (disk_cache.c:947)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
==2780== 1,024 bytes in 1 blocks are possibly lost in loss record 180 of 205
==2780== at 0x4C31A1E: calloc (vg_replace_malloc.c:711)
==2780== by 0x13F6467E: util_queue_init (u_queue.c:309)
==2780== by 0x13F5C9F6: disk_cache_create (disk_cache.c:369)
==2780== by 0x13F05406: brw_disk_cache_init (brw_disk_cache.c:428)
==2780== by 0x13F01E78: brwCreateContext (brw_context.c:1068)
Fixes: 1a61a8b9a7 ("i965: Initialize disk shader cache if MESA_GLSL_CACHE_DISABLE is false")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
==25481== 576 bytes in 1 blocks are definitely lost in loss record 179 of 208
==25481== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299)
==25481== by 0x1404E2CC: ralloc_size (ralloc.c:121)
==25481== by 0x14119F82: read_and_upload (brw_disk_cache.c:176)
==25481== by 0x1411A5C9: brw_disk_cache_upload_program (brw_disk_cache.c:271)
==25481== by 0x1412FCA4: brw_upload_wm_prog (brw_wm.c:597)
Fixes: 516d50db31 ("i965: add initial implementation of on disk shader cache")
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Brian Paul
Mathias Fröhlich
Iago Toral Quiroga
Tapani Pälli
Elie Tournier
Marek Olšák
Neha Bhende
Gert Wollny
Roland Scheidegger
Rafael Antognolli
Timothy Arceri
Dave Airlie
Bas Nieuwenhuizen