Looks good to me. We may need to tighten that up at some point but I
wouldn't know how yet.
Roland
Am 06.02.2015 um 20:08 schrieb Marek Olšák:
> The updated patch is attached. It allows both (0,0,0,0) and (0,0,0,1).
>
> Marek
>
> On Mon, Feb 2, 2015 at 5:19 PM, Roland Scheidegger wrote:
>> Act
The updated patch is attached. It allows both (0,0,0,0) and (0,0,0,1).
Marek
On Mon, Feb 2, 2015 at 5:19 PM, Roland Scheidegger wrote:
> Actually, since ARB_robust_buffer_access_behavior, GL requires some
> specfic values, but it's - odd...
> "In all the above cases, if the context was created w
Interesting. On radeonsi, the default value of an unbound texture can
be chosen but is the same for "load", "sample", and "gather"
instructions. We can't return (0,0,0,0) for "load" and (0,0,0,1) for
"sample".
I'll just modify the test to accept both return values.
Marek
On Mon, Feb 2, 2015 at 5
Actually, since ARB_robust_buffer_access_behavior, GL requires some
specfic values, but it's - odd...
"In all the above cases, if the context was created with robust buffer
access enabled then instead of undefined behavior the result of the
texel fetch is zero. For the case of a texel fetch on an i
I don't think this is really correct. llvmpipe will return all zeros on
purpose, because this is d3d10 behavior (and dummy textures cannot work
correctly with d3d10). Traditionally both d3d9 and gl state trackers
used dummy textures, though I'm unsure what values they required (if
any). (For d3d9 t
From: Marek Olšák
It shouldn't crash the GPU and it should return (0, 0, 0, 1).
This is r300 behavior, so I assume it's also DX9 behavior.
Radeonsi can support this easily.
---
src/gallium/auxiliary/util/u_tests.c | 39
1 file changed, 39 insertions(+)
diff
