On Wednesday, August 24, 2011 10:14:48 PM Bryan Cain wrote:
Like Dave said, the GLSL-TGSI translator needs to account for this.
Probably not, at least yet. All of those instructions are DX10.1 level
instructions which support splitting of samplers and the underlaying resource,
we don't support
On Thursday, August 25, 2011 04:30:26 PM Christoph Bumiller wrote:
Putting the resource type in the resource declaration instead of the
instruction isn't necessarily smart considering indirect resource access
... I just hope the person implementing it remembers to provide a base
array address
On Thursday, August 25, 2011 04:42:21 PM Christoph Bumiller wrote:
Of course -4 isn't a valid resource, I just meant to emphasize that I
cannot tell at all the resource to be accessed.
ADDR[0].x - 4 should of course be = 0 and valid.
And, maybe it seems silly to you, but OpenGL allows it.
On Monday, August 29, 2011 03:49:03 PM Bryan Cain wrote:
I somehow didn't notice this until now, but why are there no Gallium
set opcodes for integers that are equivalent to the SGT or SLE opcodes
for floats? Does it have to do with available hardware features?
It's largely because D3D10 only
On Monday, August 29, 2011 04:02:08 PM Zack Rusin wrote:
Either way though if GL needs those ops then, like Brian mentioned, it'd be
a good idea to add them.
Actually I think it seems easier to just flip the ops rather than add new
instructions, i.e. change stuff like a b, to b a, and a = b
On Thursday, October 06, 2011 04:58:45 PM Marek Olšák wrote:
I am cc'ing Zack, because he was the one to design the first interface.
Hi Marek.
I'm swamped right now and won't have time to review the patches. FWIW, the
interface initially did have the stream output data in the shader state,
branch.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/glx/dri2_glx.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 1b3cf2b..a51716f 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -1062,8 +1062,9
it for drivers
which are known to not support it. It makes sense because
most drivers do support it right now.
We'll be able to remove this once Xserver properly advertises
GLX_INTEL_swap_event.
Note: This is a candidate for the 9.0 branch.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/glx
Seems like we should also fix the server to not advertise the extension
if the driver doesn't have the appropriate hooks implemented. But I
have no problem with doing this on the client side too.
I've sent a patch last night to xorg-devel to handle it. But since it's likely
to only be
Should we also test for the swrast driver?
That is actually handled by a hack in the Xserver.
http://cgit.freedesktop.org/xorg/xserver/commit/glx?id=988d7ace19a009991a4528e783d1a94c2444c66a
The extension was manually removed from the list of extensions that are at all
available to the software
shaders.
Bryan Cain (3):
draw/gs: fix allocation of buffer for GS output vertices
draw: account for separate shader objects in geometry shader code
draw: use geometry shader info in clip_init_state if appropriate
Zack Rusin (1):
draw/llvm: fix inputs to the geometry shader
src/gallium
From: Bryan Cain bryanca...@gmail.com
Before, it accounted for the size of the vertices but not the other fields
in the vertex_header struct, which caused memory corruption.
Reviewed-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c |3 ++-
1 file changed, 2
We can't clip and viewport transform the vertices before we let
the geometry shader process them. Lets make sure the generated
vertex shader has both disabled if geometry shader is present.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 15
shaders and our indexes
would get completely messed up.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi
If geometry shader is present its stream output info should
be used instead of the vs and we shouldn't use the pre-clipped
corrdinates.
Signed-off-by: Zack Rusin za...@vmware.com
---
.../draw/draw_pt_fetch_shade_pipeline_llvm.c |2 +-
src/gallium/auxiliary/draw/draw_pt_so_emit.c
If ddx does not support swap, don't advertise it. We might also be
able to get rid of the vmwgfx check (I'm not quite sure the purpose of
that check vs. just checking dri2Minor.
No, not really. GLX_INTEL_swap_event doesn't have any hooks. You're checking
for presence of generic swap
well, from what I can tell, if you advertise this extension
applications will expect a swap event. Which will never come if
dri/glx on client side remaps scheduleswap to copyregion.
So maybe there are other conditions where we should not advertise this
extension. But if we know we will
hmm, well, I think my fix is not incorrect.. we can tell from dri2
proto version that the xserver does not support ScheduleSwap. Maybe
there should be other conditions where we also don't advertise this
extension, but this patch still improves things. If we absolutely
know from the dri2
well, I'm more familiar w/ EGL where we don't have the xserver
advertising anything, and it is all on the client side.. but when it
is an inexpensive check, it seems reasonable to want mesa to do the
right thing where possible.
It's simply silly. In the same sense that adding yet another if
A few tests were missing this crucial property.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/tests/graw/geometry-shader/add-mix.txt |1 +
src/gallium/tests/graw/geometry-shader/add.txt |1 +
src/gallium/tests/graw/geometry-shader/mov-cb-2d.txt |1 +
src/gallium
we were missing implementation of the breakc instruction and our
TGSI semantics currently require an implicit endprim at the end
of GS if none is present - this implements both.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h|6
src
in the common code so we can push it now.
Zack Rusin (6):
graw/gs: add missing max output vertices to all tests
draw/llvm: Remove unused gs_constants from jit_context
draw/gs: Abstract the portions of GS that are tgsi specific
draw/gs: Fetch more than one primitive per invocation
gallium/llvm
The member was never used and we'll need to handle it differently
because gs will also need samplers/textures setup.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c| 17 +++--
src/gallium/auxiliary/draw/draw_llvm.h
To be able to add llvm paths later on we need to have some common
interface for them.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c | 270 ++
src/gallium/auxiliary/draw/draw_gs.h | 14 ++
2 files changed, 156 insertions
Allows executing gs on up to 4 primitives at a time. Will also be
required by the llvm code because there we definitely don't want
to flush with just a single primitive.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c | 54
A few cleanups, plus fixes for texture sampling for the llvm
geometry shaders. This is on top of the previous patchset.
Zack Rusin (3):
draw: Allocate the output buffer for output primitives
draw/llvm: Cleanup the store debugging code
llvmpipe/draw: Fix texture sampling in geometry shaders
We were allocating the output buffer but using the input
primitives. We need to allocate that buffer using the
maximum number of output, not input, primitives.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c |3 +--
1 file changed, 1 insertion(+), 2
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 1b0b1b9..f857183 100644
--- a/src
We weren't correctly propagating the samplers and sampler views
when they were related to geometry shaders.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c |4 +-
src/gallium/auxiliary/draw/draw_llvm.c | 83 ---
src
Wow, that's a lot of code to digest, but it looks good AFAICT (without
spending hours on it). I just found some minor nits.
Nice work!
Reviewed-by: Brian Paul bri...@vmware.com
Thanks Brian! I'm sorry about the large patch, it was one of those just sit
down and do it types of coding
Instead of void pointers use a base interface.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 77 ---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 25
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 31
We were flushing with incorrect number of primitives. TGSI exec
can only work with a single primitive at a time. Plus the fetching
with multiple primitives on llvm paths wasn't copying the last
element.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c | 25
We do support so with multiple primitives.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_so_emit_tmp.h |1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
b/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
index
We do support so with multiple primitives.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_so_emit_tmp.h |1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
b/src/gallium/auxiliary/draw/draw_so_emit_tmp.h
index
We were largely ignoring primitive id.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c| 20 +++-
src/gallium/auxiliary/draw/draw_gs.h|1 +
src/gallium/auxiliary/draw/draw_llvm.c | 15 +--
src
It's quite helpful during the rendering when we know
exactly the count of the vertices available in the
buffer.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.h|1 +
src/gallium/auxiliary/draw/draw_pt.c | 18 +++---
src
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c |4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_gs.c
b/src/gallium/auxiliary/draw/draw_gs.c
index b98b133..70db837 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
I think this was there before and got accidently
removed during a merge. Same code as for the GS
context, which is also using an enum instead of
hardcoded numbers.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c |8
src/gallium/auxiliary/draw
we use draw_set_mapped_so_targets nowadays
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c |7 ---
src/gallium/auxiliary/draw/draw_context.h |5 -
2 files changed, 12 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_context.c
b
We need to reset the internal state of the so buffers or we'll
keep appending even though we're not supposed to.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_state_so.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe
vertex shader and llvmpipe
resolves at draw time which vertex shader the given empty geometry
shader should be linked to.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c |9 -
src/gallium/auxiliary/draw/draw_context.h |7
It's part of SM4 (http://goo.gl/4IpeK). It's also fairly
painful to emulate without branching. Most hardware
supports it natively and even llvm has a 'select' opcode
which can handle it without too much hassle.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm
On 04.04.2013 03:45, Zack Rusin wrote:
It's part of SM4 (http://goo.gl/4IpeK). It's also fairly
painful to emulate without branching. Most hardware
supports it natively and even llvm has a 'select' opcode
which can handle it without too much hassle.
diff --git a/src/gallium/docs
Erm, unsigned 0 doesn't make sense.
Ah indeed!
Definitely what the description says:
static void
micro_ucmp(union tgsi_exec_channel *dst,
const union tgsi_exec_channel *src0,
const union tgsi_exec_channel *src1,
const union tgsi_exec_channel
Hah, yea, I'm sorry, that's a good point. So movc is a bitcast to unsigned
followed by ucmp. Alright, I'm withdrawing the patch.
z
- Original Message -
- Original Message -
Erm, unsigned 0 doesn't make sense.
Ah indeed!
Definitely what the description
and add a test for it
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 21
.../tests/graw/fragment-shader/frag-ucmp.sh| 11 ++
2 files changed, 32 insertions(+)
create mode 100644 src/gallium/tests/graw
we break when the mask values are 0 not, 1, plus it's bit comparison
not a floating point comparison. This fixes both.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 26 ---
1 file changed, 14 insertions(+), 12 deletions
We want to both make sure we never divide by zero to not generate
sigfpe and that divide by zero is guaranteed to return 0x.
Based on José idea.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 29 +---
1 file changed
We were missing the implementation of PIPE_QUERY_SO_STATISTICS
query, this change implements it on top of the existing
facilities.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_query.c | 19 +++
src/gallium/drivers/llvmpipe/lp_rast.c |3
across
conditionals.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |6 +-
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 118 ---
2 files changed, 105 insertions(+), 19 deletions(-)
diff --git a/src/gallium/auxiliary
both mov and ucmp can be used to move variables of any type.
correctly note that about ucmp in the tgsi_info and make
sure gallivm can handle that by correctly casting the untyped
moves.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |8
Same as with llvmpipe: we can't be divind/moding by zero and we
need to make sure that dividing/moding by zero produces 0x.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff
which means that our execution mask in GS is equal to 1 not 0xf.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b
instrunctions correctly? From my quick glance it seems
to be ok, but I don't know those codebases at all.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 10 --
src/gallium/auxiliary/tgsi/tgsi_info.c |2 ++
src/gallium/docs
What about drivers without integer support? The IF instruction should have 2
definitions: one for the drivers which support PIPE_SHADER_CAP_INTEGERS, and
the other one for those which don't. Obviously, there is no way to change
the behavior of the IF opcode if you only have floats.
I think in
- Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is the proof of it.
We really should have two IF opcodes. And the state tracker should choose
- Original Message -
- Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is the proof of it.
We really should have two IF
the pipeline statistics capability
though because llvmpipe is lacking gathering of the fragment shading
and rasterization statistics.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c | 16 +
src/gallium/auxiliary/draw/draw_context.h |7
conditions. Now we're combining the
execution mask with a mask created from emitted vertices to handle
both cases. As a result we don't need the pending_end_primitive
flag which was broken because it was static and could be affected
by both above mentioned conditions at run-time.
Signed-off-by: Zack Rusin
- Original Message -
I wonder if, instead of sending statistics down the pipe with through vbuf,
it would be simpler to just have
void draw_statistics_start(struct draw_context *draw)
void draw_statistics_end(struct draw_context *draw,
struct
Can happen if we were using stream output without geometry
shader, by returning early we avoid a crash.
---
src/gallium/auxiliary/draw/draw_gs.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/auxiliary/draw/draw_gs.c
b/src/gallium/auxiliary/draw/draw_gs.c
index
The specification says that the geometry shader should exit if the
number of emitted vertices is bigger or equal to max_output_vertices and
we can't do that because we're running in the SoA mode, which means that
our storing routines will keep getting called on channels that have
overflown (even
We were always treating the vertex index as a scalar but when the
shader is using indirect addressing it will be a vector of indices
for each channel. This was causing some nasty crashes insides
LLVM.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c
we were using the wrong vars, reporting incorrect stream output
statistics.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/softpipe/sp_query.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_query.c
we were ignoring leading/provoking vertex settings which was
breaking decomposition of some strips.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_so_emit_tmp.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/draw
pre_clip_pos is a float[4] we just use (*float)[4] to be able to
jump within the array of vertex_headers with it. So if the idx
happened to be anything but 0, we'd actually read from some garbage
in memory. Always use 0 to correctly offset withing float[4].
Signed-off-by: Zack Rusin za
Looks good to me.
Reviewed-by: Zack Rusin za...@vmware.com
- Original Message -
From: José Fonseca jfons...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_texture.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe
primitive is one of the
adjacency primitives, decomposes them into something
that the rest of the pipeline can understand.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/Makefile.sources |1 +
src/gallium/auxiliary/draw/draw_prim_assembler.c | 202
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/util/u_prim.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index 99bb66c..507d12e 100644
--- a/src/gallium/auxiliary
- Original Message -
Looks good to me though I wonder if it would be an option to do this at
vertex fetch time instead after vs? I guess though that way it would
have to be done separate for the llvm and non-llvm code as the fetch is
integrated into the llvm code. I think that the
which
we can reset instance dependent data.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c | 13 +
src/gallium/auxiliary/draw/draw_gs.c | 14 +-
src/gallium/auxiliary/draw/draw_gs.h |2 ++
src/gallium/auxiliary
Can you even have that property in in a non-geometry shader?
No, not in well formed shaders at least. One could of course force it through
graw. I thought about an assert there but I figured that a conditional there
won't matter much.
In any case, series looks good to me, though your patches
We need to handle the leading vertex information when
assembling primitives for the geometry shader otherwise
the resulting triangles will have vertices at incorrect
input locations.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs_tmp.h |2 +-
1 file changed
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_query.c | 12
src/gallium/drivers/llvmpipe/lp_query.h |1 +
src/gallium/drivers/llvmpipe/lp_rast.c |2 ++
3 files changed, 15 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
There can be more stream output decls than shader outputs because
individual components from them can be split and distributed
among different so buffers.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/include/pipe/p_state.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion
[0]. Correctly take into
consideration where the vertex position is actually stored.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src
We weren't taking the buffer offset, destination offset or the
stride into consideration so we were frequently writing into
an overflown buffer.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_pt_so_emit.c | 11 ---
1 file changed, 8 insertions(+), 3
- Original Message -
Am 24.04.2013 00:58, schrieb Zack Rusin:
There can be more stream output decls than shader outputs because
individual components from them can be split and distributed
among different so buffers.
Signed-off-by: Zack Rusin za...@vmware.com
---
src
- Original Message -
Am 24.04.2013 00:58, schrieb Zack Rusin:
This was a very serious bug. We were always doing the viewport
transformations on the first output of the vertex shader. That means
that every application that was storing position in anything but
OUT[0] was outputing
You can already express holes with the current interface by setting
dst_offset of two outputs such that there is a hole between them (e.g.
dst_offset0 = 0, dst_offset1 = 8). I don't think inserting a dummy
output for the hole is needed.
Also, the commit summary doesn't say that the gallium
We already hold the variable, just weren't providing access
to it.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c |9 +
src/gallium/auxiliary/tgsi/tgsi_ureg.h |6 ++
2 files changed, 15 insertions(+)
diff --git a/src/gallium/auxiliary
we weren't adding the soa offsets when constructing the indices
for the gather functions. That meant that we were always returning
the data in the first vertex/primitive/pixel in the SoA structure
and not correctly fetching from all structures.
Signed-off-by: Zack Rusin za...@vmware.com
---
src
Fixes a crash when one of the so targets is null.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_draw_arrays.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
b/src/gallium/drivers
We were crashing if one of the buffers wasn't set, we should
just treat it as an overflow. It's useful when using so
statistics because it allows one to figure out how much data
would be generated by so without actually writing any of it.
Signed-off-by: Zack Rusin za...@vmware.com
---
src
only report overflow for missing targets if they're actually being
used. if the targets are missing but are not being used by any
slot in the stream output declaration we should correctly just
ignore them.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw
Technically it's legal for geometry shader to not emit any
vertices. It's silly, but perfectly legal, so lets make draw
stop crashing if it happens.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c |9 +
.../auxiliary/draw
What is IA?
Input Assembly, a D3D10 term that roughly matches pipe_vertex_elements /
pipe_vertex_buffer state.
BTW, I think that Chris Forbes makes a good point -- a GS might choose to
not emit any vertices (e.g., that does fancy culling) -- so maybe this
debugging message should be
- Original Message -
Primitive culling in the geometry shader can be faster if emitting
lots of primitives is a bottleneck, for example rendering to multiple
viewports. The geometry shader execution is not slow per se. It's the
stuff around it that makes it slow. (the primitives might
It's valid. Some shaders do the negation on unsigned and then
use the results in opcodes taking signed integers.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary
instead of crashing just fill zeros at the input slots that don't
match, that's the mandated behavior and it avoids debug asserts.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c | 93 --
1 file changed, 54 insertions(+), 39
- Original Message -
Am 02.05.2013 03:13, schrieb Zack Rusin:
It's valid. Some shaders do the negation on unsigned and then
use the results in opcodes taking signed integers.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c |2
and
IADD).
zFrom 6db142347bcbe6d197317bc6ba9637233074cf4b Mon Sep 17 00:00:00 2001
From: Zack Rusin za...@vmware.com
Date: Sun, 28 Apr 2013 10:50:55 -0400
Subject: [PATCH] gallivm: allow negation of all integer types
It's valid. Some shaders do the negation on unsigned and then
use the results
Well in contrast to the IF/UIF they'd be really redundant unless I'm
missing something so just for supporting negation on inputs or not this
looks like not really worth it (and as said there are also other signed
instructions where supporting negation doesn't really make sense). OTOH
you're
- Original Message -
Hi list,
This patch series attemps to clean up u_prim.h, with an exception that a new
function to get the tessellated (as opposed to decomposed) primitive count is
added by the last patch. I need that function for ilo to update
PIPE_QUERY_PRIMITIVES_GENERATED.
it, just ureg didn't).
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c |3 ++-
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 14 ++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src
gallium lies. buffer_size is not actually buffer_size but available
size, which is 'buffer_size - buffer_offset' so by adding buffer
offset we'd incorrectly compute overflow.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_pt_so_emit.c |3 +--
1 file changed, 1
k, I'll just push that last patch then. If someone won't like it or we'll
decide to do it in some other way we can always redo it later. For now
this will be enough to fix the umad handling.
I don't like this, sorry for being slow :-)
Mainly because I don't think any hw has the
the instrunction has
immediate register with indirect addressing.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h |6 ++
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 78 ++-
2 files changed, 82 insertions(+), 2 deletions
the check.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 145 +---
src/gallium/auxiliary/draw/draw_llvm.h | 16
src/gallium/auxiliary/draw/draw_pt.c |3 +-
3 files changed, 151 insertions(+), 13 deletions(-)
diff
buffer, which works perfectly
for buffer backed vertex_buffers and, in future, it will allow
us to plumb user_buffer sizes through the same interface.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c |6 +-
src/gallium/auxiliary/draw
1 - 100 of 299 matches
Mail list logo
