Spotted by Coverity.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reported-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Only one of these were recently introduced. However, since
we keep copy/pasting the same wrong indentation we should
probably just fix it.
Reviewed-by: Brian Paul <brianp@vmware.com>
We should not dereference shader before we have done the
null check.
Reviewed-by: Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
From ARB_viewport_array spec:
" * On GL3-capable hardware the VIEWPORT_BOUNDS_RANGE should be at least
[-16384, 16383].
* On GL4-capable hardware the VIEWPORT_BOUNDS_RANGE should be at least
[-32768, 32767]."
This range is set using ctx->Const.MaxViewportWidth value, so just bump
those constants to 32k for gen7+ which can support OpenGL 4.0.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Don't use hardcoded ones because the driver can set different ones.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
While Broadwell is very good about UINT formats, HSW is more restrictive.
Neither R8G8B8_UINT nor R16G16B16_UINT really exist on HSW. It should be
safe to just use the unorm formats.
Now that we are no longer using the pctx reference in the shader, drop
it and turn on shareable shaders.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
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>
The table in prog_instruction.h is correct.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Brian Paul <brianp@vmware.com>
Looks like more never-used crap from the first geometry shader attempt.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Brian Paul <brianp@vmware.com>
Dead since commit d8a366200 in 2010.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Brian Paul <brianp@vmware.com>
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>
