Otherwise we read past the end of the buffer.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
the hack was introduced to avoid an extra copying
but now with dri3 we don't need it anymore
v1.1: rebasing
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Acked-by: Christian König <christian.koenig@amd.com>
this avoids an extra copy which occurs in case of dri2
v1.1: fallback to dri2 if dri3 fails to initialize
v2: add PIPE_BIND_SCANOUT to output buffers as they will
be send to X server directly (Michel)
Suggested-by: Christian König <christian.koenig@amd.com>
Tested-by: Andy Furniss <adf.lists@gmail.com>
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
dri3 allows us to send handle of a texture directly to X
so this patch allows a state tracker to directly send its
texture to X to be used as back buffer and avoids extra
copying
v2: use clip width/height to display a portion of the surface
v3: remove redundant variables, fix wrapping, rename variables
handle vaapi path
v3.1: we need clip_width/height for every frame so we don't need
to maintain it for each buffer instead use a global variable
v4: In case of single gpu we can cache the buffers as applications
use constant number of buffer and we can avoid calls to present
extension for every frame
Reviewed and Suggested-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Andy Furniss <adf.lists@gmail.com>
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
The same we do in the OpenGL driver (comment copied from there).
This is required to ensure that we execute the fragment shader stage when
side-effects (such as image or ssbo stores) are present but there are no
color writes.
I found this while writing a test to check rendering to a framebuffer
without attachments where the fragment shader does not produce any
color outputs but writes to an image via imageStore(). Without this patch
the fragment shader does not execute and the image is not written,
which is not correct.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes crash in dEQP-VK.ubo.random.all_shared_buffer.48 due to a
fragment shader code bigger than 128 kB.
This patch increases the allocation size limit to 1 MB.
v2:
- Increase it to 1 MB (Jason)
- Increase device->instruction_block_pool allocation size in
anv_device.c (Jason)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Address loading can often end up as shl + shr + shl combinations. The
latter two are equal shifts, which get converted into an and mask.
However if the previous shl is more than the mask is trying to remove
(in terms of low bits), we can just remove the and entirely. This
reduces some large shaders by as many as 3% of instructions (out of 2K).
total instructions in shared programs : 6495509 -> 6491076 (-0.07%)
total gprs used in shared programs : 954621 -> 954623 (0.00%)
local gpr inst bytes
helped 0 0 1014 1014
hurt 0 2 0 0
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
We don't need to support all the color buffers for advanced blend, just
cb0. For Fermi, we use the special binding slots so that we don't
overlap with user textures, while Kepler+ gets a dedicated position for
the fb handle in the driver constbuf.
This logic is only triggered when a FBFETCH is actually present so it
should be a no-op most of the time.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This implements support for emitting FBFETCH ops, using the existing
lowering pass for advanced blend logic, and disabling hw blend when
advanced blending is enabled.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This is so that we can differentiate between flushing any framebuffer
reading caches from regular sampler caches.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The extension spec is not currently published, so it's a bit premature
to require it for BlendBarrier usage.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This is just prep work for layered clears, it doesn't change
anything.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pretty straightforward. Also deleted the big comment block as it
is a pretty standard pattern for filling in arrays.
Also removed the error message on non-existent devices, as getting
7 errors printed to the console each time you enumerate the
devices is pretty confusing.
v2: Add constant for number of DRM devices.
Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This had been updated in one place but not the other.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Just noticed this while in the area.
v2: one replacement was incorrect.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We only need one per samples (maybe not even that), reduce
all the unneeded ones.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The existing lowering is in place to lower that to RCP + MUL, or fancier
things down the line if necessary.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Double-precision division, to allow more precision than a DRCP + DMUL
sequence.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This may fix GPU hangs on Gen8. I don't know if it does though.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Everything is in place and the test results look solid.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Renaming data sources was added in
e8bb97ce30
It was possible to use a new name longer than
the name array in hud_graph of 128. This
patch truncates the name to fit the array.
CC: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
It should be close to the GPU load, but it can be much lower if something
is stalling shader execution (e.g. CP DMA).
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
If begin_frame is called before setting intra_matrix and
non_intra_matrix it leads to segmentation faults when
vl_mpeg12_decoder.c is used.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92634
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
In commit 7428e6f86a we switched the barrier SEND message's
destination type to UW to avoid problems in SIMD16 compute shaders.
Tessellation control shaders also use barriers, and in vec4 mode, we
were emitting them in align16 mode. The simulator warns that only UD,
D, F, and DF are valid destination types - UW is technically illegal.
So, switch to align1 mode. Either mode should work fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We were using impl->num_blocks, but that isn't guaranteed to be
up-to-date until after the block_index metadata is required. If we were
unlucky, this could lead to overwriting memory.
Noticed by inspection.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Each physical device may have different extensions than one another.
Furthermore, depending on the software stack, some extensions may not be
accessible.
If an extension is conditional, it can be registered only when
necessary.
v2: removed unused function and fixed indentation
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
All extension arrays are global, but only one of them refers to instance
extensions.
The device extension array refers to extensions that are common across
all physical devices. This disctinction will be more imporant once we
have dynamic extension support for devices.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Queues are independent execution streams. The vulkan spec provides no
ordering guarantees for different queues.
By using a single context for all queues, we are forcing all commands
into an unecessary FIFO ordering.
This change is a preparation step to allow our-of-ordering scheduling of
certain work tasks.
v2: Fix a rebase error with radv_QueueSubmit() and trace_bo
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This fixes glxgears rendering, which had surprisingly been broken since
late October! Specifically, commit 91d61fbf7c.
glxgears uses glShadeModel(GL_FLAT) when drawing the main portion of the
gears, then uses glShadeModel(GL_SMOOTH) for drawing the Gouraud-shaded
inner portion of the gears. This results in the same fragment program
having two different state-dependent interpolation maps: one where
gl_Color is flat, and another where it's smooth.
The problem is that there's only one gen4_fragment_program, so it can't
store both. Each FS compile would trash the last one. But, the FS
compiles are cached, so the first one would store FLAT, and the second
would see a matching program in the cache and never bother to compile
one with SMOOTH. (Clearing the program cache on every draw made it
render correctly.)
Instead, move it to brw_wm_prog_data, where we can keep a copy for
every specialization of the program. The only downside is bloating
the structure a bit, but we can tighten that up a bit if we need to.
This also lets us kill gen4_fragment_program entirely!
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The Vulkan rules for point size are a bit whacky. If you only have a
vertex shader and you use points, then you must write PointSize in your
vertex shader. If you have a geometry or tessellation shader, then it's
dependent on the shaderTessellationAndGeometryPointSize device feature.
From the Vulkan 1.0.38 specification:
"shaderTessellationAndGeometryPointSize indicates whether the
PointSize built-in decoration is available in the tessellation
control, tessellation evaluation, and geometry shader stages. If this
feature is not enabled, members decorated with the PointSize built-in
decoration must not be read from or written to and all points written
from a tessellation or geometry shader will have a size of 1.0. This
also indicates whether shader modules can declare the
TessellationPointSize capability for tessellation control and
evaluation shaders, or if the shader modules can declare the
GeometryPointSize capability for geometry shaders. An implementation
supporting this feature must also support one or both of the
tessellationShader or geometryShader features."
In other words, if the feature is disbled (the client can disable
features!) then they don't write PointSize and we provide a 1.0 default
but if the feature is enabled, they do write PointSize and we use the
one they wrote in the shader. There are at least two valid ways we can
implement this:
1) Track whether or not shaderTessellationAndGeometryPointSize is
enabled and set the 3DSTATE_SF bits based on that and what stages
are enabled, ignoring the shader source.
2) Just look at the last geometry stage VUE map and see if they wrote
PointSize and set the 3DSTATE_SF accordingly.
The second solution is the easiest and the most robust against invalid
usage of the Vulkan API, so we choose to go with that one.
This fixes all of the dEQP-VK.tessellation.primitive_discard.*point_mode
tests. The tests are also broken because they unconditionally enable
shaderTessellationAndGeometryPointSize if it's supported by the
implementation and then don't write PointSize in the evaluation shader.
However, since this is the "robust against invalid API usage" solution,
the tests happily pass. :-)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
