This got broken by 3dbf5bf657.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all the color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out the color
mapping).
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
accel_working2 returns 3 if the new firmware is used.
The comment wasn't updated in v3 of commit:
36771dc winsys/radeon: fix nop packet padding for hawaii
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Fixes piglit glean "do-loop with continue and break" on RS690
It's based on Tom Stellard patch and improved to handle CMP instruction.
[v2] handle CMP instruction
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: David Heidelberger <david.heidelberger@ixit.cz>
We were leaking the input buffer used for kernel arguments and since
we were allocating it using si_upload_const_buffer() we were leaking
1 MB per kernel invocation.
CC: "10.2" <mesa-stable@lists.freedesktop.org>
This will decrement the reference count for buffers referenced in the
command stream will prevent us from leaking them.
CC: "10.2" <mesa-stable@lists.freedesktop.org>
There is a hard limit in older kernels of 256 MB for buffer allocations,
so report this value as MAX_MEM_ALLOC_SIZE and adjust MAX_GLOBAL_SIZE
to statisfy requirements of OpenCL.
CC: "10.2" <mesa-stable@lists.freedesktop.org>
Before, when we encountered a situation where we had to optimistically
color a node, we would immediately give up and push all the remaining
nodes on the stack in the order of their index - which is a random, and
potentially not optimal, order. Instead, choose one node to
optimistically color in ra_select(), and then once we've optimistically
colored it, keep on going as normal in the hopes that we've opened up
more avenues for the normal select phase to make progress. In cases with
high register pressure, this helps make the order we push things on the
stack much better, and therefore increase the chance that we can allocate
successfully.
total instructions in shared programs: 4545447 -> 4545401 (-0.00%)
instructions in affected programs: 1353 -> 1307 (-3.40%)
GAINED: 124
LOST: 6
Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, we would consider any optimistically colored nodes for
spilling. However, spilling any optimistically colored nodes below the
node that we failed to color on the stack wouldn't help us make
progress, since it wouldn't help with allowing us to find a color for
the node currently failing to get colored. Only consider nodes
which were above the failing node on the stack for spilling, which
simplifies the logic, and comment the code better so people know what's
going on here.
No shader-db changes with BRW_MAX_GRF reduced to 90 (or with the normal
number of GRF's).
Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We can store the q total that pq_test() would've calculated in the node
itself, updating it when we add a node to the stack. This way, we only
have to walk the adjacency list when we push a node on the stack (i.e.
when the p, q test succeeds) instead of every time we do the p, q test.
No difference in shader-db run times, but I'm keeping this in because
the q total that it calculates will also be used in the next few commits.
Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, there were 3 entrypoints into parts of the actual allocator,
and an API called ra_allocate_no_spills() that called all 3. Nobody
would ever want to call any of the 3 entrypoints by themselves, so
everybody just used ra_allocate_no_spills(). So just make them static
functions, and while we're at it rename ra_allocate_no_spills() to
ra_allocate() since there's no equivalent "with spills," because the
backend is supposed to handle spilling.
Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This would try to allocate 0-sized bo's when the max level was below the
base level.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The ARB_gpu_shader5 extension is made up of a lot of small sub-parts.
Instead of adding PIPE_CAP's for each of these, just rely on the GLSL
version reported by the pipe driver. The remaining extensions lend
themselves naturally to being checked through a single CAP.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Will make it easier on us as CleanSpec.mk comes along and improves
consistency across the Android build.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Will make it easier on us as CleanSpec.mk comes along and improves
consistency across the Android build.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Saves us a few lines and brings us closer to the automake build.
Drop DRM_TOP as it's not longer used.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Trying to get rid of the hardcoded dependency of DRM_TOP which
expects that mesa is localted in /external/drm. Will
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The variable i915_C_FILES changed to i915_FILES with commit
34d4216e64 back in mesa 9.1/9.2. Yet we've missed to update the
the android build, essentially creating an dummy/empty driver that
can never work.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
When the compiler is not capable/does not accept -msse4.1 while the target
has the instruction set we'll blow up as _mesa_streaming_load_memcpy is
going to be undefined.
To make sure that never happens, wrap the runtime cpu check+caller in an
ifdef thus do not compile that hunk of the code.
Fix the android build by enabling the optimisation and adding the define
where applicable.
v2: autoconf conditionals end with "fi" rather than endif.
v3: Wrap the definition and call to intel_miptree_{un,}map_movntdqa in
if defined(USE_SSE41). Spotted by Matt.
Cc: Matt Turner <mattst88@gmail.com>
Cc: Adrian Negreanu <adrian.m.negreanu@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The latter lacks various functionality used by mesa/glsl.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Upstream Android (system/core) has dropped these formats with commit
6bac41f1bf9(get rid of HAL pixelformats 5551 and 4444) yet does not
mention why.
These formats never really worked so we're safe to drop them as well.
Identical commit is available in the android-x86 external/mesa repo
commit 06a2d36edc
Author: Chih-Wei Huang <cwhuang@linux.org.tw>
Date: Wed Sep 25 01:16:57 2013 +0800
android: get rid of HAL pixelformats 5551 and 4444
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Recent versions of bionic has picked up support for these functions,
leading to build issues due to the redefition of the symbols.
Note: wrapping things in #ifdef does not cut it :\
Identical patch is available in chromium, android-x86 and perhaps other
projects.
commit 66c1c789ce3407472de9ed620c9f815639058835
Author: rmcilroy@chromium.org
Date: Wed Apr 02 10:59:34 2014 +0000
Porting to x64 Android. Remove redefinitions of log2 and log2f.
BUG=
R=kbr@chromium.org
Review URL: https://codereview.chromium.org/216773005
commit 9cc0a0d2b0
Author: Chih-Wei Huang <cwhuang@linux.org.tw>
Date: Sun Jul 21 23:04:19 2013 +0800
android: remove log2, log2f
The functions are already defined in the latest bionic.
Cc: Chia-I Wu <olvaffe@gmail.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Chia-I Wu <olvaffe@gmail.com>
Android build never really installs the headers, as such we need to
explicitly add their location in the source tree otherwise it will
fail to find them.
v2: Android now installs the headers, so let's use that ;)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Considering the way we've been consolidating things it makes
sense to add the final two (aux and tests) in here.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Yet another makefile less to worry about.
v2: Add state_trackers and targets on a single SUBDIRS line.
Requested by Matt.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
One makefile less, with the potential of further compacting the
automake build.
v2: Rebase on top of vc4 changes.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Rather than having two separate almost empty and identical makefiles,
compact them thus improving the configure and build time.
Additionally this makes the automake build symmetrical to the scons
and android one.
v2: Rebase on top of vc4, compact drivers + winsys on a single line.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
For all everyone willing to give the freedreno driver
a go they can now build it under Android.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Cc: Rob Clark <robclark@freedesktop.org>
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
For all the people interested in testing the freedreno driver on
their Android devices. The next commit will hook these up within
the libEGL driver (via the gallium-egl backend).
There may be some rough edges but those can be sorted when a
willing builder/tester comes along.
v2:
- s/freefreno/freedreno/. Spotted by Matt Turner.
- Use the installed libdrm headers.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Cc: Rob Clark <robclark@freedesktop.org>
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Rather than including two extra folders only for two headers,
just prefix the headers and be done with it.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Cc: Rob Clark <robclark@freedesktop.org>
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
- link against libdrm_radeon
- link the r600 driver against libstlport
- linkin the newly added libmesa_pipe_radeon library
required by r600 and radeonsi drivers
v2: Include pipe_radeon after pipe_r600/radeonsi.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
[Emil Velikov] Split up and add commit message.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
- include the correct folders
- add a new buildscript for the common radeon folder
v2: Use the installed libdrm headers over the DRM_TOP ones.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
[Emil Velikov] Split up and add commit message.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
For a while the nouveau pipe driver has been a static library
and it has been using STL for even longer.
Correct add the link and cleanup the gallium_DRIVERS.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
nouveau uses STL for a while now thus we need to include
external/stlport/libstlport.mk in order to get the build
at least partially working.
v2: Use the installed libdrm headers over the DRM_TOP ones.
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Rather than having the sources list duplicated across all three
build systems, define it once and use it whenever needed.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
