The u_format_other.c users sqrtf, which on some systems require
a math-library. So let's make sure we link with it.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes fbo-blending-formats on RGB8 and 565. We will still need to demote
blending to shader code in the MRT case to fix it in general, but that can
be added when we start doing 32F blending (which also needs to be done in
the shader).
The previous packing I did got us all the R*16F and R*32F formats, where
the pipe format basically matched the TLB's format, but since the clear
color will just be memcpyed to the TLB, we should be looking at its format
for deciding how to pack.
Fixes RGB565, RGB5_A1 and RGBA10 fbo-clear-formats tests and improves
4444.
We were storing the resolved pixels in all cases, but nr_samples > 0 means
we should be keeping the per-sample values.
We will probably want to change the job structure at some point, as we'll
want to recognize full-buffer resolves and do the resolved store in the
same job as the original rendering, meaning we'll need to track both the
MSAA and single-sample resources in the job. However, this will be enough
to build the rest of the MSAA support.
The HW has no native sampler support for multisample textures, but since
we only need to support txf_ms and the layout is UIF, we just need to
scale up the texcoords and then add in the sample.
This drops the old TEXTURE_MSAA_ADDR special uniform, since we're treating
MSAA textures as textures, rather than basically texbos like VC4 had to.
We just need to multiply width/height by 2 each, and always set them up as
UIF tiling, since that's how the TLB will store them in raw (per-sample)
mode.
I already had the texture's wrapping set up to use different behavior for
nearest or linear, so we just needed to saturate the coordinates in linear
mode to get the "proper" blend between the edge and border values.
1D is the exception to "all V3D textures are tiled", since tiling 1D
textures would just waste memory and cache space. This ended up being a
problem once we started actually marking 1D textures as 1D instead of 2D.
Like VC4, we need to at least have one element set up, but unlike VC4 it
seems we don't need to read it to keep the HW happy. Fixes GPU hangs with
glsl-no-vertex-attribs.shader_test.
Having moved gallium_dri.so library to /vendor/lib/dri
also symlinks need to be coherently created using TARGET_OUT_VENDOR instead of TARGET_OUT
or all non Intel drivers will not be loaded with Android N and earlier,
thus causing SurfaceFlinger SIGABRT
(v2) simplification of post install command
Fixes: c3f75d483c ("Android: move libraries to /vendor")
Cc: 17.3 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (v1)
Reviewed-by: Rob Herring <robh@kernel.org> (v1)
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Following piglits are passing:
- glean@texture_srgb
- spec@ext_texture_srgb@fbo-srgb
- spec@ext_texture_srgb@tex-srgb
- spec@ext_texture_srgb@texwrap formats
- spec@ext_texture_srgb@texwrap formats-s3tc
Btw. this enables GL 2.1 :-)
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Wladimir J. van der Laan <laanwj@gmail.com>
Culling tris with zero area seems like a great idea, but apparently with
fill mode line (and point) we're supposed to draw them, at least some tests
for some other state tracker complained otherwise.
Such tris also always seem to be back facing (not sure if this can be
inferred from anything, since in a mathematical sense it cannot really be
determined), so make sure to account for this when filling in the face
information.
(For solid tris, this is of course unnecessary, drivers will throw the tris
away later in any case.)
Reviewed-by: Brian Paul <brianp@vmware.com>
This has been tested with the osdemo from mesa-demos
v2: - Add SELinux dependency
- fix typo GALLIUM_LLVM -> GALLIUM_LLVMPIPE
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
These are used by non-gallium osmesa, so they need to be defined outside
of the gallium subdirectory.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Mesa's DEBUG and assert's NDEBUG are not tied to each other, so we need
to explicitly compile this code out.
Fixes: 3df7892878 "vc4: Drop reloc_count tracking for debug
asserts on non-debug builds."
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
It appears that flushing the DB metadata is actually not sufficient
since the driver uses the new VS blit shaders. This looks quite
strange though, but it seems like we need to flush DB for fixing
the corruption.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102955
Fixes: 69ccb9dae7 (radeonsi: use new VS blit shaders (VS inputs in SGPRs)
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
See my LLVM patch which fixes the root cause.
Users have to apply this patch and then they have 2 choices:
- Downgrade to LLVM 5.0
- Update to LLVM git after my LLVM patch is pushed.
It won't be possible to use current and earlier development version
of LLVM 6.0.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: 17.3 <mesa-stable@lists.freedesktop.org>
This should be OUT_RELOC() since the operation isn't writing to the
buffer. Technically it doesn't matter much currently, since we'd
anyways to a gmem2mem later. But that will change.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This was duplicated between both drivers, share here.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
v2: use a more generic compat function
v3: rename and formatting cleanup
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103388
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
CC: <mesa-stable@lists.freedesktop.org>
These assertions were revisited a couple of times in the past, and they
still weren't quite right.
The problem I was seeing (with some other state tracker) was a copy between
two 512x512 s3tc textures, but from mip level 0 to mip level 8. Therefore,
the destination has only size 2x2 (not a full block), so the box width/height
was only 2, causing the assertion to trigger for src alignment.
As far as I can tell, such a copy is completely legal, and because a correct
assertion would get ridiculously complicated just get rid of it for good.
Reviewed-by: Brian Paul <brianp@vmware.com>
Mostly copy/pasta from Dylan Baker's conversion of nouveau and i965.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Similar to 848da66222, pass an arg to
ir3_nir_trig.py to add to python path, rather than using $PYTHONPATH,
to prep for meson build support.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
To enable per-context priorities, we need to have per-context pipe's.
Unfortunately we still need to keep the global screen pipe, mostly just
for screen->get_timestamp().
Signed-off-by: Rob Clark <robdclark@gmail.com>
To add context priority support we need to have an fd_pipe per context,
rather than per-screen. Which conflicts with existing ctx->pipe (which
is actually a visibility stream pipe (hw resource). So just rename it.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of plain snprintf(). To fix the MSVC build.
snprintf() is used in various places in Mesa/gallium, but apparently,
not in code built with MSVC.
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
This restores performance for the drirc workaround, i.e.
KILL_IF does:
visible = src0 >= 0;
kill_flag &= visible; // accumulate kills
amdgcn_kill(wqm_vote(visible)); // kill fully dead quads only
And all helper pixels are killed at the end of the shader:
amdgcn_kill(kill_flag);
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
