Picked from a different branch. When we stop using the scratch patching,
this function will not be called.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
LLVM 3.8:
- had broken indirect resource indexing
- didn't have scratch coalescing
- was the last user of problematic v16i8
- only supported OpenGL 4.1
This leaves us with LLVM 3.9 and LLVM 4.0 support for Mesa 17.2.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
To simplify things for now, since all the gfx shader stages share a
single SSBO state block, only advertise SSBO support for fragment shader
(and compute when we have that). We could possibly use a fixed-
partitioning of the SSBO index space to support SSBOs on other stages
without having to resort to shader variants.
Signed-off-by: Rob Clark <robdclark@gmail.com>
TODO cwabbott pointed out a write-after-read hazzard, which effects both
this and arrays. A write needs to depend on *all* reads since the last
write, not just the last read.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Always true, since the dri modules required shared glapi.
With earlier commit (da410e6afa "configure: explicitly require shared
glapi for enable-dri") we even made that explicit during the configure
stage.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
In the early days of Xorg and Mesa we had multiple providers of the
GLAPI. All of those were the ones responsible for dlopening the DRI
module. Hence it was perfectly fine, and actually expected, for the DRI
modules to have unresolved symbols.
Since then we've moved the API to a separate shared library and no other
libraries provide the symbols.
Here comes the picky part:
It's possible that one uses old Xorg (where libglx.so provides the
GLAPI) and new Mesa (with DRI modules linking against libglapi.so).
That should still work, since the the libglx.so symbols will take
precedence over the libglapi.so ones.
I've verified this while running 1.14 series Xorg alongside this (and
next) patch.
It may seem a bit fragile, but that's of reasonably OK since all of the
affected Xorg versions have been EOL for years.
The final one being the 1.14 series, which saw its final bug fix release
1.14.7 in June 2014.
To ensure that the binaries do not have unresolved symbols add
-no-undefined and $(LD_NO_UNDEFINED), just like we do everywhere else
throughout mesa.
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98428
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This moves the structs from the data segment to the rodata segment,
which seems like the more correct place for them.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No piglit regressions.
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
This will allow Raspbian's ARMv6 builds to take advantage of the new NEON
code, and could prevent problems if vc4 ends up getting used on a v7 CPU
without NEON.
v2: Drop dead NEON_SUFFIX (noted by Erik Faye-Lund)
Android.mk was setting the flag across the entire driver, so we didn't
have non-NEON versions getting built. This was going to be a problem with
the next commit, when I start auto-detecting NEON support and use the
non-NEON version when appropriate.
Reviewed-by: Rob Herring <robh@kernel.org>
I wrote this code with reference to pixman, though I've only decided to
cover Linux (what I'm testing) and Android (seems obvious enough). Linux
has getauxval() as a cleaner interface to the /proc entry, but it's more
glibc-specific and I didn't want to add detection for that.
This will be used to enable NEON at runtime on ARMv6 builds of vc4.
v2: Actually initialize the temp vars in the Android path (noticed by
daniels)
v3: Actually pull in the cpufeatures library (change by robher).
Use O_CLOEXEC. Break out of the loop when we find our feature.
v4: Drop VFP code, which was confused about what it was detecting and not
actually used yet.
Reviewed-by: Grazvydas Ignotas <notasas@gmail.com>
To restart interrupted system calls, use drmIoctl.
Fixes: 848b49b288 ("gallium: add renderonly library")
CC: <mesa-stable@lists.freedesktop.org>
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The renderonly_scanout holds a reference on its prime pipe resource,
which should be released when it is destroyed. If it was created by
renderonly_create_kms_dumb_buffer_for_resource, the dumb BO also has
to be destroyed.
Fixes: 848b49b288 ("gallium: add renderonly library")
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
prime_fd is only used to transfer the scanout buffer to the GPU inside
renderonly_create_kms_dumb_buffer_for_resource. It should be closed
immediately to avoid leaking the DMA-BUF file handle.
Fixes: 848b49b288 ("gallium: add renderonly library")
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
NEON is sufficiently different on arm64 that we can't just reuse this
code. Disable it on arm64 for now.
v2: Use PIPE_ARCH_ARM instead, as __ARM_ARCH may be 8 for a 32-bit build
for a v8 CPU.
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: <mesa-stable@lists.freedesktop.org>
For consistency, similar to the other emitters.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
val_bool and val_int are in a union. val_bool gets the first byte, which
happens to work on LE when setting via the int, but breaks on BE. By
setting the value properly, we are able to use DRI3 on BE architectures.
Tested by running glxgears with a NV34 in a G5 PPC.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
[Emil Velikov: squash the vmwgfx hunk]
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
We do not need to restrict WGL_BIND_TO_TEXTURE_RGB_ARB to
RGB visuals only. It can be supported with RGBA visuals as well.
This fixes the early exit of cinebench-r15-test trace.
Tested with cinebench-r15, piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
If texture is imported and templ format is sRGB, use compatible sRGB format
to the imported texture format while creating surface view.
tested with MTT piglit, glretrace, viewperf and conform
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
This function will return compatible svga srgb format for corresponding
linear format
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
dri3 is a bit sloppy about its format compatibility requirements, so add
a possibility to import xrgb surfaces as argb textures and vice versa.
At the same time, make the svga_texture_from_handle() function a bit more
readable and fix the error path where we leaked a winsys surface.
v2: Addressed review comments by Brian.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Small fetch performance optimization - use gather instruction
for odd format fetch instead of slow emulated code.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Misplaced #endif preventing depth and stencil hot tile pointers
from incrementing in SIMD16 8x2 configuration of BackendPixelRate.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
