Looks like the various max's were never plumbed through.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Until now there has been only one type of color buffer that needs
to resolved - namely single sampled fast clear. As even the
sampler engine in GPU doesn't understand the associated meta data,
the color values need to be always resolved prior to reading them.
From SKL onwards there is new scheme supported called the lossless
compression of single sampled color buffers. This is something that
is understood by the sampling engine and therefore resolving of
these types of buffers is not necessary before sampling.
This patch adds means to make the distinction when considering if
resolve is needed.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
In addition to simply calling miptree_create() the higher level
call intel_miptree_create() also considers if the buffer should
be associated with an auxiliary buffer based on the given format.
Here we are allocating an auxiliary buffer which in turn has such
format that would mislead intel_miptree_create_layout() later on
to try to associate the auxiliary buffer with an auxiliary buffer.
To prevent this the actual buffer creation logic was split out
into its own function. Lets invoke that instead.
v2 (Ben): Do not signal msaa layout with explicit argument but
using layout_flags instead.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
These were originally added to reduce compiler warnings but aren't really
needed. Getting rid of them reduces the diff between the Vulkan branch and
master, so we might as well.
This allows ls, and scripts to get the file names in the correct order of
optimization.
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The L3 partitioning code tries to look at all programs - both render
programs (VS/TCS/TES/GS/FS) and compute (CS).
After calling brw_clear_cache, all prog_data pointers are invalid and
point to freed data. The intention was that flagging the dirty bits for
all programs would cause the next draw call to re-run the atoms for each
program stage, uploading new programs and installing new, valid pointers.
However, this doesn't quite work in our new multi-pipeline world. When
drawing or dispatching a compute workload, we only consider the programs
for the appropriate pipeline: drawing sets up VS/TCS/TES/GS/FS, but not
CS, and vice versa. This leaves pointers dangling a bit longer than
intended.
The L3 configuration code tries to inspect the prog_data for all shader
stages, so that we avoid having to reconfigure it when swapping back and
forth between render and compute workloads. So we can't have dangling
pointers.
The fix is simple: have brw_clear_cache NULL out stale prog_data
pointers, making it safe to inspect. The next L3 configuration pass
will see either the render shaders or compute shader as missing for
one go around, but will pick them up when both pipelines have run.
In other words, we'll simply reconfigure L3 twice, which is safe,
if a tiny bit wasteful - but then again, we just threw every compiled
shader we had on the floor and started recompiling the from scratch,
which is massively more wasteful, so it's not much of a concern.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93790
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jordan Justen <jljusten@gmail.com>
If there is no pipe info log, we would unconditionally deref length,
which was only optionally there. _mesa_copy_string handles the source
being null, as well as the length, so may as well just always call it.
Fixes a segfault in
dEQP-GLES31.functional.state_query.program_pipeline.info_log
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Similar to commit dd9d2963d6 (mesa: AtomicBufferBindings should be
initialized to zero.), we should reset these to zero when unbinding.
This fixes a number of dEQP failures due to cross-test pollution. The
tests properly unbound everything, but when querying the values again,
the expectation was that they would be 0.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Similar as for AUX1-3, these enums aren't invalid (i.e. -1) but also not
supported by mesa. Returning BUFFER_COUNT causes the proper error to be
returned by ReadBuffer and other functions. This resolves some failures
in
dEQP-GLES31.functional.debug.negative_coverage.get_error.buffer.read_buffer
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
This fixes
dEQP-GLES31.functional.debug.negative_coverage.get_error.buffer.clear_bufferfv
and brings the logic up to spec with GL 4.5
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
This fixes
dEQP-GLES31.functional.debug.negative_coverage.get_error.buffer.clear_bufferuiv
and brings the logic up to spec with GL 4.5
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
There's a hunk above which sets INVALID_ENUM for GL_DEPTH
unconditionally.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
This fixes
dEQP-GLES31.functional.state_query.texture.texture_2d_multisample.depth_stencil_mode_integer
and a few related tests.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
The race we were seeing on cherryview was caused by the multi-submit
problem with fences. We can now turn snooping off again an rely on
clflush and we intended.
We were implementing those the same way than
the default pool, which is sub-optimal.
The buffer is supposed to return pointer to
a ram copy when user locks, and automatically
update the vram copy when needed.
v2: Rename NineBuffer9_Validate to NineBuffer9_Upload
Rename validate_buffers to update_managed_buffers
Initialize NineBuffer9 managed fields after the resource
is allocated. In case of allocation failure, when the dtor
is executed, This->base.pool is then rightfully set.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
For 32 bits, incoming stack is 4-byte aligned.
We need to realign the stack to 16-byte at some point,
or there are issues later (crash with SSE, llvm, etc).
This patch chooses to align the stack at API entry points.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
using MIN/MAX is fine instead of CLAMP.
NRM doesn't exist anymore.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
We had several issues of crashes with it.
This should fix it.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Add new argument to d3d9_to_pipe_format_checked to
be able to bypass format support checks. This argument
is set to TRUE when the requested Pool is SCRATCH.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Returns INVALIDCALL when trying to create a surface
of unsupported format.
In practice, apps are supposed to check for format
support before trying to create a render target
of that format. However some bad behaving apps
could just try to create the surface and deduce if
it failed that it wasn't supported.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Texture and CubeTexture use common code,
and thus ATI1/ATI2 is already implemented
for CubeTexture.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
We were having checks at both Create*Texture functions
and in ctors.
Move all Create*Texture checks to ctors.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This->base.base.resource is worth NULL
for SYSTEMMEM textures.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
We do not support shared textures, thus no need to set
the shared flag.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
We do not create a resource for SYSTEMMEM textures,
thus we do not need to set resource usage.
The only exception is vertexbuffer SYSTEMMEM, since
we do use a pipe resource for them.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
So it's near the other cube map helper functions.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Just minor clean-up so we're consistent everywhere.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We hash the input SPIR-V, specialization constants, entrypoint and the
shader key using SHA1 to determine a unique identifier for the
combination. A VkPipelineCache is then a hash table mapping these
identifiers to the corresponding prog_data and kernel data.
Long ago, the blit code used to handle clearing and blitting.
- Fix any comments that refer to clearing.
- Rename shader var 'attr' to 'tex_pos'. The name 'attr' is an artifact
of the time when the shader was used for blitting as well as clearing.
The clear code lived in anv_meta_clear.c. The resolve code in
anv_meta_resolve.c. Only the blit code lived in anv_meta.c, alongside
the shareed meta code.
This is just a copy-paste patch. No change in behavior.
We already use these for gallium in
src/gallium/auxiliary/os/os_memory_stdc.h and it's always better to
minimize divergences between MinGW and MSVC.
Reviewed-by: Brian Paul <brianp@vmware.com>
