And use this for allocating bo's to hold the shader binary, rather than
accessing the dev via ctx ptr. One step towards making shaders sharable
across contexts.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Commit 65dfb30 added exec_list EmptyUniformLocations, but only
initialized the list if ARB_explicit_uniform_location was enabled,
leading to crashes if the extension was not available.
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions. The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.
Here's the problem scenario:
- Application calls a meta function that generates a name. The first
Gen will probably return 1.
- Application decides to use the same name for an object of the same
type without calling Gen. Many demo programs use names 1, 2, 3,
etc. without calling Gen.
- Application calls the meta function again, and the meta function
replaces the data. The application's data is lost, and the app
fails. Have fun debugging that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
tl;dr: For many types of GL object, we can *NEVER* use the Gen function.
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions. The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.
Here's the problem scenario:
- Application calls a meta function that generates a name. The first
Gen will probably return 1.
- Application decides to use the same name for an object of the same
type without calling Gen. Many demo programs use names 1, 2, 3,
etc. without calling Gen.
- Application calls the meta function again, and the meta function
replaces the data. The application's data is lost, and the app
fails. Have fun debugging that.
Fixes piglit tests:
- object-namespace-pollution glGetTexImage-compressed framebuffer
- object-namespace-pollution glGenerateMipmap framebuffer
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This enables later patches that will stop calling _mesa_GenFramebuffers
or _mesa_CreateFramebuffers which pollute the framebuffer namespace.
For framebuffers, the Bind call is still necessary.
sed -i -e 's/_mesa_GenFramebuffers/_mesa_CreateFramebuffers/' \
src/mesa/drivers/common/*.c
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This enables later patches that will stop calling _mesa_GenFramebuffers
or _mesa_CreateFramebuffers which pollute the framebuffer namespace.
For framebuffers, the Bind call is still necessary.
sed -i -e 's/_mesa_GenFramebuffers/_mesa_CreateFramebuffers/' \
src/mesa/drivers/dri/i965/*.c
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Some meta operations can be called recursively. Future changes (the
"Don't pollute the ... namespace" changes) will cause objects with
invalid names to be used. If a nested meta operation tries to restore
an object named 0xDEADBEEF, it will fail.
This also fixes another latent bug in meta. In a multithreaded,
multicontext application, one thread can delete an object that is bound
in another thread. That object continues to exist until it is unbound
(i.e., its refcount drops to zero). Meta unbinds objects all over the
place. As a result, the rebind in _mesa_meta_end could fail because the
object vanished!
See https://bugs.freedesktop.org/show_bug.cgi?id=92363#c8.
Using _mesa_reference_<object type> to save and restore the objects
prevents the refcount from going to zero.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Fixing dd_function_table::BindFramebuffer will come later because that
change is probably not suitable for stable.
v2: Fix whitespace issue noticed by Topi.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Also change the name of the function to
_mesa_meta_framebuffer_texture_image. The function is basically a
wrapper around _mesa_framebuffer_texture (which is used to implement
glFramebufferTexture1D and friends), so it makes sense for it's name to
be similar to that.
The next patch will clean _mesa_meta_framebuffer_texture_image up
considerably.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
(This is commit 4a1c8a3037 for vec4 mode.)
Using the push model for inputs is much more efficient than pulling
inputs - the hardware can simply copy a large chunk into URB registers
at thread creation time, rather than having the thread send messages to
request data from the L3 cache. Unfortunately, it's possible to have
more TES inputs than fit in registers, so we have to fall back to the
pull model in some cases.
However, it turns out that most tessellation evaluation shaders are
fairly simple, and don't use many inputs. An arbitrary cut-off of
24 vec4 slots (12 registers) should suffice. (I chose this instead of
the 32 vec4 slots used in the scalar backend to avoid regressing a few
Piglit tests due to the vec4 register allocator being too stupid to
figure out what to do. We probably ought to fix that, but it's a
separate issue.)
Improves performance in GPUTest's tessmark_x64 microbenchmark by
41.5394% +/- 0.288519% (n = 115) at 1024x768 on my Clevo W740SU
(with Iris Pro 5200).
Improves performance in Synmark's Gl40TerrainFlyTess microbenchmark by
38.3576% +/- 0.759748% (n = 42).
v2: Simplify abs/negate handling, as requested by Matt.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
in order to make some winsys interface changes easier
This distros should use new DRM if they want to use new Mesa:
Distro kernel mesa eol
SLES 10 2.6.16 6.4.2 2016-07
SLED 11 3.0 9.0.3 2022-03
RHEL 5 2.6.18 6.5.1 2017-03
RHEL 6 2.6.32 10.4.3 2020-11
Debian 6 2.6.32 7.7.1 2016-02
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This can increase perf for shaders that kill pixels (kill, alpha-test,
alpha-to-coverage).
v2: add comments
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
When reusing a depth attachment as a stencil, we need to propogate
the layered bit, otherwise we fail to complete the framebuffer.
discovered running ./bin/fbo-depth-array depth-layered-clear
on virgl on haswell.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Here is another threading issue with MANAGED buffers:
Thread 1: buffer creation
Thread 1: buffer lock
Thread 2: Draw call
Thread 1: writes data
Thread 1: Unlock
Without this patch, the buffer is initially dirty
and in the list of things to upload after its creation.
The draw call will then upload the data and unset the dirty flag,
and the Unlock won't trigger a second upload.
Fixes regression introduced by cc0114f30b:
"st/nine: Implement Managed vertex/index buffers"
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
d3d calls are protected by mutexes, however if app is doing in
two threads:
Thread 1: buffer Lock
Thread 2: Draw call
Thread 1: writes data
Thread 1: Unlock
Then before this patch, the Draw call would begin to upload
the buffer.
Solves this by moving the moment we add the buffer to the queue
of things to upload (We move it from Lock time to Unlock time).
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
When the semantic is Position (which can happen with index 0 only),
use the helper to get Position input.
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Add the virtio-gpu PCI ID for virtio 1.0 (according to the
specification, "the PCI Device ID is calculated by adding 0x1040 to the
Virtio Device ID")
Support for virtio 1.0 was added in qemu 2.4 (same time virtio-gpu
landed).
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This is a very rudimentary script that checks if any of the applied
cherry-picks have been referenced (fixed?) by another patch. With the
latter either missing the stable tag or hasn't yet been picked.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
