OES_geometry_shader has wording to allow xfb when using Draw*Indirect
and DrawElements.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
When passing in GL_RGBA or other base formats, we will try to upgrade
the format to whatever the passed in type was. However not all drivers
(notably nv30) support 32F textures, and so this would lead to crashes
down the line. Only upgrade when the relevant extensions are available.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Otherwise we still have TGSI_OPCODE_CMP's info, which causes a number of
later logic to go wrong. This fixes
dEQP-GLES2.functional.shaders.functions.control_flow.return_in_if_vertex
on nv30.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The mode should stay the same as the original struct. In
particular, shared should not be changed to temporary.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Technically, this was introduced with GL 4.4. However, I believe it
was intended to be retroactive. As far as I know, AMD has never
supported primitive restart with patches, while NVidia and Intel do.
This necessitated the need for a query which would allow applications
to figure out whether this was usable or not.
I decided to expose it everywhere ARB_tessellation_shader is exposed.
(It's also in both OES and EXT_tessellation_shader.)
Enable this for i965 and Gallium drivers which expose the capability.
v2: Fix a bug in the state_tracker code (caught by Ilia Mirkin).
Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=10364
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Some hardware supports primitive restart on patch primitives, and other
hardware does not. Modern GL and ES include a query for this feature;
adding a capability bit will allow us to answer it.
As far as I know, AMD hardware does not support this feature, while
NVIDIA and Intel hardware does. However, most Gallium drivers do not
appear to support tessellation shaders yet. So, I've enabled it for
nvc0 and disabled it everywhere else.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This lets the rest of the backend know that the uniform pull constant
load opcodes don't respect channel enables -- Without this the
register allocator has no way to know that the return payload of a
pull constant load is not per-channel and spills of the destination
will be broken under non-uniform control flow.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Currently the spilling code attempts to guess the scratch message
block size from the dispatch width of the shader, which is plain wrong
for SIMD-lowered instructions (frequently but not exclusively
encountered in SIMD32 shaders) or for instructions with register
region data types of size other than 32 bit.
Instead try to use the SIMD component size of the instruction which in
some cases will allow the dataport to apply the correct channel mask
to the scratch data read or written. In the spill case the block size
needs to be clamped to the number of MRF registers reserved for
spilling. In the unspill case I didn't even bother because we
currently have no 100% accurate way to determine whether a source
region is per-channel or whether it contains things like headers that
don't respect channel boundaries -- That's fine, because the unspill
is marked force_writemask_all we can just use the largest allowable
scratch message size.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This prevents the application of an incorrect channel mask by the
scratch write instruction for spilled variables that don't have an
exact one-to-one correspondence between channels of the variable and
32-bit components of the scratch write instruction.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This makes sure that unspills restore the exact contents of the
variable in scratch space into the GRF without applying channel
masking, which is incorrect under control flow for things like message
headers or vectors of heterogeneous types that don't properly respect
channel boundaries.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This makes emit_(un)spill even more stupid by removing the logic that
decides what execution size each scratch read or write send message
should have and instead relying on the caller to specify an
appropriate execution size via the builder argument. This makes sense
because the caller will need to act differently based on the scratch
message width (e.g. emit an additional unspill before the instruction
if the execution width and channel layout of the spill doesn't match
the instruction's).
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This seems cleaner than exposing an implementation detail of
brw_fs_reg_allocate.cpp to the world, and will give the caller control
over the instruction execution flags (e.g. force_writemask_all) that
are applied to the scratch read and write instructions.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Until now the execution controls (e.g. channel group,
force_writemask_all, exec_size) of the instruction had been completely
ignored by spilling, even though that can lead to a mismatch between
the channel mask applied to the contents of the (un)spilled memory and
the GRF source or destination of the instruction. In some cases we'll
actually want the (un)spill messages to be marked force_writemask_all
regardless of whether the instruction has it set, but that will have
to be handled specially by the caller.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And as we're at it fix the calculation to allocate a larger block of
registers for 32-wide dispatch.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
According to the EGL specifications eglQueryString(EGL_CLIENT_APIS)
should return a string containing a combination of "OpenGL", "OpenGL_ES"
and "OpenVG", any other values would be considered invalid. Due to this
when the API string is constructed, the version of GLES should be
disregarded and "OpenGL_ES" should be attached once instead of
"OpenGL_ES2" and "OpenGL_ES3".
Fixes:
dEQP-EGL.functional.negative_api* and
dEQP-EGL.functional.query_context.simple.query_api
Signed-off-by: Plamena Manolova <plamena.manolova@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
The variable-indexing tests always had a few random fails, which I
usually couldn't reproduce when running tests manually. Somehow
recently this got a lot worse. I ported a couple of the shaders to
GLES to see what blob does, and it also seems to be avoiding to cp
indirect srcs. So I guess indirect w/ instructions other than cat1
(mov) are not totally reliable. Let's just switch that off until
this is better understood.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Constbufs are only aliased on Fermi and this will reduce the number of
flushes when we switch between 3d and compute.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
/system/vendor/lib/dri/*_dri.so actually depend on libglapi: without
this, loading the so file fails with:
cannot locate symbol "__emutls_v._glapi_tls_Context"
On non-Android (non-bionic) platform, EGL uses the following
workflow, which works fine:
dlopen("libglapi.so", RTLD_LAZY | RTLD_GLOBAL);
dlopen("dri/<driver>_dri.so", RTLD_NOW | RTLD_GLOBAL);
However, bionic does not respect the RTLD_GLOBAL flag, and the dri
library cannot find symbols in libglapi.so, so we need to link
to libglapi.so explicitly. Android.mk already does this.
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
[Emil Velikov: s/explicitely/explicitly/]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Add support for EGL android platform.
Also, detect when --host finishes with -android. In that case, we
do not set _GNU_SOURCE, and define autoconf symbol HAVE_ANDROID, so
that Android-specific workarounds can be applied.
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
[Emil Velikov: Rebase on top of HAVE_EGL_PLATFORM_NULL removal]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The build systems already add this as applicable. There's no need to
have this in the source file.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The build systems already add this as applicable. There's no need to
have this in the source file.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The build systems already add this as applicable. There's no need to
have this in the source file.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Bounds of screen are 0 (inclusive) and ScreenCount(dpy) (exclusive).
The upper bound was too ScreenCount(dpy) (inclusive).
This causes a crash invoked by java3d which passes down an invalid
screen:
6 0x00007f0e5198ba70 in <signal handler called> () at /lib64/libc.so.6
7 0x00007f0e14531e14 in glXGetFBConfigs (dpy=<optimized out>, screen=1, nelements=nelements@entry=0x7f0dab3c522c) at glxcmds.c:1660
8 0x00007f0e14532f7f in glXChooseFBConfig (dpy=<optimized out>, screen=<optimized out>, attribList=0x7f0dab3c54e0, nitems=0x7f0dab3c535c) at glxcmds.c:1611
9 0x00007f0e1478d29b in find_S_FBConfigs () at /usr/lib64/libj3dcore-ogl.so
10 0x00007f0e1478d3dc in find_S_S_FBConfigs () at /usr/lib64/libj3dcore-ogl.so
11 0x00007f0e1478d567 in find_AA_S_S_FBConfigs () at /usr/lib64/libj3dcore-ogl.so
12 0x00007f0e1478d728 in find_DB_AA_S_S_FBConfigs () at /usr/lib64/libj3dcore-ogl.so
13 0x00007f0e1478d97c in Java_javax_media_j3d_X11NativeConfigTemplate3D_chooseOglVisual () at /usr/lib64/libj3dcore-ogl.so
While ScreenCount(dpy) is actually 1:
(gdb) p dpy->nscreens
$2 = 1
screen=1 is passed to glXGetFBConfigs.
Fix this typo in glXGetFBConfigs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95456
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Some platforms require separate library in order to resolve the
clock_gettime() symbol. Add the link or the build will fail.
Fixes: 70299474f5 ("egl: add EGL_KHR_reusable_sync to egl_dri")
Cc: Dongwon Kim <dongwon.kim@intel.com>
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The DRI flush extension should already do the same thing.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Rob Herring <robh@kernel.org>
Make the function non static so that we can use it directly from the
android platform code.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Add separate labels and jump to the correct one as needed.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
3d0fac7aca changed all
VK_PROTOTYPES to VK_NO_PROTOTYPES
This brings the Intel header in line with the rest of the Vulkan code.
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
This adds map and unmap functions to GBM utilizing the DRIimage extension
mapImage/unmapImage functions or existing internal mapping for dumb
buffers. Unlike prior attempts, this version provides a region to map and
usage flags for the mapping. The operation follows the same semantics as
the gallium transfer_map() function.
This was tested with GBM based gralloc on Android.
Signed-off-by: Rob Herring <robh@kernel.org>
[Emil Velikov: drop no longer relevant hunk from commit message.]
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Add pthreadstubs to avoid pulling in full pthreads library. GBM will be the
first user.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
In preparation to add public map/unmap functions, rename the existing
gbm_dri_bo_{map,unmap} functions to indicate that they are only for dumb
buffers.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Implement support for mapImage/unmapImage functions in version 12 of the
DRIimage extension.
Signed-off-by: Rob Herring <robh@kernel.org>
[Emil Velikov: align/indent the map/unmap vfuncs]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Add mapImage and unmapImage functions to DRIimage extension for mapping
and unmapping DRIimages for CPU access. The caller provides the region of
the image to map and is returned a pointer to the beginning of the region
and the stride (which could be different from the original).
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
In order to use libgbm for gralloc, add it to the Android build.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
GBM needs the same special gallium_dri.so loading as EGL for Android, so
copy over the same hunk from the EGL code.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
In preparation to add Android build support, split out the source file
lists to Makefile.sources
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
[Emil Velikov: Whitespace cleanup.]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the defining of DEFAULT_DRIVER_DIR path to a common location so both
EGL and GBM can use it.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
If the mutexattrs are the default one can just pass NULL to
pthread_mutex_init. As the compiler does not know this detail it
unnecessarily creates/destroys the attrs.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This fixes a recent linking error in libvulkan_common
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
From the GL 4.5 core spec, section 11.1.1 (Vertex Attributes):
"A program with more than the value of MAX_VERTEX_ATTRIBS
active attribute variables may fail to link, unless
device-dependent optimizations are able to make the program
fit within available hardware resources. For the purposes
of this test, attribute variables of the type dvec3, dvec4,
dmat2x3, dmat2x4, dmat3, dmat3x4, dmat4x3, and dmat4 may
count as consuming twice as many attributes as equivalent
single-precision types. While these types use the same number
of generic attributes as their single-precision equivalents,
implementations are permitted to consume two single-precision
vectors of internal storage for each three- or four-component
double-precision vector."
This commits makes dvec3, dvec4, dmat2x3, dmat2x4, dmat3, dmat3x4,
dmat4x3 and dmat4 consume twice as many attributes as equivalent
single-precision types.
v3: count doubles as consuming two attributes (Dave Airlie)
v4: make reference to spec (Michael Schellenberger Costa)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Antia Puentes <apuentes@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
The previous implementation relied on the std140 alignment rules to
avoid handling misalignment in the case where we are loading more than
2 double components from a vector, which requires to emit a second load
message.
This alternative implementation deals with misalignment and is more
flexible going forward.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
I think these are not strictly necessary since the floats in them
should be automatically promoted to doubles when operated with
double sources, but it makes things more explicit at least.
Reviewed-by: Matt Turner <mattst88@gmail.com>
