Re: [Mesa3d-dev] geometry shading patches
On Saturday 26 December 2009 02:19:40 Marek Olšák wrote: > Zack, > > to be honest, Direct3D 11 can report geometry shaders are not supported > through so-called feature levels. There are six levels to my knowledge > (9_1, 9_2, 9_3, 10_0, 10_1, 11_0). i915 is 9_1, R300 is 9_2, R500 is 9_3, > and so on. Direct3D 11 is indeed accelerated on those pieces of hardware > and, though the feature set is a little limited, the hardware support is > covered well. Is Direct3D 11 generations past because of that? No, it > isn't. > > Let's say I have R500 and I want to use geometry shaders in Direct3D 11. > What are my options? I can't use my R500 and I must manually switch to the > device called WARP (Windows Advanced Rasterization Platform), which > reports the 10_1 feature level. This kind of device is very similar to > llvmpipe in Gallium. > > In the past you said we should do it the same way as Direct3D, so why > should Gallium be different now? I think you're using "it" a bit broadly here because we never had a discussion about caps. First of all Gallium3D is already different when it comes to capabilities reporting. We have a buttload of caps, realistically speaking most of them are likely tight together. What we do right now is what d3d9 used to do which is what everyone agreed is awful. Not to mention that we don't have an option of actually selecting llvmpipe vs whatever hardware driver by hand. The argument that would certainly make sense is one for moving Gallium3D caps model towards a shader-model reporting. e.g. shader-model 2.x, 3.x, 4.x, 5.x versus every single feature that they bring forward, e.g. 4.x implies geometry shader, 5.x implies tessellation/compute. I absolutely abhor the idea of reporting as a cap everything above of what i915 or r300 can do, for the lack of better wording it's just ridicules. I do think though that we should look at our caps bits and come up with something better. > Moreover, if applications decide to use geometry shaders to emulate point > sprites or wide lines, we'll be screwed. If the hardware doesn't implement those features they'll be in the draw module anyway. So it's really draw module vs draw module. > If they decide to do texture fetches in geometry shaders, we'll be screwed > even more because we'll have to move textures out of VRAM and that will be > a total performance killer. So I agree with Corbin that the CAP for > geometry shaders should be added and we should let drivers decide what's > best for them. How is that different from the same problem applied to a vertex shader on i915 and the ways that works right now? I agree that we need to solve that problems, but I just refuse that the best we can is "everything above i915 is a feature cap". We need to come up with a scheme that actually works or assume it's ok for draw module to handle some of those features. For us it likely should be some combination of API and shader-model support (shader-models don't tell us anything about gl specific features like shadow samplers or aa lines/points), if we can figure out we can reasonable handle that we'll be fine. z -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
I don't think this is a big deal either way. My feeling was that since most or all drivers will have some use of the draw module, this wouldn't be any worse. But if there really are pre-geometry shader drivers that can avoid the draw module in all other situations, that's probably something we want to preserve. Corbin, do these drivers actually implement all of the GL stuff that the draw module provides fallbacks for? Or is there missing functionality that will eventually need help to implement? Basically my desire is to avoid an explosion of capability bits and advertise just a small number of broad classes of hardware. Probably the way to answer the question of whether this should be a cap or not is to do the work of figuring out what these mythical harware classes are and whether that can be made to work. Keith From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Friday, December 25, 2009 4:03 AM To: Keith Whitwell Cc: Zack Rusin; mesa3d-dev Subject: Re: [Mesa3d-dev] geometry shading patches I can't speak for Jakob or the Nouveau guys, but at least r300g is trying to keep Draw usage to a minimum. I know i915 has to use Draw, so that won't be a problem, but nv30 and nv40 are Draw-free IIRC. ~ C. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
Zack, to be honest, Direct3D 11 can report geometry shaders are not supported through so-called feature levels. There are six levels to my knowledge (9_1, 9_2, 9_3, 10_0, 10_1, 11_0). i915 is 9_1, R300 is 9_2, R500 is 9_3, and so on. Direct3D 11 is indeed accelerated on those pieces of hardware and, though the feature set is a little limited, the hardware support is covered well. Is Direct3D 11 generations past because of that? No, it isn't. Let's say I have R500 and I want to use geometry shaders in Direct3D 11. What are my options? I can't use my R500 and I must manually switch to the device called WARP (Windows Advanced Rasterization Platform), which reports the 10_1 feature level. This kind of device is very similar to llvmpipe in Gallium. In the past you said we should do it the same way as Direct3D, so why should Gallium be different now? Moreover, if applications decide to use geometry shaders to emulate point sprites or wide lines, we'll be screwed. If they decide to do texture fetches in geometry shaders, we'll be screwed even more because we'll have to move textures out of VRAM and that will be a total performance killer. So I agree with Corbin that the CAP for geometry shaders should be added and we should let drivers decide what's best for them. Marek On Fri, Dec 25, 2009 at 5:11 PM, Zack Rusin wrote: > On Friday 25 December 2009 07:03:02 Corbin Simpson wrote: > > Isn't this incredibly at odds with our previous discussion, in which > > we generally agreed to not advertise support for unaccelerated things? > > No, it's really not. We don't have caps for core features, e.g we don't > have > caps for vertex shaders and this goes hand in hand with that. Geometry > shaders > are optional in the pipeline meaning that unlike fragment shaders they can > be > absent in which case the pipeline behaves just like it would if the api > didn't > have geometry shaders exposed at all i.e. vertex shader outputs go directly > do > the fragment shader. So for games/apps that don't use geometry shaders this > won't matter at all. And games/app that are so new that they actually check > for geometry shaders will already be slow on i915 and r300 not because of > geometry shaders, but because they're running on it on i915 or r300 =) > > Not to mention that this is not a fringe feature that will be present only > in > super high-end and futuristic hardware. > > All in all it's a bit like fixed-point hardware - programmable hardware is > not > a cap because it's what Gallium models. We can't just keep the Gallium > interface at i915 level and mark everything above that as a cap, it'd be > silly > given that we're generations past that now. > > z > > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
Half of the in-tree HW-accelerated drivers lack geo shaders, not to mention out-of-tree drivers. I politely request that drivers not be required to have the geo shader hooks filled out; mesa st can detect this and enable extensions appropriately. Posting from a mobile, pardon my terseness. ~ C. On Dec 25, 2009 8:16 AM, "Zack Rusin" wrote: On Friday 25 December 2009 07:03:02 Corbin Simpson wrote: > Isn't this incredibly at odds with our p... No, it's really not. We don't have caps for core features, e.g we don't have caps for vertex shaders and this goes hand in hand with that. Geometry shaders are optional in the pipeline meaning that unlike fragment shaders they can be absent in which case the pipeline behaves just like it would if the api didn't have geometry shaders exposed at all i.e. vertex shader outputs go directly do the fragment shader. So for games/apps that don't use geometry shaders this won't matter at all. And games/app that are so new that they actually check for geometry shaders will already be slow on i915 and r300 not because of geometry shaders, but because they're running on it on i915 or r300 =) Not to mention that this is not a fringe feature that will be present only in super high-end and futuristic hardware. All in all it's a bit like fixed-point hardware - programmable hardware is not a cap because it's what Gallium models. We can't just keep the Gallium interface at i915 level and mark everything above that as a cap, it'd be silly given that we're generations past that now. z -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
On Friday 25 December 2009 07:03:02 Corbin Simpson wrote: > Isn't this incredibly at odds with our previous discussion, in which > we generally agreed to not advertise support for unaccelerated things? No, it's really not. We don't have caps for core features, e.g we don't have caps for vertex shaders and this goes hand in hand with that. Geometry shaders are optional in the pipeline meaning that unlike fragment shaders they can be absent in which case the pipeline behaves just like it would if the api didn't have geometry shaders exposed at all i.e. vertex shader outputs go directly do the fragment shader. So for games/apps that don't use geometry shaders this won't matter at all. And games/app that are so new that they actually check for geometry shaders will already be slow on i915 and r300 not because of geometry shaders, but because they're running on it on i915 or r300 =) Not to mention that this is not a fringe feature that will be present only in super high-end and futuristic hardware. All in all it's a bit like fixed-point hardware - programmable hardware is not a cap because it's what Gallium models. We can't just keep the Gallium interface at i915 level and mark everything above that as a cap, it'd be silly given that we're generations past that now. z -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
Isn't this incredibly at odds with our previous discussion, in which we generally agreed to not advertise support for unaccelerated things? Geometry shaders are simply not going to have any kind of speed on i915, nv30, nv40, or r300. I can't speak for Jakob or the Nouveau guys, but at least r300g is trying to keep Draw usage to a minimum. I know i915 has to use Draw, so that won't be a problem, but nv30 and nv40 are Draw-free IIRC. ~ C. On Thu, Dec 24, 2009 at 6:09 AM, Keith Whitwell wrote: > Zack, > > In terms of advertising support for this - I wonder if this isn't something > we should just turn on for all drivers, given that in the worst case it is > just a vertex path fallback, and a lot of drivers will be hitting those for > various reasons anyway. > > Keith > > From: Zack Rusin [za...@vmware.com] > Sent: Thursday, December 24, 2009 5:24 AM > To: mesa3d-dev > Cc: Keith Whitwell; Michal Krol > Subject: geometry shading patches > > yo, > > after our discussions i hacked a new version of geometry shading support in > gallium. the new geometry shading syntax looks as follows: > GEOM > PROPERTY GS_INPUT_PRIMITIVE TRIANGLES > PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP > DCL IN[][0], POSITION, CONSTANT > DCL IN[][1], COLOR, CONSTANT > DCL OUT[0], POSITION, CONSTANT > DCL OUT[1], COLOR, CONSTANT > 0:MOV OUT[0], IN[0][0] > 1:MOV OUT[1], IN[0][1] > 2:EMIT > 3:MOV OUT[0], IN[1][0] > 4:MOV OUT[1], IN[1][1] > 5:EMIT > 6:MOV OUT[0], IN[2][0] > 7:MOV OUT[1], IN[2][1] > 8:EMIT > 9:ENDPRIM > 10:END > the attached patch series adds support for all of it throughout gallium > (including support for 2dimensional arrays in tgsi_sanity checking, tgsi_dump > and tgsi_text). > Right now don't support switching of primitives in the draw module (e.g. input > primitive being points and output primitive being a triangle_strip) but i'd > like to do that after committing the attached changes (also the semantic for > vertices which is a leftover from an old patch should be removed then if it's > ok with you). > > Keith, most relevant patches for you are 0001 and 0005. > Michal the most relevant to you are 0007, 0010, 0011 and 0012. > > z > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
Zack Rusin wrote on 2009-12-24 14:24: > yo, > > after our discussions i hacked a new version of geometry shading support in > gallium. the new geometry shading syntax looks as follows: > Zack, That looks nice. Once you commit I will take a closer look at patch #10 and see what's the issue there without bothering you. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
On Thursday 24 December 2009 10:03:25 Keith Whitwell wrote: > Thanks Zack. I'm fine with doing it on top of the others... ok, great, thanks Keith. In that case I'll wait for any objections until tomorrow and if nothing will show up commit in the morning. z -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
Thanks Zack. I'm fine with doing it on top of the others... Keith From: Zack Rusin [za...@vmware.com] Sent: Thursday, December 24, 2009 6:39 AM To: Keith Whitwell Cc: mesa3d-dev; Michal Krol Subject: Re: geometry shading patches On Thursday 24 December 2009 09:09:44 Keith Whitwell wrote: > Zack, > > In terms of advertising support for this - I wonder if this isn't something > we should just turn on for all drivers, given that in the worst case it is > just a vertex path fallback, and a lot of drivers will be hitting those > for various reasons anyway. Yes, I completely agree with both of your emails. The attached patches implement that (plus the last one comments out some unnecessary debugging output). They do it on top of the previous patches but if you'd like to have a history clear of them I can try to redo the entire series. z -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
On Thursday 24 December 2009 09:09:44 Keith Whitwell wrote:
> Zack,
>
> In terms of advertising support for this - I wonder if this isn't something
> we should just turn on for all drivers, given that in the worst case it is
> just a vertex path fallback, and a lot of drivers will be hitting those
> for various reasons anyway.
Yes, I completely agree with both of your emails. The attached patches
implement that (plus the last one comments out some unnecessary debugging
output). They do it on top of the previous patches but if you'd like to have a
history clear of them I can try to redo the entire series.
z
From 0483e3ed1c28982857da3292f8247388e8f9d0d9 Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Thu, 24 Dec 2009 09:20:45 -0500
Subject: [PATCH 13/15] util: put vertices_per_primitive function in its proper location
---
src/gallium/auxiliary/tgsi/tgsi_sanity.c |5 +--
src/gallium/auxiliary/tgsi/tgsi_text.c |4 +-
src/gallium/auxiliary/util/u_prim.h | 33 ++
src/gallium/include/pipe/p_inlines.h | 32 -
4 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_sanity.c b/src/gallium/auxiliary/tgsi/tgsi_sanity.c
index 5d11c19..16b8ec6 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_sanity.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_sanity.c
@@ -27,7 +27,7 @@
#include "util/u_debug.h"
#include "util/u_memory.h"
-#include "pipe/p_inlines.h"
+#include "util/u_prim.h"
#include "cso_cache/cso_hash.h"
#include "tgsi_sanity.h"
#include "tgsi_info.h"
@@ -463,8 +463,7 @@ iter_property(
if (iter->processor.Processor == TGSI_PROCESSOR_GEOMETRY &&
prop->Property.PropertyName == TGSI_PROPERTY_GS_INPUT_PRIM) {
- ctx->implied_array_size =
- pipe_vertices_per_primitive(prop->u[0].Data);
+ ctx->implied_array_size = u_vertices_per_prim(prop->u[0].Data);
}
return TRUE;
}
diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c
index ca247a1..825d17a 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_text.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
@@ -27,6 +27,7 @@
#include "util/u_debug.h"
#include "util/u_memory.h"
+#include "util/u_prim.h"
#include "pipe/p_defines.h"
#include "pipe/p_inlines.h"
#include "tgsi_text.h"
@@ -1187,8 +1188,7 @@ static boolean parse_property( struct translate_ctx *ctx )
}
if (property_name == TGSI_PROPERTY_GS_INPUT_PRIM &&
ctx->processor == TGSI_PROCESSOR_GEOMETRY) {
- ctx->implied_array_size =
-pipe_vertices_per_primitive(values[0]);
+ ctx->implied_array_size = u_vertices_per_prim(values[0]);
}
break;
default:
diff --git a/src/gallium/auxiliary/util/u_prim.h b/src/gallium/auxiliary/util/u_prim.h
index 7434329..10a874f 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -135,6 +135,39 @@ static INLINE unsigned u_reduced_prim( unsigned pipe_prim )
}
}
+static INLINE unsigned
+u_vertices_per_prim(int primitive)
+{
+ switch(primitive) {
+ case PIPE_PRIM_POINTS:
+ return 1;
+ case PIPE_PRIM_LINES:
+ case PIPE_PRIM_LINE_LOOP:
+ case PIPE_PRIM_LINE_STRIP:
+ return 2;
+ case PIPE_PRIM_TRIANGLES:
+ case PIPE_PRIM_TRIANGLE_STRIP:
+ case PIPE_PRIM_TRIANGLE_FAN:
+ return 3;
+ case PIPE_PRIM_LINES_ADJACENCY:
+ case PIPE_PRIM_LINE_STRIP_ADJACENCY:
+ return 4;
+ case PIPE_PRIM_TRIANGLES_ADJACENCY:
+ case PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY:
+ return 6;
+
+ /* following primitives should never be used
+* with geometry shaders abd their size is
+* undefined */
+ case PIPE_PRIM_POLYGON:
+ case PIPE_PRIM_QUADS:
+ case PIPE_PRIM_QUAD_STRIP:
+ default:
+ debug_printf("Unrecognized geometry shader primitive");
+ return 3;
+ }
+}
+
const char *u_prim_name( unsigned pipe_prim );
#endif
diff --git a/src/gallium/include/pipe/p_inlines.h b/src/gallium/include/pipe/p_inlines.h
index 95ec55d..5fbd62a 100644
--- a/src/gallium/include/pipe/p_inlines.h
+++ b/src/gallium/include/pipe/p_inlines.h
@@ -192,38 +192,6 @@ pipe_transfer_buffer_flags( struct pipe_transfer *transf )
}
}
-static INLINE unsigned
-pipe_vertices_per_primitive(int primitive)
-{
- switch(primitive) {
- case PIPE_PRIM_POINTS:
- return 1;
- case PIPE_PRIM_LINES:
- case PIPE_PRIM_LINE_LOOP:
- case PIPE_PRIM_LINE_STRIP:
- return 2;
- case PIPE_PRIM_TRIANGLES:
- case PIPE_PRIM_TRIANGLE_STRIP:
- case PIPE_PRIM_TRIANGLE_FAN:
- return 3;
- case PIPE_PRIM_LINES_ADJACENCY:
- case PIPE_PRIM_LINE_STRIP_ADJACENCY:
- return 4;
- case PIPE_PRIM_TRIANGLES_ADJACENCY:
- case PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY:
- return 6;
-
- /* following primitives should never be used
-* with geometry shaders */
- case PIPE_PRIM_POLYGON:
- case PIPE_PRIM_QUADS:
- case PIPE_PRIM_QUAD_STRIP:
- default:
- debug_printf
Re: [Mesa3d-dev] geometry shading patches
Zack, In terms of advertising support for this - I wonder if this isn't something we should just turn on for all drivers, given that in the worst case it is just a vertex path fallback, and a lot of drivers will be hitting those for various reasons anyway. Keith From: Zack Rusin [za...@vmware.com] Sent: Thursday, December 24, 2009 5:24 AM To: mesa3d-dev Cc: Keith Whitwell; Michal Krol Subject: geometry shading patches yo, after our discussions i hacked a new version of geometry shading support in gallium. the new geometry shading syntax looks as follows: GEOM PROPERTY GS_INPUT_PRIMITIVE TRIANGLES PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP DCL IN[][0], POSITION, CONSTANT DCL IN[][1], COLOR, CONSTANT DCL OUT[0], POSITION, CONSTANT DCL OUT[1], COLOR, CONSTANT 0:MOV OUT[0], IN[0][0] 1:MOV OUT[1], IN[0][1] 2:EMIT 3:MOV OUT[0], IN[1][0] 4:MOV OUT[1], IN[1][1] 5:EMIT 6:MOV OUT[0], IN[2][0] 7:MOV OUT[1], IN[2][1] 8:EMIT 9:ENDPRIM 10:END the attached patch series adds support for all of it throughout gallium (including support for 2dimensional arrays in tgsi_sanity checking, tgsi_dump and tgsi_text). Right now don't support switching of primitives in the draw module (e.g. input primitive being points and output primitive being a triangle_strip) but i'd like to do that after committing the attached changes (also the semantic for vertices which is a leftover from an old patch should be removed then if it's ok with you). Keith, most relevant patches for you are 0001 and 0005. Michal the most relevant to you are 0007, 0010, 0011 and 0012. z -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
Zack -- Impressive! Only one comment on patch #5 -- this is probably a util function rather than something for include/pipe. In particular we already have util/u_prim.h which has some similar functions in it -- I'd put this function there if possible... Keith From: Zack Rusin [za...@vmware.com] Sent: Thursday, December 24, 2009 5:24 AM To: mesa3d-dev Cc: Keith Whitwell; Michal Krol Subject: geometry shading patches yo, after our discussions i hacked a new version of geometry shading support in gallium. the new geometry shading syntax looks as follows: GEOM PROPERTY GS_INPUT_PRIMITIVE TRIANGLES PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP DCL IN[][0], POSITION, CONSTANT DCL IN[][1], COLOR, CONSTANT DCL OUT[0], POSITION, CONSTANT DCL OUT[1], COLOR, CONSTANT 0:MOV OUT[0], IN[0][0] 1:MOV OUT[1], IN[0][1] 2:EMIT 3:MOV OUT[0], IN[1][0] 4:MOV OUT[1], IN[1][1] 5:EMIT 6:MOV OUT[0], IN[2][0] 7:MOV OUT[1], IN[2][1] 8:EMIT 9:ENDPRIM 10:END the attached patch series adds support for all of it throughout gallium (including support for 2dimensional arrays in tgsi_sanity checking, tgsi_dump and tgsi_text). Right now don't support switching of primitives in the draw module (e.g. input primitive being points and output primitive being a triangle_strip) but i'd like to do that after committing the attached changes (also the semantic for vertices which is a leftover from an old patch should be removed then if it's ok with you). Keith, most relevant patches for you are 0001 and 0005. Michal the most relevant to you are 0007, 0010, 0011 and 0012. z -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
