| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
It introduces references to gallium util/ symbols which means we don't get
to include it from outside-of-gallium code.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These act like flt32 except they take up two slots, and you
can only add 2 x flt64 constants in one slot.
The main reason they are different is we don't want to match half a flt64
constants against a flt32 constant in the matching code, we need to make
sure we treat both parts of the flt64 as an single structure.
Cleaned up printing/parsing by Ilia Mirkin <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for a set of double opcodes
to TGSI. It is an update of work done originally
by Michal Krol on the gallium-double-opcodes branch.
The opcodes have a hint where they came from in the
header file.
v2: add unsigned/int <-> double
v2.1: update docs.
v3: add DRSQ (Glenn), fix review comments (Glenn).
v4: drop DDIV
v4.1: cleanups, fix some docs bugs, (Ilia)
rework store_dest and fetch_source fns. (Ilia)
4.2: fixup float comparisons (Ilia)
This is based on code by Michael Krol <[email protected]>
Roland and Glenn also reviewed earlier versions.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
No actual decoding is added, similar faking mechanism to bptc.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
Otherwise for non-default installations the build will fail to find the
headers and error out.
Cc: "10.5" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
With commit c39dbfdd0f7(auxiliary/vl: bring back the VL code for the dri
targets) we did not fully consider users of dri-swrast alone. Thus we
ended up trying to compile the dri2 specific code on platform which lack
it - Cygwin for example.
Cc: "10.5" <[email protected]>
Reported-by: Jon TURNEY <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jon TURNEY <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
To help identify llvmpipe rasterizer threads -- especially when there
can be so many.
We can eventually generalize this to other OSes, but for that we must
restrict the function to be called from the current thread. See also
http://stackoverflow.com/a/7989973
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With commit c642e87d9f4(auxiliary/vl: rework the build of the VL code)
we split out the VL code into a separate static library that was meant
to be used by the VL targets alone - va, vdpau, xvmc.
The commit failed to consider the way we handle vdpau-gl interop and
broke it. Bring back the functionality by keeping the vl <> vl_stub
separation as requrested by Christian.
v2: Update the omx target as well. Update mesa-stable email address.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86837
Cc: "10.5" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Tested-by: Andy Furniss <[email protected]>
|
|
|
|
|
|
|
| |
Convert the code to try formats from an array rather than a bunch
of if/else cases.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88962
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
I wanted all of these for NIR-to-TGSI.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
| |
I wanted to use it for nir-to-tgsi. The equivalent ureg_src_register() is
also located here.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
| |
Reviewed-by: Glenn Kennard <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This expects (0,0,0,0), though it can be changed to something else or allow
more than one set of values to be considered correct.
This is currently the radeonsi behavior.
Reviewed-by: Glenn Kennard <[email protected]>
|
|
|
|
| |
v2: allow one of the two values
|
|
|
|
| |
Reviewed-by: Glenn Kennard <[email protected]>
|
|
|
|
| |
Reviewed-by: Glenn Kennard <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
As ffsll doesn't exist in MSVC yet, and u_bit_scan64 is only used by
radeonsi which is never built with MSVC.
This is just a stop-gap fix to unbreak MSVC build until we refactor these
mathematical portability wrappers into src/util.
Trivial.
|
|
|
|
|
|
| |
Trivial.
(Fixing MSVC will be far less so, as _BitScanForward64 is only supported on x64.)
|
|
|
|
|
|
|
| |
E.g. r600g can use slot 17, which is outside of the API range.
Reviewed-by: Glenn Kennard <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
Same as u_bit_scan, but for uint64_t.
Reviewed-by: Glenn Kennard <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Glenn Kennard <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
Unclear circumstances lead to undefined symbols on x86.
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=536916
Cc: [email protected]
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
| |
The code was exactly the same, except util/ has c++ guards and a struct
simple_node declaration.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
NOTE IN[] and OUT[] don't need (have?) ArrayID's.. and TEMP[] can
optionally have them. So we implicitly assume that ArrayID==0 always
exists for each file. This is why array_max[file] is never less than
zero.
You can tell from indirect_files(_read/written) if the legacy array-
id zero was actually used.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
At least temporarily, I need to fallback to old compiler still for
relative dest (for freedreno), but I can do relative src temp. Only
a temporary situation, but seems easy/reasonable for tgsi-scan to
track this.
Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
| |
|
|
|
|
|
|
| |
v2: move initialization of llvm_gs to declaration.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
| |
Silence warnings about possibly uninitialized variables when making a
release build.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The "normal" detection (querying clflush size) already made sure it is
non-zero, however another method did not. This lead to crashes if this
value happened to be zero (apparently can happen in virtualized environments
at least).
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=87913
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The code used PIPE_ALIGN_VAR for the variable used by fxsave, however this
does not work if the stack isn't aligned. Hence use PIPE_ALIGN_STACK function
decoration to fix the segfault which can happen if stack alignment is only
4 bytes.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=87658.
Cc: "10.4" <[email protected]>
|
|
|
|
|
|
|
| |
v2: Conditionalize it on having done any uploads (Turns out
u_upload_destroy() isn't safe with a NULL arg).
Reviewed-by: Dave Airlie <[email protected]> (v1)
|
|
|
|
|
|
| |
This gets DRI3 working on modesetting with glamor. It's not enabled under
simulation, because it looks like handing our dumb-allocated buffers off
to the server doesn't actually work for the server's rendering.
|
|
|
|
|
|
|
|
|
| |
This reverts db3dfcfe90a3d27e6020e0d3642f8ab0330e57be.
The commit was correct but we've got some precision problems later in
llvmpipe (or possibly in draw clip) due to the vertices coming in in
different order, causing some internal test failures. So revert for now.
(Will only affect drivers which actually support constant-interpolated
attributes and not just flatshading.)
|
|
|
|
|
|
|
| |
Signed-off-by: Timothy Arceri <[email protected]>
Reviewed-By: Jose Fonseca <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
| |
This fixes 4 vertexid related piglit tests with llvmpipe due to switching
behavior of vertexid to the one gl expects.
(Won't fix non-llvm draw path since we don't get the basevertex currently.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Plus a new PIPE_CAP_VERTEXID_NOBASE query. The idea is that drivers not
supporting vertex ids with base vertex offset applied (so, only support
d3d10-style vertex ids) will get such a d3d10-style vertex id instead -
with the caveat they'll also need to handle the basevertex system value
too (this follows what core mesa already does).
Additionally, this is also useful for other state trackers (for instance
llvmpipe / draw right now implement the d3d10 behavior on purpose, but
with different semantics it can just do both).
Doesn't do anything yet.
And fix up the docs wrt similar values.
v2: incorporate feedback from Brian and others, better names, better docs.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
| |
Android builds Mesa from git, so there don't need to be in the tarball.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
f0ba7d897d1c22202531acb70f134f2edc30557d made debug_assert()/assert()
unsafe for expressions, but only now that u_atomic.h started to rely on
them for Windows that this became an issue.
This fixes non-debug builds with MSVC.
Reviewed-by: Brian Paul <[email protected]>
|