Re: [Mesa-dev] Stream output
First of all top posting for make benefit glorious nation of Poland, also won't
have access to my email client for the next two weeks.
Correct, this is for stream output/transform feedback as devised on DX10 level
hardware. Anything that supports DX10 will support this (there's a CAP for it
of course). In general while the state itself is independent from geometry
shaders one could make the case that stream output needs it (which is what DX10
api does) or at least makes it a lot simpler (e.g. register_mask which
specifies the writemask for the given output can be trivially done in a
geometry shader).
I doubt emulation of all of this is very feasible, of course it really depends
what the hardware can actually do - if it can write post-vertex-shader any
number of output to buffers with writemasks then it might be possible.
Otherwise drivers are left with either using draw 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, 2010 at 11:43 AM, Zack Rusin za...@vmware.com wrote:
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 transaction costs).
In case of a successful completion of this transaction you'll be able to
indulge all your senses with a plethora of amazing new
words_combined_with_underscores. Some of my personal favorites include:
struct pipe_stream_output_state
{
/** number of the output buffer to insert each element into */
int output_buffer[PIPE_MAX_SHADER_OUTPUTS];
/** which register to grab each output from */
int register_index[PIPE_MAX_SHADER_OUTPUTS];
/** TGSI_WRITEMASK signifying which components to output */
ubyte register_mask[PIPE_MAX_SHADER_OUTPUTS];
/** number of outputs */
int num_outputs;
/** stride for an entire vertex, only used if all output_buffers
* are 0 */
unsigned stride;
};
which is the main stream output object and
struct p_context {
...
void * (*create_stream_output_state)(struct pipe_context *,
const struct pipe_stream_output_state
*);
void (*bind_stream_output_state)(struct pipe_context *, void *);
void (*delete_stream_output_state)(struct pipe_context*, void*);
void (*set_stream_output_buffers)(struct pipe_context *,
struct pipe_resource **buffers,
int *offsets, /*array of offsets
from the start of each
of the buffers */
int num_buffers);
};
There's also a short blurb about the whole thing in the official gallium
docs, you can preview it at
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/docs/source/context.rst?h=gallium-stream-out
.
If you have any concerns please let me know.
Ah, hello. I am going to university and working on a project. The
project is in C# and Java but I think that your project is like mine.
I would appreciate very much if you could email me the codes for your
project. My name is Corbin and I am in university. I do have several
questions though.
This is for vert feedback, not render-to-VBO, correct? Do we have a
list of HW that can do it? Is there a trivial way to emulate this on
older HW, or should those chipsets just use Draw?
Thank you very much for the docs. Looks good.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Drop glew from mesa
On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote: Jakob Bornecrantz wrote: On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Since we don't have any progs in mesa that uses glew anymore is it okay if we drop it? I have attached a patch which drops it its a bit big so I packed it. And here is the change thingy: configs/beos |2 +- configs/darwin |2 +- configs/default|4 +- configs/freebsd-dri|2 +- configs/linux-cell |2 +- configs/linux-dri-xcb |2 +- configs/linux-indirect |2 +- configure.ac |2 +- include/GL/glew.h |14435 include/GL/glxew.h | 1476 - include/GL/wglew.h | 1247 - src/SConscript |1 - src/glew/LICENSE.txt | 73 - src/glew/Makefile | 54 - src/glew/SConscript| 69 - src/glew/glew.c|14320 --- src/glew/glewinfo.c| 8441 src/glew/visualinfo.c | 1173 18 files changed, 8 insertions(+), 41299 deletions(-) This got stuck in the moderation queue, resending without the patch. Looks good. But it would be handy to have glew in the mesa-demos tree so that we don't all have find/install the latest version. Yes. And glut, could we move glut to demos too? It would make building on windows easy again. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Drop glew from mesa
On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote: Jakob Bornecrantz wrote: On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Since we don't have any progs in mesa that uses glew anymore is it okay if we drop it? I have attached a patch which drops it its a bit big so I packed it. And here is the change thingy: configs/beos | 2 +- configs/darwin | 2 +- configs/default | 4 +- configs/freebsd-dri | 2 +- configs/linux-cell | 2 +- configs/linux-dri-xcb | 2 +- configs/linux-indirect | 2 +- configure.ac | 2 +- include/GL/glew.h |14435 include/GL/glxew.h | 1476 - include/GL/wglew.h | 1247 - src/SConscript | 1 - src/glew/LICENSE.txt | 73 - src/glew/Makefile | 54 - src/glew/SConscript | 69 - src/glew/glew.c |14320 --- src/glew/glewinfo.c | 8441 src/glew/visualinfo.c | 1173 18 files changed, 8 insertions(+), 41299 deletions(-) This got stuck in the moderation queue, resending without the patch. Looks good. But it would be handy to have glew in the mesa-demos tree so that we don't all have find/install the latest version. Yes. And glut, could we move glut to demos too? It would make building on windows easy again. glut might be something that deserves its own repo since some people use Kilgard's glut as their system glut. Requiring them to get that from a demos package seems a little odd. But splitting it out of the main mesa package seems nice, if not just for licensing reasons. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Merge gallium-drm-driver-descriptor
On Mon, 2010-06-07 at 12:17 -0700, Jakob Bornecrantz wrote: Also I need to figure out a good way to solve some of the target helpers code. The current wrapper code doesn't work since it gets compiled into the aux archive which gets linked in after identity, rbug and trace so it can't find the symbols for the create functions. I tried making that function a inline, moving it the header file and it worked for me. Hmm, gallium_wrap_screen() seems to work fine in the existing targets. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stream output
On 07.06.2010 21:21, Marek Olšák wrote: On Mon, Jun 7, 2010 at 8:53 PM, Corbin Simpson mostawesomed...@gmail.com mailto:mostawesomed...@gmail.com wrote: This is for vert feedback, not render-to-VBO, correct? Do we have a list of HW that can do it? Is there a trivial way to emulate this on older HW, or should those chipsets just use Draw? gallium-stream-output == StreamOut in Direct3D 10 == render-to-vertex-buffer == vert feedback to a vertex buffer == Transform feedback in OpenGL. r300 could do it with some limitations since ATI has implemented something similar in Direct3D 9. No render-to-vertex-buffer is quite different, as this one uses data output from the normal rendering path (after rop), but transform feedback (streamout) outputs data even before the pixel shader is run. In theory, just about any chip could do render-to-vertex-buffer, as long as it has at least one format which is compatible to both rop output and vertex shader input. But only chips supporting DX10 typically can really export data after geometry shader stage. It doesn't look to me like any kind of emulation is really feasible nor desirable. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Drop glew from mesa
Dan Nicholson wrote: On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote: Jakob Bornecrantz wrote: On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Since we don't have any progs in mesa that uses glew anymore is it okay if we drop it? I have attached a patch which drops it its a bit big so I packed it. And here is the change thingy: configs/beos |2 +- configs/darwin |2 +- configs/default|4 +- configs/freebsd-dri|2 +- configs/linux-cell |2 +- configs/linux-dri-xcb |2 +- configs/linux-indirect |2 +- configure.ac |2 +- include/GL/glew.h |14435 include/GL/glxew.h | 1476 - include/GL/wglew.h | 1247 - src/SConscript |1 - src/glew/LICENSE.txt | 73 - src/glew/Makefile | 54 - src/glew/SConscript| 69 - src/glew/glew.c|14320 --- src/glew/glewinfo.c| 8441 src/glew/visualinfo.c | 1173 18 files changed, 8 insertions(+), 41299 deletions(-) This got stuck in the moderation queue, resending without the patch. Looks good. But it would be handy to have glew in the mesa-demos tree so that we don't all have find/install the latest version. Yes. And glut, could we move glut to demos too? It would make building on windows easy again. glut might be something that deserves its own repo since some people use Kilgard's glut as their system glut. Requiring them to get that from a demos package seems a little odd. But splitting it out of the main mesa package seems nice, if not just for licensing reasons. I'd be OK with that, but please don't remove it until glut is set up somewhere else, either in the demo repo or a new repo. I could move the glew sources into the demo tree but someone else will have to setup the automake stuff. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Current tinderbox regression (mesa)
http://tinderbox.x.org/builds/2010-06-08-0018/logs/libGL/#build swrastg_dri.so.tmp: undefined reference to `softpipe_delete_stream_output_state' swrastg_dri.so.tmp: undefined reference to `softpipe_bind_stream_output_state' swrastg_dri.so.tmp: undefined reference to `softpipe_create_stream_output_state' swrastg_dri.so.tmp: undefined reference to `softpipe_set_stream_output_buffers' -- Chris Ball c...@laptop.org One Laptop Per Child ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: r300 compiler loop emulation
Tom Stellard wrote: On Mon, Jun 07, 2010 at 08:38:15AM -0600, Brian Paul wrote: Tom Stellard wrote: Hi, I have just published a branch with loop emulation for the r300 compiler here: http://cgit.freedesktop.org/~tstellar/mesa/ This adds support for unrolling of loops that have a constant number of iterations (e.g. for(i=0; i10; i++) or for(i=10; i0; i--) It only handles cases where the counter is either added to or subtracted from, like the examples above, but I think this covers a majority of loops. Loops that have an unknown number of iterations are unrolled as many times as possible without going over the instruction limit for the shader program. Right now, this is only enabled for fragment shaders, but I am working on enabling it for vertex shaders. Any comments/suggestions would be appreciated. Thanks. Is there any advantage to doing this in the r300 compiler instead of the GLSL compiler? The GLSL compiler already does loop unrolling in some cases. If we do it in the GLSL compiler, all the drivers can benefit. The r300 compiler needs to have very aggressive loop unrolling for the r300 cards that don't have loop instructions. I am not sure if the kind of loop unrolling it is doing would be appropriate for the GLSL compiler in all cases. Although, I think you are right, just like other optimizations any loop unrolling that the GLSL complier can do would be a plus. I guess I'd like to see the loop unrolling code be primarily in the GLSL compiler. If the driver needs to give hints to the compiler (such as always unroll or never unroll) we can add additional flags to struct gl_shader_state. Drivers can set those flags and the compiler will follow them. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Stream output
On Tue, Jun 8, 2010 at 6:25 AM, Roland Scheidegger srol...@vmware.com wrote: But only chips supporting DX10 typically can really export data after geometry shader stage. It doesn't look to me like any kind of emulation is really feasible nor desirable. With that in mind, do we want to introduce a new object for this? pipe_stream_feedback or something along those lines? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Drop glew from mesa
On Tue, Jun 8, 2010 at 3:51 PM, Brian Paul bri...@vmware.com wrote: Dan Nicholson wrote: On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote: Jakob Bornecrantz wrote: On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Since we don't have any progs in mesa that uses glew anymore is it okay if we drop it? I have attached a patch which drops it its a bit big so I packed it. And here is the change thingy: configs/beos | 2 +- configs/darwin | 2 +- configs/default | 4 +- configs/freebsd-dri | 2 +- configs/linux-cell | 2 +- configs/linux-dri-xcb | 2 +- configs/linux-indirect | 2 +- configure.ac | 2 +- include/GL/glew.h |14435 include/GL/glxew.h | 1476 - include/GL/wglew.h | 1247 - src/SConscript | 1 - src/glew/LICENSE.txt | 73 - src/glew/Makefile | 54 - src/glew/SConscript | 69 - src/glew/glew.c |14320 --- src/glew/glewinfo.c | 8441 src/glew/visualinfo.c | 1173 18 files changed, 8 insertions(+), 41299 deletions(-) This got stuck in the moderation queue, resending without the patch. Looks good. But it would be handy to have glew in the mesa-demos tree so that we don't all have find/install the latest version. Yes. And glut, could we move glut to demos too? It would make building on windows easy again. glut might be something that deserves its own repo since some people use Kilgard's glut as their system glut. Requiring them to get that from a demos package seems a little odd. But splitting it out of the main mesa package seems nice, if not just for licensing reasons. I'd be OK with that, but please don't remove it until glut is set up somewhere else, either in the demo repo or a new repo. I could move the glew sources into the demo tree but someone else will have to setup the automake stuff. I'm sure we can also make automake detect if glu and glut is installed and use the system ones instead of the ones shipping within the demos repo (also overridden with a option). Can we do the same to glu and glw? Giving --disable-glu --disable-glw --disable-glut as arguments to configure is getting old. Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Drop glew from mesa
On Tue, Jun 8, 2010 at 5:26 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Tue, Jun 8, 2010 at 3:51 PM, Brian Paul bri...@vmware.com wrote: Dan Nicholson wrote: On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote: Jakob Bornecrantz wrote: On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Since we don't have any progs in mesa that uses glew anymore is it okay if we drop it? I have attached a patch which drops it its a bit big so I packed it. And here is the change thingy: configs/beos | 2 +- configs/darwin | 2 +- configs/default | 4 +- configs/freebsd-dri | 2 +- configs/linux-cell | 2 +- configs/linux-dri-xcb | 2 +- configs/linux-indirect | 2 +- configure.ac | 2 +- include/GL/glew.h |14435 include/GL/glxew.h | 1476 - include/GL/wglew.h | 1247 - src/SConscript | 1 - src/glew/LICENSE.txt | 73 - src/glew/Makefile | 54 - src/glew/SConscript | 69 - src/glew/glew.c |14320 --- src/glew/glewinfo.c | 8441 src/glew/visualinfo.c | 1173 18 files changed, 8 insertions(+), 41299 deletions(-) This got stuck in the moderation queue, resending without the patch. Looks good. But it would be handy to have glew in the mesa-demos tree so that we don't all have find/install the latest version. Yes. And glut, could we move glut to demos too? It would make building on windows easy again. glut might be something that deserves its own repo since some people use Kilgard's glut as their system glut. Requiring them to get that from a demos package seems a little odd. But splitting it out of the main mesa package seems nice, if not just for licensing reasons. I'd be OK with that, but please don't remove it until glut is set up somewhere else, either in the demo repo or a new repo. I could move the glew sources into the demo tree but someone else will have to setup the automake stuff. I'm sure we can also make automake detect if glu and glut is installed and use the system ones instead of the ones shipping within the demos repo (also overridden with a option). What I'd like to do sooner or later is add *-uninstalled.pc files to the repo to support the I want to link the demos against the libGL in my mesa tree case that I figure lots of developers use. Then you could just do PKG_CONFIG_PATH=$HOME/src/mesa and the demo tree would never know the difference. Can we do the same to glu and glw? Giving --disable-glu --disable-glw --disable-glut as arguments to configure is getting old. Again, people/distros use these as their system glu and glw, so you can't just drop them from the mesa repo without moving them to an alternate location. However, we can easily make configure default to not building them. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Drop glew from mesa
On Wed, Jun 9, 2010 at 2:41 AM, Dan Nicholson dbn.li...@gmail.com wrote: On Tue, Jun 8, 2010 at 5:26 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Tue, Jun 8, 2010 at 3:51 PM, Brian Paul bri...@vmware.com wrote: Dan Nicholson wrote: On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote: Jakob Bornecrantz wrote: On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Since we don't have any progs in mesa that uses glew anymore is it okay if we drop it? I have attached a patch which drops it its a bit big so I packed it. And here is the change thingy: configs/beos | 2 +- configs/darwin | 2 +- configs/default | 4 +- configs/freebsd-dri | 2 +- configs/linux-cell | 2 +- configs/linux-dri-xcb | 2 +- configs/linux-indirect | 2 +- configure.ac | 2 +- include/GL/glew.h |14435 include/GL/glxew.h | 1476 - include/GL/wglew.h | 1247 - src/SConscript | 1 - src/glew/LICENSE.txt | 73 - src/glew/Makefile | 54 - src/glew/SConscript | 69 - src/glew/glew.c |14320 --- src/glew/glewinfo.c | 8441 src/glew/visualinfo.c | 1173 18 files changed, 8 insertions(+), 41299 deletions(-) This got stuck in the moderation queue, resending without the patch. Looks good. But it would be handy to have glew in the mesa-demos tree so that we don't all have find/install the latest version. Yes. And glut, could we move glut to demos too? It would make building on windows easy again. glut might be something that deserves its own repo since some people use Kilgard's glut as their system glut. Requiring them to get that from a demos package seems a little odd. But splitting it out of the main mesa package seems nice, if not just for licensing reasons. I'd be OK with that, but please don't remove it until glut is set up somewhere else, either in the demo repo or a new repo. I could move the glew sources into the demo tree but someone else will have to setup the automake stuff. I'm sure we can also make automake detect if glu and glut is installed and use the system ones instead of the ones shipping within the demos repo (also overridden with a option). What I'd like to do sooner or later is add *-uninstalled.pc files to the repo to support the I want to link the demos against the libGL in my mesa tree case that I figure lots of developers use. Then you could just do PKG_CONFIG_PATH=$HOME/src/mesa and the demo tree would never know the difference. Or just use GL_CFLAGS=-I$HOME/src/mesa/include GL_LDFLAGS=-L$HOME/src/mesa/lib ./configure, but I guess the *-uninstalled.pc is less typing. Tho can .pc point to directories relative to the location of the .pc file? That will help for linking but not running without setting up LD_LIBRARY_PATH, tho I know automake can generate wrapper scripts if you use progname_LDADD = my_lib.la that picks up the right library at run time (see drm.git/tests/kmstest). I dunno if it will do the right thing with libraries added via AM_LDFLAGS, or ones external to the current build. Can we do the same to glu and glw? Giving --disable-glu --disable-glw --disable-glut as arguments to configure is getting old. Again, people/distros use these as their system glu and glw, so you can't just drop them from the mesa repo without moving them to an alternate location. However, we can easily make configure default to not building them. Sorry communication error on my part, thats what I wanted to do, just as long as I don't have to deal with them in Mesa. Move them either to the demos repo (but that feels like shuffling lint from one pocket to another), or their own separate repository. I'm perfectly content with using the ones from my distro, they have hardly changed in the last past 5 years. Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
