This fixes the a build breakage caused by
6974eb9076 on build configurations where
all the following are true:
1. radeonsi is not being built
2. r600g is being built
3. opencl is disabled
4. --enable-r600-llvm-compiler is not being used
5. libelf is not installed
v2:
- Add $(RADEON_CFLAGS) to libllvmradeon_la_CFLAGS
Tested-by: Brian Paul <brianp@vmware.com>
And move its definition into r600_pipe_common.h; This struct is a just
a container for shader code and has nothing to do with LLVM.
v2:
- Drop unrelated Makefile change
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Using DMA for reads is much faster.
Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off by: Marek Olšák <marek.olsak@amd.com>
v2: rotate in gen_rect_verts instead
v3: clear rotate in vl_compositor_clear_layers,
update calc_drawn_area as well
Signed-off-by: Kusanagi Kouichi <slash@ac.auone-net.jp>
Signed-off-by: Christian König <christian.koenig@amd.com>
Fix a leaked vertex shader in u_blitter.c
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
CC: "10.1" <mesa-stable@lists.freedesktop.org>
If scissor optimization is used (to avoid bringing scissored portions of
the render target into GMEM and then back out to system memory) in
combination with hw binning pass, the result would be a scissor mismatch
between binning pass and rendering pass. This would cause rendering
bugs in some scenarios with (for example) gnome-shell.
I would have expected that simply using the correct screen-scissor
during the binning pass would be enough, but seems like there is
something else missing. So for now disable binning pass if scissor
optimization is used.
Because in draw we always inject position at slot 0 whenever
fragment shader would take the maximum number of inputs (32) it
meant that we had PIPE_MAX_ATTRIBS + 1 slots to translate, which
meant that we were crashing with fragment shaders that took
the maximum number of attributes as inputs. The actual max number
of attributes we need to translate thus is PIPE_MAX_ATTRIBS + 1.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Matthew McClure <mcclurem@vmware.com>
draw_current_shader_* functions return a final output when considering
both the geometry shader and the vertex shader. But when code generating
vertex shader we can not be using output slots from the geometry shader
because, obviously, those can be completely different. This fixes a
number of very non-obvious crashes.
A side-effect of this bug was that sometimes the vertex shading code
could save some random outputs as position/clip when the geometry
shader was writing them and vertex shader had different outputs at
those slots (sometimes writing garbage and sometimes something correct).
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Matthew McClure <mcclurem@vmware.com>
r600_translate_colorformat is rewritten to look like radeonsi.
r600_translate_colorswap is shared with radeonsi.
r600_colorformat_endian_swap is consolidated.
This adds some formats which were missing. Future "plain" formats will
automatically be supported.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
To avoid 32-bit integer overflow for large textures. Note: we're
already doing this in llvmpipe.
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
omx_component_library_Setup should return all entrypoints the library
implements, independent of what is available on the current hardware.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74944
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
This is just a simple implementation that stores the extra values into the DRIimage
struct and just uses the fd importer. I haven't looked into what is required
to import YUV or deal with the extra parameters.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The logic to count number of block outputs was out of sync with the
actual array construction. But to simplify / make things less fragile,
we can just allocate the arrays for worst case size.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
A value may be assigned on only one side of an if/else. In this case we
can simply substitute a mov.f32f32.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Add option to generate fragment shader to emulate two sided color.
Additional inputs are added to shader for BCOLOR's (on corresponding to
each COLOR input). CMP instructions are used to select whether to use
COLOR or BCOLOR.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
If vertex writes pointsize, there are a few extra bits we need to turn
on in the cmdstream here and there.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Now that we have the infrastructure for shader variants, add support to
generate an optimized shader for hw binning pass (with varyings/outputs
other than position/pointsize removed). This exposes the possibility
that the shader uses fewer constants than what is bound, so we have to
take care to not emit consts beyond what the shader uses, lest we
provoke the wrath of the HLSQ lockup!
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Fixes anything that tries to use gl_FrontFacing/gl_FragCoord. Also,
face support is needed to emulate two sided color.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
An unused input might not have a register assigned. We don't want bogus
regid to result in impossibly high max_reg..
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This prevents clover from using unsupported devices.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
CC: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
This avoids the kernel driver spewing out errors about the param not being
supported.
Also correct the max surface size used when the kernel does not support the
query.
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Some formats can't be handled - in particular cannot handle ints/uints formats,
which lack the pack_rgba_float/unpack_rgba_float functions. Instead of trying
to call these (and crash) return an error (I'm not sure yet if we should try
to translate such formats too here might not make much sense).
v2: suggested by Jose, use separate checks for pack/unpack of rgba_8unorm and
rgba_float functions (right now if one exists the other should as well).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This makes it easy to compare output between different cards, especially
for ones that you don't have (and/or not in the current machine).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This should pave the way to being able to use the compiler without a
context. Also leads to cleaner code.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
