| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r600, rv610 and rv630 all have a bug in their GPR indexing
and how the hw inserts access to PV.
If the base index for the src is the same as the dst gpr
in a previous group, then it will use PV instead of using
the indexed gpr correctly.
The workaround is to insert a NOP when you detect this.
v2: add second part of fix detecting DST rel writes followed
by same src base index reads.
v3: forget adding stuff to structs, just iterate over the
previous node group again, makes it more obvious.
v3.1: drop local_nop.
Fixes ~200 piglit regressions on rv635 since SB was introduced.
Reviewed-By: Glenn Kennard <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
|
| |
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
| |
This reverts commit 7b0067d23a6f64cf83c42e7f11b2cd4100c569fe.
Vadim's patch fixes this a lot better.
|
| |
|
|
|
| |
32-bit unsigned would require some adjustments to handle values >=
0x80000000.
|
| | |
|
| |
|
|
|
| |
It's only an f16 conversion if you're doing a float operation, otherwise
it's 16 bit signed to 32-bit signed.
|
| | |
|
| |
|
|
| |
There was just way too much indentation.
|
| |
|
|
|
| |
We're actually allocating out of r3 now, and I missed it because I'd typed
this one as qpu_rn(3) instead of qpu_r3().
|
| |
|
|
|
| |
There is an equivalent unpack function without conversion to float if you
use an integer operation instead.
|
| | |
|
| |
|
|
| |
I typoed this when rebasing the memory leak fixes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
They're copied into a vc4_bo after compiling is done.
|
| |
|
|
|
| |
No performance difference on a microbenchmark with norast that should hit it
enough to have mattered, n=220.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the hash_table API required the user to do all of the hashing
of keys as it passed them in. Since the hashing function is intrinsically
tied to the comparison function, it makes sense for the hash table to know
about it. Also, it makes for a somewhat clumsy API as the user is
constantly calling hashing functions many of which have long names. This
is especially bad when the standard call looks something like
_mesa_hash_table_insert(ht, _mesa_pointer_hash(key), key, data);
In the above case, there is no reason why the hash table shouldn't do the
hashing for you. We leave the option for you to do your own hashing if
it's more efficient, but it's no longer needed. Also, if you do do your
own hashing, the hash table will assert that your hash matches what it
expects out of the hashing function. This should make it harder to mess up
your hashing.
v2: change to call the old entrypoint "pre_hashed" rather than
"with_hash", like cworth's equivalent change upstream (change by
anholt, acked-in-general by Jason).
Signed-off-by: Jason Ekstrand <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
|
| |
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
|
| |
|
|
|
|
|
|
| |
A bunch of open-coded 'gpu_id > 300's seems like it will eventually
cause problems with future generations. There were already a few minor
problems with caps for features that still need additional work on a4xx.
Signed-off-by: Rob Clark <[email protected]>
|
| |
|
|
|
|
|
| |
Rather than duplicating this everywhere. Especially as on a4xx the
layout of layers and levels differs based on texture type.
Signed-off-by: Rob Clark <[email protected]>
|
| | |
|
| |
|
|
| |
Android builds Mesa from git, so there don't need to be in the tarball.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
And add d3dadapter9's extra dependency.
|
| | |
|
| |
|
|
|
| |
While the pipe_reference_* helpers set the pointer, a bare pipe_reference
doesn't. Fixes 5 ARB_sync tests.
|
| |
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
| |
This fixes flatshading of backface color in 4 of the piglit interpolation
tests.
|
| |
|
|
| |
This is already done at set_index_buffer() time.
|
| |
|
|
|
| |
When we upload shadow indices at draw time, we need the source offset.
Fixes the piglit draw-elements test.
|
| |
|
|
| |
The original Broadcom driver also did this with the viewport.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because all topologies are reduced to basic primitives (i.e. no strips, fans)
and the vertices involved are all copied, there's no need for any elaborate
decisions where to insert the prim id. The logic employed was correct for
first provoking vertex, but didn't account at all for the last provoking
vertex case. And since we now will get the right constant value even if the
primitive type is later changed (for unfilled etc.) this is no longer
required to pass certain tests (which were checking for prim_id == some
const interpolated value so passing because both were wrong in the end).
This is a bit overkill (3x4 values assigned in total even though it's really
one scalar per prim...) but the code is now much easier and I don't need to
add more cases for last provoking vertex.
This fixes piglit primitive-id-no-gs-strip test.
Reviewed-by: Jose Fonseca <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously the first provoking vertex convention would only be used if
flatshading were enabled. No matter how I look at it that cannot be possibly
correct. Maybe the code getting used was somewhat simpler that way at a time
where there weren't constant interpolated attributes, only flatshading...
(Note that all other places including the decomposition macros already do
the same.)
Reviewed-by: Jose Fonseca <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This stage only worked for traditional old-school flatshading, it did ignore
constant interpolated values and only handled colors, the code probably
predates using of constant interpolated values in gallium. So fix this - the
clip stage apparently did this a long time ago already.
Unfortunately this also means the stage needs to be invoked when flatshading
isn't enabled but some other prim changing stages are - for instance with
fill mode line each of the 3 lines in a tri should get the same attribute
value from the leading vertex in the original tri if interpolation is constant,
which did not happen before
Due to that, the stage is now run in more cases, even unnecessary ones. Could
in theory skip it completely if there aren't any constant interpolated
attributes (and rast->flatshade isn't set), but not sure it's worth bothering,
as it looks kinda complicated getting this information in advance.
No piglit change (doesn't really cover this directly).
Reviewed-by: Jose Fonseca <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Just like we do for tris (det shouldn't matter at this point, however
can have flags for things like line stipple reset).
No piglit change, it would fail line stippling tests if the flatshade
stage were run, which will happen with the next commit.
Reviewed-by: Jose Fonseca <[email protected]>
|
| |
|
|
|
|
|
|
| |
The previous language was a bit misleading, since it sounded like
w was interpolated then the reciprocal calculated which isn't what
should be happening.
Reviewed-by: Jose Fonseca <[email protected]>
|
| |
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
| |
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
| |
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
