Re: [Mesa3d-dev] vbo heads up
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith I have tried to play a bit with that but i segfault in vbo_exec_array.c line 127 with varray in progs/redbook know bug or something from my side ? Btw i have thinked a bit more about the need to update max-min vertices in drawelements and drawrangeelements and i don't see an easy way to split the rendering as we have to go throught all indices and make sure that (max-min)*primsize never need more memory than what dma alloc can give us. Don't you have similar problem with intel ? You cannot split the commands nor remove copying of elts. r300 vertex cache is incorrectly configured and as a result of that, accessing elts twice (by the gpu) will cause r300 to crash immediately. You must upload new indices for every IDX packet. While this sucks it would suck even more if IDX packets wouldn't work at all. -- Aapo Tahkola - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
On 11/18/06, Aapo Tahkola [EMAIL PROTECTED] wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith I have tried to play a bit with that but i segfault in vbo_exec_array.c line 127 with varray in progs/redbook know bug or something from my side ? Btw i have thinked a bit more about the need to update max-min vertices in drawelements and drawrangeelements and i don't see an easy way to split the rendering as we have to go throught all indices and make sure that (max-min)*primsize never need more memory than what dma alloc can give us. Don't you have similar problem with intel ? You cannot split the commands nor remove copying of elts. r300 vertex cache is incorrectly configured and as a result of that, accessing elts twice (by the gpu) will cause r300 to crash immediately. You must upload new indices for every IDX packet. While this sucks it would suck even more if IDX packets wouldn't work at all. I was thinking of accumulating vertex in a buffer and submit then so we wouldn't exactly split the IDX packet but send a stream of vertex. Anyway i think this should be handled somewhere in mesa because all driver might suffer from that, even with new memory handler if your gart size doesn't fit the vertex and index buffer you end up in bad situation. best, Jerome Glisse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Jerome Glisse wrote: On 11/18/06, Aapo Tahkola [EMAIL PROTECTED] wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith I have tried to play a bit with that but i segfault in vbo_exec_array.c line 127 with varray in progs/redbook know bug or something from my side ? Btw i have thinked a bit more about the need to update max-min vertices in drawelements and drawrangeelements and i don't see an easy way to split the rendering as we have to go throught all indices and make sure that (max-min)*primsize never need more memory than what dma alloc can give us. Don't you have similar problem with intel ? You cannot split the commands nor remove copying of elts. r300 vertex cache is incorrectly configured and as a result of that, accessing elts twice (by the gpu) will cause r300 to crash immediately. You must upload new indices for every IDX packet. While this sucks it would suck even more if IDX packets wouldn't work at all. I was thinking of accumulating vertex in a buffer and submit then so we wouldn't exactly split the IDX packet but send a stream of vertex. Anyway i think this should be handled somewhere in mesa because all driver might suffer from that, even with new memory handler if your gart size doesn't fit the vertex and index buffer you end up in bad situation. I've been travelling for the last two weeks (and another long flight tonight) so I've had to let this sit for a little while. Hopefully I'll be alert enough on the flight to do a little more investigation. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Roland Scheidegger wrote: Below's the backtrace from Mesa's cva test, which uses DrawElements. The same thing also happens with software mesa (once you get past cva's gl version check...). Ah. Looks like vbo_exec_DrawRangeElements needs to call bind_arrays()? With this change, DrawElements seems to work. I noticed some glitches, however. Sometimes there seem to be random polygons around. For instance, quake3's intro screen gets (diagonally) split in two, with only the bottom-left part being correct (the game itself runs fine) - this happens with software mesa too. doom3 shows some glitches too sometimes, and was a bit prone to segfaults. ut2k3 failed an assertion, presumably due to the too many vertices the driver can handle (?), ut2003-bin: r200_ioctl.c:330: r200AllocDmaRegion: Assertion `rmesa-dma.current.ptr = rmesa-dma.current.end' failed. Roland - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Roland Scheidegger wrote: Roland Scheidegger wrote: Below's the backtrace from Mesa's cva test, which uses DrawElements. The same thing also happens with software mesa (once you get past cva's gl version check...). Ah. Looks like vbo_exec_DrawRangeElements needs to call bind_arrays()? With this change, DrawElements seems to work. I noticed some glitches, however. Sometimes there seem to be random polygons around. For instance, quake3's intro screen gets (diagonally) split in two, with only the bottom-left part being correct (the game itself runs fine) - this happens with software mesa too. doom3 shows some glitches too sometimes, and was a bit prone to segfaults. ut2k3 failed an assertion, presumably due to the too many vertices the driver can handle (?), ut2003-bin: r200_ioctl.c:330: r200AllocDmaRegion: Assertion `rmesa-dma.current.ptr = rmesa-dma.current.end' failed. These are almost certainly due to the issue I ran into yesterday - the tnl VB struct is a fixed size and may be smaller than the incoming arrays. I'm toying with a couple of different approaches to this, ranging from quick and dirty to impossibly grandiose... Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Roland Scheidegger wrote: Roland Scheidegger wrote: Below's the backtrace from Mesa's cva test, which uses DrawElements. The same thing also happens with software mesa (once you get past cva's gl version check...). Ah. Looks like vbo_exec_DrawRangeElements needs to call bind_arrays()? With this change, DrawElements seems to work. Yes, looks like it. Feel free to commit the change. Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Alex Deucher wrote: IIRC, radeons don't really have the limit either, I think the buffersize size stuff is a vestage of some past wrong... Didn't Roland look into some buffersize issues a while back? I could be way off though... Well, the radeon/r200 chips don't really have a hw limit neither, but the driver sure does. Trouble is, vertex array data is put into the vertex/indirect buffers, and those are 64k a piece - that's good enough for an array size up to 4096 (float4) entries (actually the driver currently doesn't set this limit (Const.MaxArrayLockSize), it probably should, but the default of 3000 works too). There are other limits currently too, for instance the indices are only 16 bits, and you can only emit somewhat below 32k of them at once (or below 16k if you'd use 32bit indices, though 32bit indices might be r200 only). This is actually afaik a hard limit of r100 chips, r200 could do the same as r300, with putting the indices into a separate buffer. Roland - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. How hard would it be to add some quick-and-dirty acceleration for CVAs in this branch? I ask for a couple reasons. First, it's on my Mesa wish-list. ;) Second, I think that the lack of acceleration for CVAs is a big part of the reason that fglrx beats the pants off r300 in Quake3 based games. According to the Phoronix review (below), gets nearly *DOUBLE* the framerate in Enemy Territory at 640x480 on an X300. Ouch. :( The gap closes as resolution increases. It stands to reason that we're not fill rate limited but geometry limited. It seems like we ought to be able to do something generic that could be enabled by any driver that provides real VBOs. Thoughts? That's the catch. I don't know how many drivers do provide real VBO's - does the r300 actually manage this? In a limited sense, yes. Until the i965 gets ported to the TTM memory manager, it is still using a fake-plus implementation of VBO's - it has backing store in regular memory which gets copied to AGP on usage, just like textures in the old DRI scheme. It may stay there for several usages, but can be knocked out at any time by another context. You run into a similar situation if you try to make the VBO module turn *all* incoming data into VBO's, like I thought would be clever when I started writing it: The upload path using VBO's would look like: - Identify locked array situation. - Copy locked arrays to VBO. - Inside the driver: Copy VBO to AGP. So you get a double copy. Compare to just leaving them alone: - Pass regular arrays to driver - Inside the driver: Copy arrays to AGP. Only one upload. With CVA, maybe the arrays will get used again in a subsequent drawing command, in which case you don't lose, or maybe 2 subsequent commands, in which case you win. I wonder if we could avoid one of the copies in the CVA case by implicitly using some APPLE_client_memory type functionality. Do some sort of a lazy copy. Hmm... If the driver actually does real VBOs and it allows us access to real AGP memory, we can do: - Identify locked array situation - Copy locked arrays to VBO in AGP space. Which is what you want. Right. Which is why the driver would have to flip the switch to enable that code path. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFS6OjX1gOwKyEAw8RApt7AJsFwPJMs8NyMLG2n5MEMymgw5vYtwCaAxoF yHG2ExDHP4lHRdv4hpNmz7A= =IPdn -END PGP SIGNATURE- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Keith Whitwell wrote:
OK, the first round of work on the VBO branch seems to have gone quite
smoothly. It'd be great if a couple of the key r200/r300 people could
check the branch out and verify whether I've broken those drivers or not.
It'd be particularly interesting to see if someone (Aapo?) can take a
look at the disabled vtxfmt_a code and see if it is easy to port that
over to the new archiecture. I've got a feeling it should be fairly
straight-forward, as it's simple to fallback to the tnl/ module for any
unexpected or non-handled situations.
I took a quick look at this and it seems doable. I sketched out a
simplified approach that just attempts to hook the existing code into a
_radeon_draw_prims() callback. It looks like it might work, but it
would be better to try for a deeper integration.
I'm pretty bullish about the vbo code would like to see an early
merge, so please take a look at this.
Keith
? diff
? server
Index: radeon_vtxfmt_a.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_vtxfmt_a.c,v
retrieving revision 1.22
diff -u -r1.22 radeon_vtxfmt_a.c
--- radeon_vtxfmt_a.c 23 Aug 2006 23:18:39 - 1.22
+++ radeon_vtxfmt_a.c 2 Nov 2006 10:20:28 -
@@ -46,6 +46,8 @@
#include state.h
#include image.h
+#include vbo/vbo_context.h
+
#define CONV_VB(a, b) rvb-AttribPtr[(a)].size = vb-b-size, \
rvb-AttribPtr[(a)].type = GL_FLOAT, \
rvb-AttribPtr[(a)].stride = vb-b-stride, \
@@ -129,15 +131,7 @@
CONV(i, VertexAttrib[i]);
for (i=0; i VERT_ATTRIB_MAX; i++) {
- if (enabled (1 i)) {
- rmesa-state.VB.AttribPtr[i].data += rmesa-state.VB.AttribPtr[i].stride * start;
- } else {
- def.data = ctx-Current.Attrib[i];
- memcpy(rmesa-state.VB.AttribPtr[i], def, sizeof(struct dt));
- }
-
- /*if(rmesa-state.VB.AttribPtr[i].data == ctx-Current.Attrib[i])
- fprintf(stderr, %d is default coord\n, i);*/
+ rmesa-state.VB.AttribPtr[i].data += rmesa-state.VB.AttribPtr[i].stride * start;
}
for(i=0; i VERT_ATTRIB_MAX; i++){
@@ -177,177 +171,11 @@
void radeon_init_vtxfmt_a(r300ContextPtr rmesa);
-static void radeonDrawElements( GLenum mode, GLsizei count, GLenum type, const GLvoid *c_indices )
-{
- GET_CURRENT_CONTEXT(ctx);
- r300ContextPtr rmesa = R300_CONTEXT(ctx);
- int elt_size;
- int i;
- unsigned int min = ~0, max = 0;
- struct tnl_prim prim;
- static void *ptr = NULL;
- struct r300_dma_region rvb;
- const GLvoid *indices = c_indices;
-
- if (count 65535) {
- WARN_ONCE(Too many verts!\n);
- goto fallback;
- }
-
- if (ctx-Array.ElementArrayBufferObj-Name) {
- /* use indices in the buffer object */
- if (!ctx-Array.ElementArrayBufferObj-Data) {
- _mesa_warning(ctx, DrawRangeElements with empty vertex elements buffer!);
- return;
- }
- /* actual address is the sum of pointers */
- indices = (GLvoid *)
- ADD_POINTERS(ctx-Array.ElementArrayBufferObj-Data, (const GLubyte *) c_indices);
- }
-
- if (!_mesa_validate_DrawElements( ctx, mode, count, type, indices ))
- return;
-
- FLUSH_CURRENT( ctx, 0 );
-
- memset(rvb, 0, sizeof(rvb));
- switch (type) {
- case GL_UNSIGNED_BYTE:
- for (i=0; i count; i++) {
- if(((unsigned char *)indices)[i] min)
-min = ((unsigned char *)indices)[i];
- if(((unsigned char *)indices)[i] max)
-max = ((unsigned char *)indices)[i];
- }
-
-#ifdef FORCE_32BITS_ELTS
- elt_size = 4;
-#else
- elt_size = 2;
-#endif
- r300AllocDmaRegion(rmesa, rvb, count * elt_size, elt_size);
- rvb.aos_offset = GET_START(rvb);
- ptr = rvb.address + rvb.start;
-
-#ifdef FORCE_32BITS_ELTS
- for (i=0; i count; i++)
- ((unsigned int *)ptr)[i] = ((unsigned char *)indices)[i] - min;
-#else
- for (i=0; i count; i++)
- ((unsigned short int *)ptr)[i] = ((unsigned char *)indices)[i] - min;
-#endif
- break;
-
- case GL_UNSIGNED_SHORT:
- for (i=0; i count; i++) {
- if(((unsigned short int *)indices)[i] min)
-min = ((unsigned short int *)indices)[i];
- if(((unsigned short int *)indices)[i] max)
-max = ((unsigned short int *)indices)[i];
- }
-
-#ifdef FORCE_32BITS_ELTS
- elt_size = 4;
-#else
- elt_size = 2;
-#endif
-
- r300AllocDmaRegion(rmesa, rvb, count * elt_size, elt_size);
- rvb.aos_offset = GET_START(rvb);
- ptr = rvb.address + rvb.start;
-
-#ifdef FORCE_32BITS_ELTS
- for (i=0; i count; i++)
- ((unsigned int *)ptr)[i] = ((unsigned short int *)indices)[i] - min;
-#else
- for (i=0; i count; i++)
- ((unsigned short int *)ptr)[i] = ((unsigned short int *)indices)[i] - min;
-#endif
- break;
-
- case GL_UNSIGNED_INT:
- for (i=0; i count; i++) {
- if(((unsigned int *)indices)[i] min)
-min = ((unsigned int *)indices)[i];
- if(((unsigned int *)indices)[i] max)
-max = ((unsigned int *)indices)[i];
- }
-
-#ifdef FORCE_32BITS_ELTS
- elt_size = 4;
-#else
- if (max - min = 65535)
- elt_size = 2;
- else
- elt_size = 4;
-#endif
- r300AllocDmaRegion(rmesa, rvb, count *
Re: [Mesa3d-dev] vbo heads up
On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. best, Jerome Glisse - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
On 11/2/06, Jerome Glisse [EMAIL PROTECTED] wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. After looking more carefully at your sketched patch i think it gonna be easier too handle but i would like to avoid fallback on such case. Then likely mean to split the command based on the primitive type. best, Jerome Glisse - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith I have tried to play a bit with that but i segfault in vbo_exec_array.c line 127 with varray in progs/redbook know bug or something from my side ? I see the same thing here, I'll fix it. Btw i have thinked a bit more about the need to update max-min vertices in drawelements and drawrangeelements and i don't see an easy way to split the rendering as we have to go throught all indices and make sure that (max-min)*primsize never need more memory than what dma alloc can give us. Don't you have similar problem with intel ? No, the i965 has no hardware restrictions on the size of the arrays, and I use texture memory to upload them, so I can allocate arbitarily large amounts. Only in the most extreme cases would I ever have to fail and fallback. Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
On 11/2/06, Jerome Glisse [EMAIL PROTECTED] wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith I have tried to play a bit with that but i segfault in vbo_exec_array.c line 127 with varray in progs/redbook know bug or something from my side ? Btw i have thinked a bit more about the need to update max-min vertices in drawelements and drawrangeelements and i don't see an easy way to split the rendering as we have to go throught all indices and make sure that (max-min)*primsize never need more memory than what dma alloc can give us. Don't you have similar problem with intel ? IIRC, radeons don't really have the limit either, I think the buffersize size stuff is a vestage of some past wrong... Didn't Roland look into some buffersize issues a while back? I could be way off though... Alex best, Jerome Glisse - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith I have tried to play a bit with that but i segfault in vbo_exec_array.c line 127 with varray in progs/redbook know bug or something from my side ? Btw i have thinked a bit more about the need to update max-min vertices in drawelements and drawrangeelements and i don't see an easy way to split the rendering as we have to go throught all indices and make sure that (max-min)*primsize never need more memory than what dma alloc can give us. Don't you have similar problem with intel ? I've fixed the initial problem, but hit another one related to the above -- namely that the tnl/ module currently *does* have size limits... I'd like to lift those limits by just reallocating memory as required, but it may be more cache friendly to chop large render requests into chunks. Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith I have tried to play a bit with that but i segfault in vbo_exec_array.c line 127 with varray in progs/redbook know bug or something from my side ? Btw i have thinked a bit more about the need to update max-min vertices in drawelements and drawrangeelements and i don't see an easy way to split the rendering as we have to go throught all indices and make sure that (max-min)*primsize never need more memory than what dma alloc can give us. Don't you have similar problem with intel ? I've fixed the initial problem, but hit another one related to the above -- namely that the tnl/ module currently *does* have size limits... I'd like to lift those limits by just reallocating memory as required, but it may be more cache friendly to chop large render requests into chunks. Keith I still see the segfault here, (line 129 this time). Should be fixed now. I also think it would be better to split big request into smaller chunk but that might be time consuming as you would have to go throught indices array to see how you can split. Splitting indexed requests is likely to involve plucking vertices out of the indices ahead of the pipeline, ie. turning them back into normal DrawArrays type rendering. Not appealing, but you can't guarantee progress any other way. For the radeon driver, it seems the limit was introduced with no reason at least from what i did understand on irc :). I guess that moving to ttm would provide us with a better and cleaner memory handling. Yep, though remember that it only applies to agp memory at this point. That's going to be fixed, though, and agp is enough to fix your current problem, so it might be worthwhile. Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
After testing a little more the change on r300 i raise the assertion in vbo_save_api.c/map_vertex_store (line 204). Also i loose vertex buffer when playing with varray (ie when you change with mouse boutton after a couple of change no things is draw anymore). I can look into this latter. best, Jerome Glisse - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. How hard would it be to add some quick-and-dirty acceleration for CVAs in this branch? I ask for a couple reasons. First, it's on my Mesa wish-list. ;) Second, I think that the lack of acceleration for CVAs is a big part of the reason that fglrx beats the pants off r300 in Quake3 based games. According to the Phoronix review (below), gets nearly *DOUBLE* the framerate in Enemy Territory at 640x480 on an X300. Ouch. :( The gap closes as resolution increases. It stands to reason that we're not fill rate limited but geometry limited. It seems like we ought to be able to do something generic that could be enabled by any driver that provides real VBOs. Thoughts? http://dri.freedesktop.org/wiki/MesaWishList http://www.phoronix.com/scan.php?page=articleitem=560num=1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFSo7MX1gOwKyEAw8RAj5WAJwPcuLkn2zWh3pOW5hoBGgTdkVU4gCfZs5k AKqFZIL8bLUMzb+Xei7ONWs= =l9Js -END PGP SIGNATURE- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
