On Wed, Jan 24, 2024 at 6:57 PM Marek Olšák wrote:
>
> Gallium looks like it was just a copy of DX10, and likely many things were
> known from DX10 in advance before anything started. Vulkanium doesn't have
> anything to draw inspiration from. It's a completely unexplored idea.
I'm not sure if
On Wed, Jan 24, 2024 at 10:27 AM Faith Ekstrand wrote:
>
> Jose,
>
> Thanks for your thoughts!
>
> On Wed, Jan 24, 2024 at 4:30 AM Jose Fonseca
> wrote:
> >
> > I don't know much about the current Vulkan driver internals to have or
> > provide an informed opinion on the path forward, but I'd li
instead which seems cleaner (since we really
> don't want to use the clipvertex value from the vs (it could be a valid value
> in the (unsupported) case of vs writing clipvertex but still using a gs).
> This fixes piglit shader_runner clip-distance-out-values.shader_test.
Great. Well
Looks great. If I was into diffs I'd make sweet and passionate love to this one.
Reviewed-by: Zack Rusin
- Original Message -
> From: Dave Airlie
>
> This limits the number of emitted vertices to the shaders max output
> vertices, and avoids us writing things into
To be honest I still don't like it. While the tgsi_exec specific paths in
draw_gs don't matter to me and can be as ugly as they need to be, they can't be
polluting the draw_pt_emit code, in other words the primitive_lengths can't be
bogus at that point - prim_info can't lie about the amount of d
> I'll revisit it today and see if I can spot something else wrong, it
> fails for triangle adj because there are 6 vertices per primitive and
> we have only malloced space for 4.
It has to be something else because that's impossible, in fact it's 2x
impossible ;)
1) It's illegal and impossible
'd look for the
bug there.
z
- Original Message -
> On 11 June 2014 00:02, Zack Rusin wrote:
> > That looks wrong. The total number of verts per buffer is the maximum
> > number of verts that can be output per invocation (primitive_boundary)
> > times num
That looks wrong. The total number of verts per buffer is the maximum number
of verts that can be output per invocation (primitive_boundary) times number of
invocations of geometry shader (num_in_primitives).
It's not maximum number of verts that can be output per invocation
(primitive_boundar
It's not relevant to anything we have. The last I looked st/nine wasn't even an
umd. Everything that's needed for a d3d9 (and d3d10) umd's has already been
added to gallium, we don't have any patches against core gallium that we've
been keeping from the community. All we could do is review the p
>
> - tgsi_exec_machine_destroy(draw->vs.tgsi.machine);
> + if (draw_get_option_use_llvm())
> + tgsi_exec_machine_destroy(draw->vs.tgsi.machine);
That part should have used !draw_get_option_use_llvm()
___
mesa-dev mailing list
mesa-dev@lists.
Lets make draw_get_option_use_llvm function available unconditionally
and use it to avoid useless allocations when LLVM paths are active.
TGSI machine is never used when we're using LLVM.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_context.c | 6 ++
src/gallium/auxi
- Original Message -
> From: Rob Clark
>
> While still more of a stop-gap solution (until glamor) for freedreno,
> with these few relatively simple changes I get a pretty big performance
> boost (~40%) for xf86-video-freedreno.
That looks great to me. Nice work.
But to be honest the only
input primitive (i.e. gs invocation).
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_gs.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_gs.c
b/src/gallium/auxiliary/draw/draw_gs.c
index 97e8a90..7de5e03 100644
it's useful to know what the llvmbuildstore arguments are going to
be before executing it because it can crash and make sure to
print out the inputs only if we're not generating a gs because
it fetches inputs differently.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/d
> I see the crashes you're referring to.
>
> I don't quite understand why though: concerning the geometry shader, other
> than cosmetic changes, in theory I should just have replaced a null/non-null
> `tokens` pointer with a boolean `no_tokens`, though obviously I missed
> something.
Yea, you mis
Actually Jose I think we'll need to revert this. That's because draw always
assumed that if geometry shader is present it means that the geometry shader is
present, but that is not true anymore. That's because d3d10 creates a null
geometry shader to pass around the stream output. Before the patc
Looks good to me.
z
- Original Message -
> From: Roland Scheidegger
>
> This can get called in some circumstances if both src type and dst type
> have same width (seen with float32->unorm32). While this particular case
> was bogus anyway let's just fix that as it can work trivially (due
The series looks great to me.
- Original Message -
> From: José Fonseca
>
> Eliminate lp_vertex_shader, as it added nothing over draw_vertex_shader.
>
> Simplify lp_geometry_shader, as most of the incoming state is unneeded.
> (We could also just use draw_geometry_shader if we were will
streamed
out to. Our interface didn't allow. This change functionally
shouldn't make any difference to OpenGL where instead of an
append_bitmask you just get a real array where -1 means append
(like in D3D) and 0 means do not append.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary
This change functionally
shouldn't make any difference to OpenGL where instead of an
append_bitmask you just get a real array where -1 means append
(like in D3D) and 0 means do not append.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/cso_cache/cso_context.c | 13 -
s
Because in draw we always inject position at slot 0 whenever
fragment shader would take the maximum number of inputs (32) it
meant that we had PIPE_MAX_ATTRIBS + 1 slots to translate, which
meant that we were crashing with fragment shaders that took
the maximum number of attributes as inputs. The a
draw_current_shader_* functions return a final output when considering
both the geometry shader and the vertex shader. But when code generating
vertex shader we can not be using output slots from the geometry shader
because, obviously, those can be completely different. This fixes a
number of very
> > reasons. This commit adds code to skip that performance optimization
> > and always use just the dynamically allocated immediates if the
> > number of them is too great.
>
> So is there any limit on the number of immediates now?
Technically not. Practically other parts of the code will max ou
-
> Am 05.02.2014 01:34, schrieb Zack Rusin:
> > ureg_program is allocated on the heap so we can just bump the
> > number of immediates that it can handle. It's needed for d3d10.
> >
> > Signed-off-by: Zack Rusin
> > ---
> > src/gallium/auxiliary/tg
ureg_program is allocated on the heap so we can just bump the
number of immediates that it can handle. It's needed for d3d10.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary
t the dynamically allocated immediates if the
number of them is too great.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 2 +-
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 112
2 files changed, 77 insertions(+), 37 deletions(-)
diff --
We need to handle a lot more immediates and in order to do that
we also switch from allocating this structure on the stack to
allocating it on the heap.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 17 +
1 file changed, 9 insertions(+), 8
Looks good.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> Previously, we were really doing F2I. And also move it to generic section.
> (Note that for llvmpipe the code generated is definitely bad, due to lack
> of unsigned conversions wi
we supported 2d indirect addressing (gs tests were using it) but
not 1d indirect addressing (which can be used in vs and ps). This
adds support for 1d indirect addressing.
Signed-off-by: Zack Rusin
---
src/gallium/state_trackers/d3d10/ShaderTGSI.c | 26 ++
1 file changed
Indexable temporaries are 2d (the index of the array and the index
within the array) and can be used both as outputs, inputs and relative
addressing registers. This fixes parsing of indexable temporaries
and fixes their parsing in relative addressing.
Signed-off-by: Zack Rusin
---
src/gallium
Outputs can have relative addressing. This adds basic support for it.
Signed-off-by: Zack Rusin
---
src/gallium/state_trackers/d3d10/ShaderTGSI.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/d3d10/ShaderTGSI.c
b/src
em as indexable
temporaries and allocate them as an array from the start.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/ga
- Original Message -
> Am 28.01.2014 23:08, schrieb Zack Rusin:
> > gallivm soa code supported only a single level of nesting for
> > control flow opcodes (if, switch, loops...) but the d3d10 spec
> > clearly states that those are nested within functions. To s
keep a stack of those.
Furthermore we make sure that if nesting for subroutines is deeper
than 32 then we simply ignore all subsequent 'call' invocations.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 72 ++---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_s
ed to return garbage but consistent
garbage (we follow the behavior which some wlk tests expect which
is to return the actual values from the bound buffer).
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_llvm.c | 42 ++
src/gallium/auxiliary/draw/draw_l
Yea, this sucks. Geometry shaders can take primitive id (system value) for
passed in primitives and generate one (semantic) for primitives generated in
the geometry shader. TBH, I thought we already handled it... Maybe wlk doesn't
test it, we'll see if it regresses.
z
- Original Message --
lways within bounds.
Currently only used for indirect addressing.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_llvm.c | 42 +++---
src/gallium/auxiliary/draw/draw_llvm.h | 32 +++--
.../draw/draw_pt_fetch_shade_pipeline_l
Looks good. Thanks Roland!
- Original Message -
> From: Roland Scheidegger
>
> The argument is a i8 pointer not a i32 pointer (even though the value
> actually
> stored/loaded IS i32). Older llvm versions didn't care but 3.2 and newer do
> leading to crashes.
> ---
> src/gallium/auxilia
Ah, good stuff, very sensual and does not need more cowbell.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> This code was always problematic, and with 64bit rasterization we no longer
> need it at all.
> ---
> src/gallium/drivers/l
Disabled by default, but it's very useful when needed.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_setup_point.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup_point.c
b/src/gallium/drivers/llv
n the renderer getting
incorrect front-face attributes. By reseting the vertex_id (which
is used for caching) we make sure that once a front-face info
has been injected the vertex will endup getting emitted.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pipe_unfilled.c | 1 +
1
The fact that we flush denorms to zero breaks our half-float
conversion and blending. This patches enables denorms for
blending. It's a little tricky due to the llvm bug that makes
it incorrectly reorder the mxcsr intrinsics:
http://llvm.org/bugs/show_bug.cgi?id=6393
Signed-off-by: Zack
The entire series looks good to me.
> Now that it is possible to query drivers for the max sampler view it should
> be safe to increase this without crashing.
> Not entirely convinced this really works correctly though if state trackers
> using non-linked sampler / sampler_views use this.
I'm not
ect.
zFrom 55c9a288c7ebc37b32bc75526e6de71a838ccaef Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 24 Oct 2013 22:05:22 -0400
Subject: [PATCH] llvmpipe: support 8bit subpixel precision
8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterizatio
8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
from the llvmpipe-rast-64 branch.
Signed-off-by: Zack Rusin
---
src/ga
That's very nice Jose! Looks good to me.
- Original Message -
> From: José Fonseca
>
> It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
>
> I had prototyped this for a while while debugging an issue, but finally
> cleaned this up and added a few more bells and whistles.
>
Looks good.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> There's only one minor functional change, for immediates the pixel offsets
> are no longer added since the values are all the same for all elements in
> any case (it migh
Used to test rasterization, because we often breakdown on
subdivision of triangles with long edges.
Signed-off-by: Zack Rusin
---
src/gallium/tests/graw/SConscript | 1 +
src/gallium/tests/graw/tri-large.c | 173 +
2 files changed, 174 insertions
As we're moving towards expanding the number of subpixel
bits and the width of the variables used in the computations
we need to make this code a bit more centralized.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_rast.h | 9 +
src/gallium/drivers/llv
Both the imul_hi and umul_hi are working with this patch.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 60 ++
1 file changed, 60 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c
b/src/gallium/auxiliary
destinations and because there's not much (any)
difference wrt code-generation.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 34 ++
src/gallium/auxiliary/tgsi/tgsi_info.c | 6
src/gallium/auxiliary/tgsi/tgsi_opcode_
only 8 and 32 bit integers were supported before.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/gallivm/lp_bld_printf.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_printf.c
b/src/gallium/auxiliary/gallivm/lp_bld_printf.c
We need to subdivide triangles if either of the dimensions is
larger than the max edge length, not when both of them are larger.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/llvmpipe
When subdiving a triangle we're using a temporary array to store
the new coordinates for the subdivided triangles. Unfortunately
the array used for that was not aligned properly causing
random crashes in the llvm jit code which was trying to load
vectors from it.
Signed-off-by: Zack
be emitted.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pipe_clip.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index 0f90bfd..2d6df81 100644
--- a/s
make it easier
to change once to switch to 64bit rasterization.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_rast.h | 12 +++-
src/gallium/drivers/llvmpipe/lp_setup.c | 14 +-
src/gallium/drivers/llvmpipe/lp_setup_tri.c | 2 +-
3 files changed, 17
We need to count the clipper primitives before the rasterizer
discards one it considers to be null.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_setup_tri.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe
The entire series looks good to me.
Reviewed-by: Zack Rusin
- Original Message -
> From: José Fonseca
>
> This removes a lot of code, but not everything, as util_blit_pixels_tex
> is still useful when one needs to override pipe_sampler_view::swizzle_?.
> ---
> src
es in case another stage is using them).
> Stéphane
> On Thu, Aug 8, 2013 at 12:46 PM, Zack Rusin < za...@vmware.com > wrote:
> > Before inserting new front face and prim id outputs cleanup
>
> > the old extra outputs, otherwise our cache will use previous
>
> This reverts commit 57cd3267782fcf92d1e7d772760956516d4367df.
>
> This fixes piglit regressions with additional draw stages on
> llvmpipe, softpipe and i915g. The attributes can't be cleared at
> this point because they might be in use by the additional draw
> stages.
The attributes have to cle
We support indirect addressing only on the vertex index, but some
shaders also use indirect addressing on attributes. This patch
adds support for indirect addressing on both dimensions inside
gs arrays.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_llvm.c | 23
Same here.
- Original Message -
> Series LGTM.
>
> Jose
>
> - Original Message -
> > From: Roland Scheidegger
> >
> > Turns out we don't need to do much extra work for detecting this case,
> > since we are guaranteed to get a empty static texture state in this case,
> > hence j
Looks good.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> pstipple/aaline stages used PIPE_MAX_SAMPLER instead of
> PIPE_MAX_SHADER_SAMPLER_VIEWS when dealing with sampler views.
> Now these stages can't actually handle sampler_unit !=
> I realize this function isn't used but it looks unnecessarily
> complicated - two constants one AND plus one comparison when you could
> simply do a single comparison (compare x with x with unordered not
> equal). This is actually doubly bad with AVX because the int comparison
> is going to use 4
If clipdistance for one of the vertices is nan (or inf) then the
entire primitive should be discarded.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_cliptest_tmp.h |2 +-
src/gallium/auxiliary/draw/draw_llvm.c |3 ++
src/gallium/auxiliary/draw/draw_pipe_clip.c
- Original Message -
> From: Roland Scheidegger
>
> This is a very well hidden bug found by accident (only the fixed glean
> tstencil2 test so far seems to hit it).
> We must use new mask with combined s_pass values and orig_mask values
> for zpass/zfail stencil ops, otherwise both the sf
> - lp_build_sample_compare(&bld, newcoords[4], texel_out);
> + if (0)
> + lp_build_sample_compare(&bld, newcoords[4], texel_out);
> }
What does this do?
The rest looks good to me!
Reviewed-by: Zack Rusin
I have to admit that I don't know the sampling code, but the patches look good
to me.
z
- Original Message -
> From: Roland Scheidegger
>
> This makes things a bit nicer, and more importantly it fixes an issue
> where a "downgraded" array texture (due to view reduced to 1 layer and
> a
If the fragment shader is null then pixel shader invocations have
to be equal to zero. And if we're running a null ps then clipper
invocations and primitives should be equal to zero but only
if both stancil and depth testing are disabled.
Signed-off-by: Zack Rusin
---
src/gallium/dr
If the fragment shader is null then pixel shader invocations have
to be equal to zero. And if we're running a null ps then clipper
invocations and primitives should be equal to zero but only
if both stancil and depth testing are disabled.
Signed-off-by: Zack Rusin
---
src/gallium/dr
fixes all of the reported piglit failures.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_context.c |2 +
src/gallium/auxiliary/draw/draw_pipe.h |5 +-
src/gallium/auxiliary/draw/draw_pipe_aaline.c | 27 ---
src/gallium/auxiliary
Nice. The entire series looks good.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> FSEQ/FSGE/FSLT/FSNE work just the same as SEQ/SGE/SLT/SNE except skip the
> select.
> And just for consistency use the same appropriate ordered/unordered
>
Ah, that looks like a great catch.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> Because we must maintain an exec_mask even if there's currently nothing
> on the mask stack, we can still have an exec_mask at the end of the program.
&g
Looks good.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> The code was quite weird, the second comparison was in fact a complete no-op
> and we can also do the comparison with the vector directly instead of scalar,
> which should not also b
itional logic to do the unsigned comparisons the cpu can't do).
> Saves a couple of instructions in some test geometry shader here.
>
> v2: that was a bit to much optimization, don't skip combining the masks...
k, I think that one looks good.
Reviewed-by: Zack Rusin
__
- Original Message -
> This is a proposal for new comparison instructions, as the old ones
> don't really fit modern (graphic or opencl I guess for that matter)
> languages well.
> If you've got objections, think the naming is crazy or whatnot I'm open
> for suggestions :-). I would think t
> Am 09.08.2013 00:40, schrieb Zack Rusin:
> > > Series looks good though I'm unsure why the pipeline stage doesn't work.
> >> Where does that decomposition happen? Is that something like GS
> >> outputting multiple prims in the same topology which all nee
> Series looks good though I'm unsure why the pipeline stage doesn't work.
> Where does that decomposition happen? Is that something like GS
> outputting multiple prims in the same topology which all need the same id?
No, it's because the pipeline stage is ran on the decomposed primitives. The
i
Looks good.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> My previous attempt at doing so double-failed miserably (minification of
> zero still gives one, and even if it would not the value was never written
> anyway).
> While he
Series looks good to me.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> d3d10 has no notion of distinct array resources neither at the resource nor
> sampler view level. However, shader dcl of resources certainly has, and
> d3d10 expects re
emit those vertices with the changed
> primitive id. So lets reset the vertex id whenever injecting
> new primitive id to make sure that the vertex data is correctly
> emitted.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/draw/draw_pipe_ia.c |9 +
>
embler and completely removes the
useless pipeline stage.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/Makefile.sources |1 -
src/gallium/auxiliary/draw/draw_context.c|8 +-
src/gallium/auxiliary/draw/draw_pipe.c |4 -
src/gallium/auxiliary/draw/d
ertex data is correctly
emitted.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pipe_ia.c |9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_ia.c
b/src/gallium/auxiliary/draw/draw_pipe_ia.c
index ecbb233..d64f19b 100644
--- a/src/ga
Before inserting new front face and prim id outputs cleanup
the old extra outputs, otherwise our cache will use previous
output slots which will break as soon as outputs of the current
shader don't match the last.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_context.c |
good too. For all three:
Reviewed-by: Zack Rusin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
- Original Message -
> From: Roland Scheidegger
>
> Clearly the returned values need to be per-element if the lod is per element.
> Does not actually change behavior yet.
Looks good. For the entire series:
Reviewed-by: Zack Rusin
Nowadays -1 for slots means that the semantic is not present, so
we need to store it in a signed variables, otherwise <0 comparisons
are pointless. Fixes
http://bugzilla.eng.vmware.com/show_bug.cgi?id=67811 (at least
with softpipe, edgeflags don't work wit llvmpipe)
Signed-off-by: Za
Looks good to me. A small comment above the disabled version noting that it's
disabled because it's a bit slower might be useful for the next person who
reads the code.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> Should be much fa
For now though this works, even if it is
very ugly.
z
- Original Message -
> Am 02.08.2013 08:28, schrieb Zack Rusin:
> > we used to have a face primitive assembler that we ran after if
> > the gs was missing but we had adjacency primitives in the pipeline,
> > l
ition is already handled for us.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/Makefile.sources |2 +-
src/gallium/auxiliary/draw/draw_context.c |1 +
src/gallium/auxiliary/draw/draw_pipe.c |4 +
src/gallium/auxiliary/draw/draw_pipe.h |
the initial scan
of fs inputs.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_state_derived.c | 30 +++
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_derived.c
b/src/gallium/drivers/llvmpipe
Inject front face only if the fragment shader uses it and
propagate through all channels because otherwise we'll
need to figure out the exact swizzle that the fs expects and
it's just simpler to make sure all the components within
the front face register are correctly set.
Signed-of
Instead of using the magical 4 use the above computed
vertex size. Doesn't change the behavior, just makes the code
a bit cleaner.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pipe_vbuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ga
propagates the entire vertex.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pipe_clip.c | 89 ---
1 file changed, 54 insertions(+), 35 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index
when dumping shader outputs it's nice to have the integer
values of the outputs, in particular because some values
are integers.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_llvm.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary
cular when running
the pipeline which depends on the vertex_id in the vertex_header
things were completely broken. The patch adjust the code to
correctly use the total number of shader outputs (the standard
ones plus the injected ones) to make it all stop crashing and
work.
Signed-off-by: Zack
Adding code to detect the usage of prim id and front face
semantics in fragment shaders.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/tgsi/tgsi_scan.c |9 +++--
src/gallium/auxiliary/tgsi/tgsi_scan.h |1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src
> > + if (draw_will_inject_frontface(lp_context->draw) &&
> I think it's annoying you have to do these calls to determine if there's
> a valid frontface here for each line instead of just per draw call but
> it doesn't seem easy to avoid it.
Yea, there's no trivial way of avoiding it.
> Also, n
e'). To fix it allow draw module to inject a fake face semantic
into outputs from which the backends can figure out the original
frontfacing info of the primitives.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_context.c | 43
src/gallium
The spec says that front-face is true if the value is >0 and false
if it's <0. To make sure that we follow the spec, lets just
subtract 0.5 from our value (llvmpipe did 1 for frontface and 0
otherwise), which will get us a positive num for frontface and
negative for backface.
Signed-o
1 - 100 of 334 matches
Mail list logo
