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 cleared
).
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
output slots which will break as soon as outputs of the current
shader don't match
On Thursday, June 21, 2012 11:19:39 AM Michel Dänzer wrote:
BTW, recent versions of emacs no longer seem to provide the dirvars
package, but I think they support another similar mechanism instead.
Would be great if somebody who knows more about this could
convert .emacs-dirvars to the current
On Thursday 29 April 2010 14:09:22 José Fonseca wrote:
We don't have such fined grain capabilities in Gallium drivers yet, so I
followed Keith's suggestion of tie the native program limits to the GLSL
and SM3 support exported by the driver.
That seems like a pretty good solution to me for now.
On Thursday 29 April 2010 15:44:35 Marek Olšák wrote:
On Thu, Apr 29, 2010 at 8:30 PM, Zack Rusin
za...@vmware.commailto:za...@vmware.com wrote: It seems like all we'd
really need is relate those things to
the feature/api levels it exposes and document it.
Feature levels are a pretty bad
On Thursday 29 April 2010 20:58:04 Dave Airlie wrote:
On Fri, Apr 30, 2010 at 10:42 AM, Jose Fonseca jfons...@vmware.com wrote:
We discussed the pros cons of this several times, there was never
consensus, and there is always room for improvements, but I refuse to
discuss them in such
On Saturday 01 May 2010 15:27:45 Chia-I Wu wrote:
Hi all,
I've been working on and off for a while on a dispatcher builder called
mapi (multiple-api, in contrary to gl-api). The code is available at
http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi
The motivation is to build a
On Monday 03 May 2010 14:17:30 Alex Deucher wrote:
On Mon, May 3, 2010 at 2:09 PM, Brian Paul bri...@vmware.com wrote:
I think it's worth exploring a policy of somehow tagging commits as
candidates for back-porting to the stable branch so they can be some
level of accounting and tracking.
Dear friends,
I'm a long lost prince of Nigeria and I'm writing to you with an incredible
business offer. I have this gallium-stream-output branch which is worth
$1000 and I'm going to send it your mesa/master account for free! All you
have to do is review it (and send me $20 to cover my
or just not advertising
support for it (PIPE_CAP_STREAM_OUTPUT == 0).
z
From: Corbin Simpson [mostawesomed...@gmail.com]
Sent: Monday, June 07, 2010 2:53 PM
To: Zack Rusin
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Stream output
On Mon, Jun 7
Hey,
there's another branch with a significant impact that I'm planning to merge
soon. gallium-resource-sampling. It effectively adds the concept of shader
resources (currently required by both DX10+ and OpenCL). The idea is to allow
arbitrary binding of resources in shaders with a number of
I like the bitwise, flow control, and primitive groups. My main
concern is splitting things into groups that make it easy to say, Oh
yes, this hardware supports all of these opcodes. Also, we have a
*lot* of opcodes. Any kind of grouping based on the semantics of the
opcodes is going to be
On Friday 02 July 2010 12:42:51 Roland Scheidegger wrote:
There is some code for 1.1 (all using #ifdef OPENVG_VERSION_1_1).
Not really sure on the status of this, but I don't think this works,
might not even compile, so the answer is probably no.
Correct, 1.1, in particular text, hasn't been
On Wednesday 07 July 2010 15:00:55 Jerome Glisse wrote:
Hi,
So after being of the grid i am resuming my epic on mesa demos.
I set version to 8.0 so it's easy for distro, and as fresh start for
demos on it's own. If no one object i will do the release by the end
of the week (this time i
On Thursday 08 July 2010 11:40:56 Keith Whitwell wrote:
On Thu, 2010-07-08 at 08:36 -0700, Brian Paul wrote:
PIPE_MAX_SHADER_INPUTS/OUTPUTS are currently set to 16 in p_state.h
That's actually not enough to accomodate OpenGL's needs. For example,
a Mesa vertex shader has these inputs:
On Friday 09 July 2010 17:41:10 Jerome Glisse wrote:
On 07/07/2010 03:00 PM, Jerome Glisse wrote:
Hi,
So after being of the grid i am resuming my epic on mesa demos.
I set version to 8.0 so it's easy for distro, and as fresh start for
demos on it's own. If no one object i will do the
Hey,
this is relatively simple: Mesa GPU instructions had no way of representing 2D
register arrays which was especially painful for things like geometry shaders.
It's the same thing Gallium supported for a while meaning
INPUT[index1][index2] syntax. So for example gl_PositionIn[index] becomes
On Tuesday 13 July 2010 12:08:15 Brian Paul wrote:
Looks great, Zack!
Just minor things:
A bunch of the shader setup code in bezier.c could probably be
replaced by calls to shaderutil.c functions.
Ah, yea, I'll just add something there to be able to link with geometry
shader.
In
On Wednesday 28 July 2010 06:26:39 Marek Olšák wrote:
Going from GL2.1 to GL1.5 just because some hardware can't do ddx and ddy
seems a bit silly to me.
I'm not quite sure what do you mean here, derivatives have been present in
GLSL since 1.1 so realistically hardware without them can't
On Friday 30 July 2010 17:51:21 Jakob Bornecrantz wrote:
On 30 jul 2010, at 14.02, Jakob Bornecrantz wrote:
On 30 jul 2010, at 13.32, Brian Paul wrote:
On 07/30/2010 12:38 PM, Jerome Glisse wrote:
Hi Brian,
I am facing a strange segfault with r600g on top of lastest git,
git bisect
On Friday 30 July 2010 14:13:06 Jorge Villaseñor wrote:
Is there some public roadmap to get this working? somewhere we can
start hacking? As Anthony I'm a newcomer and I'm looking for getting
OpenCL/clover up.
Not right now, I'll try to start something on the fdo wiki within the next few
On Monday 26 July 2010 03:48:31 Jonathan Hamilton wrote:
Hi,
I have been looking into what would be needed to modify in clang to
support opencl recently, although there is an opencl flag to set in the
lang options, it doesn't really seem to do much, so the modifications
seem non-trivial (to
On Monday 02 August 2010 12:33:50 Chia-I Wu wrote:
Hi,
While studying the draw module, I noticed that multiple primitive
decomposers exist: draw_pt_vcache_tmp.h, draw_gs_tmp.h,
draw_so_emit_tmp.h, and draw_pt_decompose.h. The differences between
them are small, yet some of them support
On Tuesday 03 August 2010 11:41:02 Chia-I Wu wrote:
On Tue, Aug 3, 2010 at 9:40 PM, Zack Rusin za...@vmware.com wrote:
I'm not sure if should, if adjacency primitives are set there should
always be a gs and if not we should set a pass-through gs should which
just emits triangles
On Tuesday 03 August 2010 12:56:41 Chia-I Wu wrote:
I see your point. There are more than one way to interpret the
diagram. Now I am curious if the diagram is all the D3D documents have
for triangle strip with adjacency?
As far as the public docs go I think that's it.
and so on. If you
On Thursday 05 August 2010 12:51:57 Chia-I Wu wrote:
On Thu, Aug 5, 2010 at 3:20 AM, Zack Rusin za...@vmware.com wrote:
With GS, the order of the vertices of a primitive becomes significant.
We can no longer permute the vertices to support flatshade_first (at
least, not before GS runs
On Sunday 15 August 2010 01:47:50 Luca Barbieri wrote:
Currently draw_llvm refuses to create itself on non-SSE2 CPUs due to
an alleged LLVM bug.
However, this is implemented improperly, because other parts of draw
still attempt to access draw-llvm, resulting in segfaults.
Instead, put the
On Sunday 05 September 2010 21:30:43 Luca Barbieri wrote:
There is a published extension with a token, so let's use it.
I'm not a fan of this patch. Technically the token is from a different
extension, one which we never supported. We use our own representation of a
geometry program, did you
Maybe lets skip this and other tessellation patches until we have code that
actually does something. It's just going to be confusing to have not finished
(or really not started =) ) code that doesn't do anything.
Also in terms of naming, I severely dislike abbreviations because code tends
to
On Monday 06 September 2010 11:19:40 Luca Barbieri wrote:
I'm not a fan of this patch. Technically the token is from a different
extension, one which we never supported. We use our own representation of
a geometry program, did you double check whether what we have is at all
compatible with
On Monday 06 September 2010 11:25:31 Luca Barbieri wrote:
On Mon, Sep 6, 2010 at 4:45 PM, Zack Rusin za...@vmware.com wrote:
Maybe lets skip this and other tessellation patches until we have code
that actually does something. It's just going to be confusing to have
not finished (or really
On Sunday 19 September 2010 13:44:33 Luca Barbieri wrote:
The current version of draw_stream_output in softpipe seems to attempt
to draw using the currently bound stream output buffer as input.
It's because I never had the time to actually test it properly. The interface
is right though, the
On Monday 20 September 2010 15:21:40 Luca Barbieri wrote:
2. How do you pass to Gallium the id parameter to DrawTransformFeedback?
You bind the buffer with the given id before issuing draw_stream_output.
Bind to what?
As the vbo.
Note that the id parameter to DrawTransformFeedback is
On Friday 12 November 2010 14:55:08 Jerome Glisse wrote:
Hi Jerome,
It's a bit tough to answer your email because it's composed of several quite
distinct parts (benchmarking, gallium, new state trackers, ttm...). If
anything it'd be good to seperate those into seperate threads.
Drawoverhead
On Tuesday 16 November 2010 20:26:03 Jerome Glisse wrote:
Anyway my point is that here the gl state tracker is not to blame,
it's only the fact that real application lead to a lot of cso
activities and i am not convinced that what we might possibly win with
cso is more important than what we
On Tuesday 30 November 2010 04:51:33 Chia-I Wu wrote:
Hi list,
I have spent the weekend adding OpenVG 1.1 support to Vega state
tracker. The new features added include mask layer support, text
support, and a new color transformation stage. The work can be found
at
On Wednesday 01 December 2010 19:46:42 Brian Paul wrote:
I was working on finishing up instanced drawing in Mesa/gallium last
week. The one stumbling block was how to handle the instance ID.
The instance ID is an integer accessible by the vertex shader that
only changes per drawing
On Sunday 23 January 2011 12:20:20 Brian Paul wrote:
The vega state tracker casts back and forth between pointers and the
handle types (VGHandle, VGPath, VGImage, etc). Since handles are
always 32-bit VGuints, casting like this doesn't work with 64-bit
pointers.
This patch series
On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
$ makelog
ar: creating libglapi.a
ar: creating libmesa.a
ar: libmesa.a: Error reading ../../src/glsl/.libs/: Is a directory
ar: creating libmesagallium.a
ar: libmesagallium.a: Error reading ../../src/glsl/.libs/: Is a
On Wednesday 26 January 2011 21:49:56 Chad Versace wrote:
What I wrote *isn't* C++. It's valid C99. It compiles without problem
with both GCC 4.5 and Clang 2.8 on Fedora14.
What compiler are you using? And why can't it handle a C dialect over a
decade old?
It doesn't matter which compiler I
On Monday 14 February 2011 21:13:04 Matt Turner wrote:
On Mon, Feb 14, 2011 at 8:31 PM, Yahya H. Mirza ya...@aurorasoft.net
wrote:
Is there anyone looking into using CMAKE as another build system for
MESA?
The solution is not another build system.
in this case it is. the issue with vs
The entire series looks good to me.
Reviewed-by: Zack Rusin za...@vmware.com
- Original Message -
From: José Fonseca jfons...@vmware.com
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_
We need to count the clipper primitives before the rasterizer
discards one it considers to be null.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_setup_tri.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers
to make it easier
to change once to switch to 64bit rasterization.
Signed-off-by: Zack Rusin za...@vmware.com
---
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
.
Signed-off-by: Zack Rusin za...@vmware.com
---
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
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 Rusin za
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 za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium
only 8 and 32 bit integers were supported before.
Signed-off-by: Zack Rusin za...@vmware.com
---
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
destinations and because there's not much (any)
difference wrt code-generation.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 34 ++
src/gallium/auxiliary/tgsi/tgsi_info.c | 6
src/gallium/auxiliary/tgsi
Both the imul_hi and umul_hi are working with this patch.
Signed-off-by: Zack Rusin za...@vmware.com
---
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
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 za...@vmware.com
---
src/gallium/drivers/llvmpipe/lp_rast.h | 9 +
src/gallium/drivers
Used to test rasterization, because we often breakdown on
subdivision of triangles with long edges.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/tests/graw/SConscript | 1 +
src/gallium/tests/graw/tri-large.c | 173 +
2 files changed, 174
Looks good.
Reviewed-by: Zack Rusin za...@vmware.com
- Original Message -
From: Roland Scheidegger srol...@vmware.com
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
That's very nice Jose! Looks good to me.
- Original Message -
From: José Fonseca jfons...@vmware.com
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
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 za...@vmware.com
55c9a288c7ebc37b32bc75526e6de71a838ccaef Mon Sep 17 00:00:00 2001
From: Zack Rusin za...@vmware.com
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
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
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 Rusin za
Disabled by default, but it's very useful when needed.
Signed-off-by: Zack Rusin za...@vmware.com
---
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
in 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 za...@vmware.com
---
src/gallium/auxiliary/draw/draw_pipe_unfilled.c
Ah, good stuff, very sensual and does not need more cowbell.
Reviewed-by: Zack Rusin za...@vmware.com
- Original Message -
From: Roland Scheidegger srol...@vmware.com
This code was always problematic, and with 64bit rasterization we no longer
need it at all.
---
src/gallium
Looks good. Thanks Roland!
- Original Message -
From: Roland Scheidegger srol...@vmware.com
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.
---
within bounds.
Currently only used for indirect addressing.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 42 +++---
src/gallium/auxiliary/draw/draw_llvm.h | 32 +++--
.../draw
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
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 za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 42 ++
src/gallium/auxiliary/draw
and 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 za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h | 72 ++---
src/gallium/auxiliary/gallivm
- 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 support
nesting of conditionals
as indexable
temporaries and allocate them as an array from the start.
Signed-off-by: Zack Rusin za...@vmware.com
---
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
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 za...@vmware.com
Outputs can have relative addressing. This adds basic support for it.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/state_trackers/d3d10/ShaderTGSI.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/d3d10
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 za...@vmware.com
---
src/gallium/state_trackers/d3d10/ShaderTGSI.c | 26
Looks good.
Reviewed-by: Zack Rusin za...@vmware.com
- Original Message -
From: Roland Scheidegger srol...@vmware.com
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
the dynamically allocated immediates if the
number of them is too great.
Signed-off-by: Zack Rusin za...@vmware.com
---
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
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 za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 17 +
1 file changed, 9
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 za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium
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 za...@vmware.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 2 +-
1 file changed, 1
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 out and
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
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
. 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 za...@vmware.com
---
src/gallium/auxiliary/cso_cache/cso_context.c | 13 -
src
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 za...@vmware.com
---
src/gallium/auxiliary
The series looks great to me.
- Original Message -
From: José Fonseca jfons...@vmware.com
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
Looks good to me.
z
- Original Message -
From: Roland Scheidegger srol...@vmware.com
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
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
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 missed
input primitive (i.e. gs invocation).
Signed-off-by: Zack Rusin za...@vmware.com
---
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
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 za...@vmware.com
---
src/gallium/auxiliary/draw
- Original Message -
From: Rob Clark robcl...@freedesktop.org
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
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 za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c | 6 ++
src
- 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
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
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
- Original Message -
On 11 June 2014 00:02, Zack Rusin za...@vmware.com 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 number of invocations of geometry shader
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
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
Looks great. If I was into diffs I'd make sweet and passionate love to this one.
Reviewed-by: Zack Rusin za...@vmware.com
- Original Message -
From: Dave Airlie airl...@redhat.com
This limits the number of emitted vertices to the shaders max output
vertices, and avoids us writing
-by: Zack Rusin za...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
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
201 - 299 of 299 matches
Mail list logo
