From: José Fonseca jfons...@vmware.com
Never used or implemented.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c |1 -
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |1 -
src/gallium/auxiliary/tgsi/tgsi_info.c |2 +-
src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
From: José Fonseca jfons...@vmware.com
TGSI_OPCODE_IF condition had two possible interpretations:
- src.x != 0.0f
- Mesa statetracker when PIPE_SHADER_CAP_INTEGERS was false either for
vertex and fragment shaders
- gallivm/llvmpipe
- postprocess
- vl state tracker
- vega state
You can merge this with the original UIF patch if you want.
---
.../drivers/nv50/codegen/nv50_ir_from_tgsi.cpp |7 ++-
.../drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp |2 +-
.../drivers/nvc0/codegen/nv50_ir_lowering_nvc0.cpp |2 +-
3 files changed, 4 insertions(+), 7
- Original Message -
From: Christoph Bumiller christoph.bumil...@speed.at
This is the only sane solution for nv50 and nvc0 (really, trust me),
but since on other hardware the border colour is tightly coupled with
texture state they'd have to undo the swizzle, so I've added a cap.
Thanks Christoph. Will do.
Jose
- Original Message -
You can merge this with the original UIF patch if you want.
---
.../drivers/nv50/codegen/nv50_ir_from_tgsi.cpp |7 ++-
.../drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp |2 +-
On 14.04.2013 13:44, Jose Fonseca wrote:
- Original Message -
From: Christoph Bumiller christoph.bumil...@speed.at
This is the only sane solution for nv50 and nvc0 (really, trust me),
but since on other hardware the border colour is tightly coupled with
texture state they'd have to
On 14.04.2013 13:50, Jose Fonseca wrote:
- Original Message -
Not to mention the sheer insanity, ugliness and emotional pain incurred
when writing that code when it COULD be so easy and simple in the state
tracker where you know that textures and samplers are tightly coupled,
while
On 14.04.2013 14:33, Christoph Bumiller wrote:
===
In the format description (including swizzle), each color component of
RGBA (as seen by the shader) gets mapped a memory component
{C0,C1,C2,C3} or {ZERO,ONE_INT,ONE_FLOAT}.
When a memory (!) component (Cx) is first encountered when going
The border color in the sampler state is untyped and that's okay. The type
is irrelevant with nearest filtering - just memcpy the border color to the
destination register (if there is swizzling, just do what you do for
texels). With linear filtering, you can always assume it's float
(regardless of
Am 14.04.2013 10:12, schrieb jfons...@vmware.com:
From: José Fonseca jfons...@vmware.com
TGSI_OPCODE_IF condition had two possible interpretations:
- src.x != 0.0f
- Mesa statetracker when PIPE_SHADER_CAP_INTEGERS was false either for
vertex and fragment shaders
-
Yeah it is ok for OpenGL. I guess for d3d10 we'd probably need to create
another sampler if the same sampler is used for both int and float
textures. Or just supply both int and float border colors to the sample
code (but making it work both for opengl and d3d would be ugly). FWIW it
looks like
Oh and btw how does this work for real hw, if the hardware indeed
interpets the border color value according to format?
Are there some bits to set that the border color value is either
interpreted according to format (useful for opengl) or always as float
(useful for d3d10)? Or how else do you use
On Sun, Apr 14, 2013 at 5:24 PM, Roland Scheidegger srol...@vmware.comwrote:
Am 14.04.2013 10:12, schrieb jfons...@vmware.com: - TBD
+ Start an IF ... ELSE .. ENDIF block. Condition evaluates to true if
+
+src0.x != 0.0
+
+ where src0.x is interpreted as a floating point
On 04/13/2013 09:54 PM, Martin Andersson wrote:
On Sat, Apr 13, 2013 at 4:23 AM, Vadim Girlin vadimgir...@gmail.com wrote:
On 04/12/2013 11:36 PM, Martin Andersson wrote:
I have made some progress with this issue.
Vadim, I did as you suggested and tried to mimic the output from the
shader
I think the hardware doesn't care what the border color type is. I think
the border color is fetched from the sampler state, which should be a
memcpy. If no texels are fetched from the texture, the border color is
copied to the destination register. If I set the texture hardware format to
invalid,
The R600 code looks good.
Marek
On Sun, Apr 14, 2013 at 10:12 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
TGSI_OPCODE_IF condition had two possible interpretations:
- src.x != 0.0f
- Mesa statetracker when PIPE_SHADER_CAP_INTEGERS was false either for
Am 14.04.2013 18:55, schrieb Marek Olšák:
I think the hardware doesn't care what the border color type is. I think
the border color is fetched from the sampler state, which should be a
memcpy. If no texels are fetched from the texture, the border color is
copied to the destination register. If
These are few patches that add a new DirectFB native and winsys backend
for the EGL state tracker. This is just about the underlaying infrastructure
that enables DirectFB surface to act as EGL render targets for gallium's
softpipe and llvmpipe sw renderers.
A DirectFB application can now do:
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
configure.ac | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 1c9d606..d74ec94 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1496,7 +1496,7 @@ dnl
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
src/gallium/state_trackers/egl/Makefile.am | 9 +
src/gallium/state_trackers/egl/common/native.h | 3 +
.../state_trackers/egl/directfb/native_directfb.c | 585 +
3 files changed, 597 insertions(+)
create
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
src/gallium/winsys/sw/Makefile.am | 4 +
src/gallium/winsys/sw/directfb/Makefile.am | 31 +++
.../winsys/sw/directfb/directfb_sw_winsys.c| 280 +
Defining EGLNativeWindowType as a pointer on a IDirectFBSurface
enables for configuring EGL to render into a double-buffered
surface which could be offscreen but also primary (visible).
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
include/EGL/eglplatform.h | 6 ++
1 file changed, 6
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
src/egl/main/egldisplay.c | 7 ++-
src/egl/main/egldisplay.h | 1 +
src/gallium/state_trackers/egl/common/egl_g3d.c | 6 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
src/egl/main/Makefile.am | 6 ++
src/gallium/targets/egl-static/Makefile.am | 7 +++
2 files changed, 13 insertions(+)
diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am
index ca5257a..e71b57f 100644
If the border color is 1.0f and the format is integer, I'm not sure if the
behavior is defined in GL, but I think r600 will return 0x3f80, which
is fine.
No, I cannot convert the border color to any other type, because the
original type is UNKNOWN after glTexParameter returns. Also, the
Am 14.04.2013 18:39, schrieb Marek Olšák:
On Sun, Apr 14, 2013 at 5:24 PM, Roland Scheidegger srol...@vmware.com
mailto:srol...@vmware.com wrote:
Am 14.04.2013 10:12, schrieb jfons...@vmware.com
mailto:jfons...@vmware.com: - TBD
+ Start an IF ... ELSE .. ENDIF block.
No, it's not defined in GL. But it doesn't matter there anyway cause you
can't have the same sampler (and hence border color) used for different
textures.
Roland
Am 14.04.2013 19:53, schrieb Marek Olšák:
If the border color is 1.0f and the format is integer, I'm not sure if
the behavior is
The R600 ISA documentation only says that the DX10 variants of MIN and MAX
use DX10 handling of NaNs. It does not say anything about the non-DX10
variants.
Marek
On Sun, Apr 14, 2013 at 8:16 PM, Roland Scheidegger srol...@vmware.comwrote:
Am 14.04.2013 18:39, schrieb Marek Olšák:
On Sun,
Ahh forget about all this.
Thanks to Christoph Bumiller for noticing me that in fact this is a
complete non-issue, since you cannot sample from integer textures _at
all_ with d3d10. Only ld, hence no sampler and no border color...
Looks like OpenGL is a lot more permissive there (which allows you
Ping!
Am Samstag, 6. April 2013, 20:36:50 schrieb Stefan Brüns:
Am Freitag, 22. März 2013, 11:46:52 schrieben Sie:
To call glFoo, the xserver (or libGL) does
(dispatch_table[offset_of_glFoo])(...);
To set the pointer for the glFoo function, the driver does
There is a bug where a BREAK/CONTINUE followed by LOOP_STARTxxx for nested
loops may put the branch stack into a state such that ALU_PUSH_BEFORE
doesn't work as expected. Workaround this by replacing the ALU_PUSH_BEFORE
with a PUSH + ALU for nested loops.
Fixes piglit tests:
spec/!OpenGL
On Sun, Apr 14, 2013 at 2:36 PM, Marek Olšák mar...@gmail.com wrote:
The R600 ISA documentation only says that the DX10 variants of MIN and MAX
use DX10 handling of NaNs. It does not say anything about the non-DX10
variants.
The difference is the NaN behavior. The dx10 versions of MIN/MAX are
On Sun, Apr 14, 2013 at 12:55 PM, Marek Olšák mar...@gmail.com wrote:
I think the hardware doesn't care what the border color type is. I think the
border color is fetched from the sampler state, which should be a memcpy.
If no texels are fetched from the texture, the border color is copied to
Am 14.04.2013 23:44, schrieb Alex Deucher:
On Sun, Apr 14, 2013 at 2:36 PM, Marek Olšák mar...@gmail.com wrote:
The R600 ISA documentation only says that the DX10 variants of MIN and MAX
use DX10 handling of NaNs. It does not say anything about the non-DX10
variants.
The difference is the
On Sun, Apr 14, 2013 at 6:04 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 14.04.2013 23:44, schrieb Alex Deucher:
On Sun, Apr 14, 2013 at 2:36 PM, Marek Olšák mar...@gmail.com wrote:
The R600 ISA documentation only says that the DX10 variants of MIN and MAX
use DX10 handling of NaNs. It
- Original Message -
Am 14.04.2013 10:12, schrieb jfons...@vmware.com:
From: José Fonseca jfons...@vmware.com
TGSI_OPCODE_IF condition had two possible interpretations:
- src.x != 0.0f
- Mesa statetracker when PIPE_SHADER_CAP_INTEGERS was false either for
vertex
On 04/15/2013 01:05 AM, Martin Andersson wrote:
There is a bug where a BREAK/CONTINUE followed by LOOP_STARTxxx for nested
loops may put the branch stack into a state such that ALU_PUSH_BEFORE
doesn't work as expected. Workaround this by replacing the ALU_PUSH_BEFORE
with a PUSH + ALU for nested
From: Roland Scheidegger srol...@vmware.com
Inserting the value for the second quad in the wrong place for the
following shuffle. This meant the row or image stride was undefined which is
quite catastrophic, can lead to bogus texels fetched or just segfault.
This code is only hit for SoA path
38 matches
Mail list logo
