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] glx_mangle.h seems to be missing entries and _glapi_Dispatch not defined
Heath Feather wrote: I am using the -DUSE_MGL_NAMESPACE option to build a name mangled version of Mesa (linux-x86-static). I first ran into some issues with glx_mangle.h requiring these additional entries. #define glXGetCurrentDisplay mglXGetCurrentDisplay #define glXChooseFBConfig mglXChooseFBConfig #define glXGetFBConfigAttrib mglXGetFBConfigAttrib #define glXGetFBConfigs mglXGetFBConfigs #define glXGetVisualFromFBConfig mglXGetVisualFromFBConfig #define glXCreateWindow mglXCreateWindow #define glXDestroyWindow mglXDestroyWindow #define glXCreatePixmap mglXCreatePixmap #define glXDestroyPixmap mglXDestroyPixmap #define glXCreatePbuffer mglXCreatePbuffer #define glXDestroyPbuffer mglXDestroyPbuffer #define glXQueryDrawable mglXQueryDrawable #define glXCreateNewContext mglXCreateNewContext #define glXMakeContextCurrent mglXMakeContextCurrent #define glXGetCurrentReadDrawable mglXGetCurrentReadDrawable #define glXQueryContext mglXQueryContext #define glXSelectEvent mglXSelectEvent #define glXGetSelectedEvent mglXGetSelectedEvent OK, I checked those in. Then I find that the mangled mesa library seems to be trying to reference _glapi_Dispatch, when it does not appear to be defined in the libraries. If you add #include glapi.h in glthread.h does that fix things? -Brian - 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] glx_mangle.h seems to be missing entries and _glapi_Dispatch not defined
(BTW, I'm using 6.5.1, forgot to mention that in the earlier message) I added glapi.h in glthread.h, but I still find _glapi_Dispatch undefined when I nm -oB the mangled libraries. However the _mglapi_Dispatch is there and defined, so I think the issue is that it _glapi_Dispatch is being referenced elsewhere in Mesa (glapi_x86, when the mangled one should be instead. This is the link error that leads me to believe this. ../../output/tarkits/linux86_32/gcc323/opt/liblgoMesa0651/lib/32bit/libl goMesaGLm.a(glapi_x86.o): In function `mglNewList': glapi_x86.o(.text+0x21): undefined reference to `_glapi_Dispatch' I messed around with this glapi_x86.S assembly module, and changed all occurences in which `_glapi_Dispatch' was referenced to _mglapi_Dispatch, and now I can link. Still need to do more testing to see if it is actually working however. So I am not sure as to whether the issue is that _mglapi_Dispatch is supposed to be the one called when running in mangled mode, or if _glapi_Dispatch is also supposed to be defined, and it isn't ? Heath. -Original Message- From: Brian Paul [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 10:32 AM To: Heath Feather Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] glx_mangle.h seems to be missing entries and _glapi_Dispatch not defined Heath Feather wrote: I am using the -DUSE_MGL_NAMESPACE option to build a name mangled version of Mesa (linux-x86-static). I first ran into some issues with glx_mangle.h requiring these additional entries. #define glXGetCurrentDisplay mglXGetCurrentDisplay #define glXChooseFBConfig mglXChooseFBConfig #define glXGetFBConfigAttrib mglXGetFBConfigAttrib #define glXGetFBConfigs mglXGetFBConfigs #define glXGetVisualFromFBConfig mglXGetVisualFromFBConfig #define glXCreateWindow mglXCreateWindow #define glXDestroyWindow mglXDestroyWindow #define glXCreatePixmap mglXCreatePixmap #define glXDestroyPixmap mglXDestroyPixmap #define glXCreatePbuffer mglXCreatePbuffer #define glXDestroyPbuffer mglXDestroyPbuffer #define glXQueryDrawable mglXQueryDrawable #define glXCreateNewContext mglXCreateNewContext #define glXMakeContextCurrent mglXMakeContextCurrent #define glXGetCurrentReadDrawable mglXGetCurrentReadDrawable #define glXQueryContext mglXQueryContext #define glXSelectEvent mglXSelectEvent #define glXGetSelectedEvent mglXGetSelectedEvent OK, I checked those in. Then I find that the mangled mesa library seems to be trying to reference _glapi_Dispatch, when it does not appear to be defined in the libraries. If you add #include glapi.h in glthread.h does that fix things? -Brian - 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] glx_mangle.h seems to be missing entries and _glapi_Dispatch not defined
Heath Feather wrote: glapi_x86.S is the trouble maker, it explicity generates calls to _glapi_Dispatch. A little snippet from the output from the preprocessor for this file looks like this .balign 16; .globl mglNewList ; .type mglNewList, function; mglNewList: movl _glapi_Dispatch,%eax ; testl %eax,%eax ; je 1f ; jmp *4 * 0(%eax) ; 1: call _x86_get_dispatch ; jmp *4 * 0(%eax) You'll note the mention of _glapi_Dispatch, It is glapi_x86.S that I modified to make it output _mglapi_Dispatch instead. I think the proper fix is to insert: #ifdef USE_MGL_NAMESPACE #define _glapi_Dispatch _mglapi_Dispatch #endif near the top of the generated .S files. I'll check in that change. Let me know if it works. -Brian - 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
