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
[Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
This patch adds two extensions, EGL_MESA_gallium and GLX_MESA_gallium, which allow an application to directly access the Gallium3D API bypassing OpenGL and using EGL or GLX for general setup. The python state tracker already uses the GLX_MESA_gallium functions (due to a commit by Jose Fonseca), but the functions are not actually implemented. There is already a WGL extension with wglGetGalliumScreenMESA and wglCreateGalliumContextMESA. A wglGetGalliumSurfacesMESA function should probably be added to match the EGL/GLX versions in this patch. It adds 3 functions: (egl|glx)GetGalliumScreenMESA: returns a pipe_screen for an X11 display/screen or an EGL display (egl|glx)CreateGalliumContextMESA: creates a pipe_context for an X11 display/screen or an EGL display (egl|glx)GetGalliumSurfacesMESA: returns all pipe_surface attachments for an X11 drawable or EGL surface The array returned by GetGalliumSurfacesMESA must be freed by the application. They are implemented for egl_glx, and the EGL and GLX DRI loaders and drivers. The egl_glx implementation simply wraps the GLX functions. The first two functions are trivially implemented, while GetGalliumSurfaces is trickier. The problem is that the current code assumes that a GL context is bound when getting surfaces, so most of the invasive changes in this patch remove this assumption. Currently, this only works for double buffered DRI surfaces, because the flush_framebuffer functions provided by DRI get the surface to flush from the current GL context. How to fix this is not obvious. An option could be to provide an (egl|glx)FlushFrontbuffer function with takes a drawable as input. Another option would be to change (egl|glx)SwapBuffers to do frontbuffer flushing without a GL context (it currently does that indirectly by calling glFlush()). Also currently surfaces are extracted from an st_framebuffer, which is not ideal as it keeps a dependency on the Mesa state tracker The patch assumes that my previous MESA_screen_surface patch has been applied. The patches are independent, but they textually conflict on the function tables. A GL_MESA_gallium extension could be implemented in the future for access to the underlying Gallium objects of OpenGL textures, buffers and renderbuffers. Some way to access the GLSL compiler without OpenGL would also be useful. --- include/EGL/eglext.h | 20 +++ include/GL/glxext.h | 20 +++ include/GL/internal/dri_interface.h | 19 +++ src/egl/drivers/glx/egl_glx.c | 28 ++ src/egl/main/eglapi.c | 40 ++- src/egl/main/eglapi.h | 11 src/egl/main/egldisplay.h |1 + src/egl/main/eglmisc.c|6 ++- src/gallium/state_trackers/dri/dri_drawable.c |4 +- src/gallium/state_trackers/dri/dri_screen.c | 38 ++ src/gallium/state_trackers/egl/egl_tracker.c | 26 + src/gallium/winsys/egl_xlib/egl_xlib.c| 54 +++- src/glx/x11/dri_common.c |7 +++ src/glx/x11/glxclient.h |7 +++ src/glx/x11/glxcmds.c | 69 + src/glx/x11/glxcurrent.c | 13 +++-- src/glx/x11/glxextensions.c |1 + src/glx/x11/glxextensions.h |1 + src/mesa/state_tracker/st_cb_fbo.c| 26 ++ src/mesa/state_tracker/st_cb_fbo.h|4 ++ src/mesa/state_tracker/st_framebuffer.c | 51 ++ src/mesa/state_tracker/st_public.h|8 +++- 22 files changed, 409 insertions(+), 45 deletions(-) diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h index b65f7f2..1b94784 100644 --- a/include/EGL/eglext.h +++ b/include/EGL/eglext.h @@ -179,6 +179,26 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLCOPYCONTEXTMESA) (EGLDisplay dpy, EGLCont #endif /* EGL_MESA_copy_context */ +/* EGL_MESA_gallium >>> PRELIMINARY <<< */ +#ifndef EGL_MESA_gallium +#define EGL_MESA_gallium 1 + +struct pipe_screen; +struct pipe_context; +struct pipe_surface; + +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI struct pipe_screen* EGLAPIENTRY eglGetGalliumScreenMESA(EGLDisplay dpy); +EGLAPI struct pipe_context* EGLAPIENTRY eglCreateGalliumContextMESA(EGLDisplay dpy); +EGLAPI int EGLAPIENTRY eglGetGalliumSurfacesMESA(EGLDisplay* dpy, EGLSurface surface, struct pipe_surface*** surfaces); +#endif /* EGL_EGLEXT_PROTOTYPES */ + +typedef struct pipe_screen* (EGLAPIENTRYP PFNEGLGETGALLIUMSCREENMESA)(EGLDisplay dpy); +typedef struct pipe_context* (EGLAPIENTRYP PFNEGLCREATEGALLIUMCONTEXTMESA)(EGLDisplay dpy); +typedef int (EGLAPIENTRYP PFNEGLGETGALLIUMSURFACESMESA)(EGLDisplay* dpy, EGLSurface surface, struct pipe_surface*** surfaces); + +#endif /* EGL_MESA_gallium */ + #ifdef __cplusplus } #endif diff --git a/include/GL/glxext.h b/include
[Mesa3d-dev] [PATCH] Add MESA_screen_surface support to egl_glx and egl_xlib
This patch adds MESA_screen_surface support to the egl_glx EGL->GLX
wrapper and egl_xlib Gallium state tracker.
With this patch applied, you should be able to just run eglgears from
an X11 terminal and get a maximized hardware accelerated gears window.
Screen surfaces are window surfaces where the X11 window is created by
the EGL driver. Showing a screen surface calls XMapWindow on it. The
window is automatically made maximized or fullscreen if the size makes
it necessary.
A single screen mode is advertised, which sized by default like the
size of the client area of a maximized window.
The EGL_FULLSCREEN=[WxH[xRATE]] and EGL_WINDOW=WxH options can be used
to force fullscreen or a window with the appropriate dimensions.
It also changes the default EGL driver for X11 to be egl_glx rather
than egl_softpipe, as this gives a good chance of being able to use
hardware acceleration.
The core X11 code is in src/egl/main/eglx11.[ch] and it is called both
by egl_x11 and Gallium egl_xlib.
It uses the WM protocol to determine work area and frame sizes and
(try to) compute the size of a maximized window and xrandr to change
fullscreen mode.
---
configure.ac |6 +-
src/egl/drivers/glx/egl_glx.c | 157 +-
src/egl/main/Makefile |6 +-
src/egl/main/eglconfig.c |1 +
src/egl/main/eglconfigutil.c |2 +-
src/egl/main/egldriver.c |2 +-
src/egl/main/eglsurface.c |2 +-
src/egl/main/eglx11.c | 537
src/egl/main/eglx11.h | 21 ++
src/gallium/winsys/egl_xlib/Makefile | 13 +-
src/gallium/winsys/egl_xlib/egl_xlib.c | 95 ++-
11 files changed, 815 insertions(+), 27 deletions(-)
create mode 100644 src/egl/main/eglx11.c
create mode 100644 src/egl/main/eglx11.h
diff --git a/configure.ac b/configure.ac
index d83dd43..83b14b5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -890,11 +890,11 @@ if test "x$enable_egl" = xyes; then
SRC_DIRS="$SRC_DIRS egl"
if test "$x11_pkgconfig" = yes; then
-PKG_CHECK_MODULES([EGL], [x11])
+PKG_CHECK_MODULES([EGL], [x11 xrandr])
EGL_LIB_DEPS="$EGL_LIBS"
else
# should check these...
-EGL_LIB_DEPS="$X_LIBS -lX11"
+EGL_LIB_DEPS="$X_LIBS -lX11 -lXrandr"
fi
EGL_LIB_DEPS="$EGL_LIB_DEPS $DLOPEN_LIBS"
fi
diff --git a/src/egl/drivers/glx/egl_glx.c b/src/egl/drivers/glx/egl_glx.c
index 96292b0..55f99b5 100644
--- a/src/egl/drivers/glx/egl_glx.c
+++ b/src/egl/drivers/glx/egl_glx.c
@@ -33,10 +33,13 @@
* Authors: Alan Hourihane
*/
+#define GLX_GLXEXT_PROTOTYPES
#include
#include
+#include
#include
#include
+#include
#include "eglconfigutil.h"
#include "eglconfig.h"
@@ -46,6 +49,9 @@
#include "eglglobals.h"
#include "egllog.h"
#include "eglsurface.h"
+#include "eglscreen.h"
+#include "eglmode.h"
+#include "eglx11.h"
#define CALLOC_STRUCT(T) (struct T *) calloc(1, sizeof(struct T))
#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
@@ -67,6 +73,7 @@ struct GLX_egl_driver
_EGLDriver Base; /**< base class */
};
+struct GLX_egl_surface;
/** driver data of _EGLDisplay */
struct GLX_egl_display
@@ -91,6 +98,9 @@ struct GLX_egl_display
EGLBoolean single_buffered_quirk;
EGLBoolean glx_window_quirk;
+ _EGLX11Screen* x11;
+
+ struct GLX_egl_surface* screen_surface;
};
@@ -200,7 +210,7 @@ static const struct {
static EGLBoolean
convert_fbconfig(Display *dpy, GLXFBConfig fbconfig,
- struct GLX_egl_config *GLX_conf)
+ struct GLX_egl_config *GLX_conf, int force_rgba)
{
__GLcontextModes mode;
int err = 0, attr, val, i;
@@ -223,10 +233,17 @@ convert_fbconfig(Display *dpy, GLXFBConfig fbconfig,
if (err)
return EGL_FALSE;
+ if(force_rgba)
+ mode.renderType = GLX_RGBA_BIT;
+
/* must have rgba bit */
if (!(mode.renderType & GLX_RGBA_BIT))
return EGL_FALSE;
+ /* EGL doesn't support accumulation buffers and we don't want them
as their mode are marked "Slow" */
+ if(mode.accumRedBits || mode.accumGreenBits || mode.accumBlueBits
|| mode.accumAlphaBits)
+ return EGL_FALSE;
+
/* pixmap and pbuffer surfaces must be single-buffered in EGL */
if (mode.doubleBufferMode) {
mode.drawableType &= ~(GLX_PIXMAP_BIT | GLX_PBUFFER_BIT);
@@ -377,7 +394,7 @@ fix_config(struct GLX_egl_display *GLX_dpy, struct
GLX_egl_config *GLX_conf)
surface_type = GET_CONFIG_ATTRIB(conf, EGL_SURFACE_TYPE);
if (!GLX_conf->double_buffered && GLX_dpy->single_buffered_quirk) {
/* some GLX impls do not like single-buffered window surface */
- surface_type &= ~EGL_WINDOW_BIT;
+ surface_type &= ~(EGL_WINDOW_BIT | EGL_SCREEN_BIT_MESA);
/* pbuffer bit is usually not set */
if (GLX_dpy->have_pbuffer)
surface_type |= EGL_PBUFFER_BIT;
@@ -405,23 +422,47 @@ create_configs(_EGLDispl
[Mesa3d-dev] [PATCH] Add GALLIUM_DUMP_VS environment variable
Add GALLIUM_DUMP_VS to dump the vertex shader to the console like
GALLIUM_DUMP_FS in softpipe.
diff --git a/src/gallium/auxiliary/draw/draw_private.h
b/src/gallium/auxiliary/draw/draw_private.h
index 3850ced..3f9eca8 100644
--- a/src/gallium/auxiliary/draw/draw_private.h
+++ b/src/gallium/auxiliary/draw/draw_private.h
@@ -170,6 +170,7 @@ struct draw_context
boolean bypass_clipping; /**< set if either api or driver
bypass_clipping true */
boolean force_passthrough; /**< never clip or shade */
+ boolean dump_vs;
double mrd; /**< minimum resolvable depth value, for polygon offset */
diff --git a/src/gallium/auxiliary/draw/draw_vs.c
b/src/gallium/auxiliary/draw/draw_vs.c
index 3553689..fd64dd2 100644
--- a/src/gallium/auxiliary/draw/draw_vs.c
+++ b/src/gallium/auxiliary/draw/draw_vs.c
@@ -83,6 +83,9 @@ draw_create_vertex_shader(struct draw_context *draw,
{
struct draw_vertex_shader *vs;
+ if (draw->dump_vs)
+ tgsi_dump(shader->tokens, 0);
+
vs = draw_create_vs_llvm( draw, shader );
if (!vs) {
vs = draw_create_vs_sse( draw, shader );
@@ -152,6 +155,8 @@ draw_delete_vertex_shader(struct draw_context *draw,
boolean
draw_vs_init( struct draw_context *draw )
{
+ draw->dump_vs = debug_get_bool_option( "GALLIUM_DUMP_VS", FALSE );
+
draw->vs.machine = tgsi_exec_machine_create();
if (!draw->vs.machine)
return FALSE;
--
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
[Mesa3d-dev] [Bug 25778] radeon driver crashes kwin
http://bugs.freedesktop.org/show_bug.cgi?id=25778 --- Comment #3 from Michel Dänzer 2009-12-25 07:01:00 PST --- (In reply to comment #2) > How can I obtain better backtrace? E.g. by making sure debugging symbols are available for all binaries involved, in particular /usr/lib/libGL.so.1 . > I also never used valgrind, how can I get the info you need? Something like valgrind kwin --replace should be a start. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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] [Mesa3d-announce] Mesa 7.6.1 and Mesa 7.7 release
Hi Ian, On Mon, Dec 21, 2009 at 18:43:41 -0800, Ian Romanick wrote: > The official notification will be posted to the Mesa website shortly. > > Mesa 7.6.1 available for download at > ftp://freedesktop.org/pub/mesa/7.6.1/ > [...] > > Mesa 7.7 available for download at ftp://freedesktop.org/pub/mesa/7.7/ > [...] Could you push git tags for these? Thanks, Julien -- 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
