From: Roland Scheidegger srol...@vmware.com
There can be other per-thread data than just vis_counter, so pass a struct
around instead (some of our non-public code uses this already and this
difference is a major cause of merge pain).
---
src/gallium/drivers/llvmpipe/lp_jit.c | 19
From: Roland Scheidegger srol...@vmware.com
This optimized filter (when using repeat wrap modes,
linear min/mag/mip filters, pot textures) only applies to 2d textures,
but nothing prevented it from being used for other textures (likely
leading to very bogus sample results).
Note: This is a
From: Roland Scheidegger srol...@vmware.com
This should handle the new lod_zero modifier more correctly.
The runtime-conditional is a bit more complex however we now also do
scalar lod computation when appropriate which should more than make up for it.
The refactoring should also fix an issue
From: Roland Scheidegger srol...@vmware.com
Need to calculate the number of mip levels (if it would be worthwile could
store it in dynamic state).
While here, the query code also used chan 2 for the lod value.
This worked with mesa state tracker but it seems safer to use chan 0.
Still passes
From: Roland Scheidegger srol...@vmware.com
There were several bugs how this was handled, most opcodes wouldn't even
have fetched the right arguments.
Also, the tex target is coming from the sampler view, hence it cannot
have information about shadow comparisons - fortunately this is not only
From: Roland Scheidegger srol...@vmware.com
They are similar to old-style tex opcodes but with separate sampler and
texture units (and other arguments in different places).
Also adjust the debug tgsi dump code.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |6 +-
From: Roland Scheidegger srol...@vmware.com
Need to calculate the number of mip levels (if it would be worthwile could
store it in dynamic state).
Also, it looks like without modifiers this opcode should return floats
so handle that as well.
While here, the query code also used chan 2 for the lod
From: Roland Scheidegger srol...@vmware.com
The emulation of these if there's no rounding instruction available
is a bit more complicated than what the code did.
In particular, doing fp-to-int/int-to-fp will not work if the exponent
is large enough (and with NaNs, Infs). Hence such values need to
From: Roland Scheidegger srol...@vmware.com
The struct padding got broken by c789b981b244333cfc903bcd1e2fefc010500013.
This caused serious performance regression because part of the key was
unitialized and hence the shader always recompiled (at least on release
builds...).
While here also fix key
From: Roland Scheidegger srol...@vmware.com
Make it obvious what unit this is (no change in functionality).
draw still uses unit in places where it changes the shader by adding
texture sampling itself - it seems like this can't work with shaders
using dx10-style sample opcodes (can't mix gl-style
From: Roland Scheidegger srol...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_state_fs.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c
b/src/gallium/drivers/llvmpipe/lp_state_fs.c
index
From: Roland Scheidegger srol...@vmware.com
We were passing in the rt index however this was always 0 for non-independent
blend case. (The format was only actually used to decide if the color mask
covered all channels so this went unnoticed and was discovered by accident.)
Additionally, there was
From: Roland Scheidegger srol...@vmware.com
Cast back the fake floats to ints, and make sure we don't try to do scaling
in format conversion (which only makes sense with normalized values).
Also need to disable blending and alpha test (as per spec) for such buffers.
This makes fbo-blending from
From: Roland Scheidegger srol...@vmware.com
Now that things mostly seem to work enable those formats.
Some formats cause crashes (notably RGB8 variants) so switch these off
(these crashes are not specific to INT/UINT variants but the state tracker
doesn't use them for UNORM etc. formats so it
From: Roland Scheidegger srol...@vmware.com
Change the texel type to int/uint instead of float throughout the sampling
code which makes it easier to catch errors (as llvm will complain about wrong
types if we mistakenly treat these values as real floats somewhere).
This should also get things
From: Roland Scheidegger srol...@vmware.com
We were passing in the rt index however this was always 0 for non-independent
blend case. (The format was only actually used to decide if the color mask
covered all channels so this went unnoticed and was discovered by accident.)
(Also do some trivial
From: Roland Scheidegger srol...@vmware.com
Change the texel type to int/uint instead of float throughout the sampling
code which makes it easier to catch errors (as llvm will complain about wrong
types if we mistakenly treat these values as real floats somewhere).
This should also get things
From: Roland Scheidegger srol...@vmware.com
Need to bitcast the float border color (luckily we already get
the color as int just disguised as float).
Fixes piglit texwrap GL_EXT_texture_integer bordercolor.
---
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |5 +
1 file changed, 5
From: Roland Scheidegger srol...@vmware.com
We get int/uint clear color value in this case, and util_pack_color can't
handle these formats at all (even if it could, float input color isn't what
we want).
Pass through the color union appropriately and handle the packing ourselves
(as I couldn't
From: Roland Scheidegger srol...@vmware.com
Since the idea is to just expand or shrink the bit width but not otherwise do
conversion we also need to adjust the sign bit according to src, otherwise
the conversion code will incorrectly clamp the values. (Since this only works
for casting to
From: Roland Scheidegger srol...@vmware.com
a460aea3f14222af46f88d1bc686f82180b8a872 wasn't entirely correct,
since all coords are already ints hence need to skip the iround.
Passes piglit texelFetch with sampler1DArray/sampler2DArray.
---
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |5
From: Roland Scheidegger srol...@vmware.com
Since we don't call lp_build_sample_common() in the texel fetch path we missed
the layer fixup code. If someone would have tried to do texelFetch with array
textures it would have crashed for sure.
Not really tested (no overlap of texelFetch and array
From: Roland Scheidegger srol...@vmware.com
we need to rely on util code for fetching those, just like before
9f06061d50f90bf425a5337cea1b0adb94a46d25.
Fixes bugs 57699 and 57756.
---
src/gallium/auxiliary/gallivm/lp_bld_format_aos.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Roland Scheidegger srol...@vmware.com
The border clamping code is unnecessary, since we don't care if a wrapped
coord value is -1 or -1 (same for length vs. length), in either case the
border handling code will mask out the offset and replace the texel value with
the border color.
Note that
601 - 624 of 624 matches
Mail list logo
