Re: [Mesa3d-dev] Re: DRI and Mesa core patch for GLSL varyings
On 07/04/06, Brian Paul <[EMAIL PROTECTED]> wrote: > > Before we get to that point, I'd like to reconsider a few things in > the code. Specifically, the way the tnl and swrast modules interface > in terms of vertex attributes. The span_arrays struct is getting > pretty big (over 800KB now) and the s_tritemp.h code is becoming > unwieldy. There's got to be a better way of handling all the > interpolants and use less memory. > The GLSL vertex attributes cannot alias with conventional attributes. This makes a total count of 32 vertex attribute vectors. The same apply to varyings, they cannot alias with texcoords. I can only cut in half the fat by tightly packing varyings. This gives 500K of varyings for 4096 viewport width. When I started working with tnl to swrast interface I falsely concluded, by quick look at the structures, that number of vertex attrib slots must be equal to number of fragment attrib (varying) slots. Funny. I suspect there can be an issue regarding vertex attrib aliasing in NV_vp. I can be wrong, but some code assumes VERT_ATTRIB_MAX to be always equal to MAX_VERTEX_PROGRAM_ATTRIBS. And now, when VERT_ATTRIB_MAX is pumped up to 32, it can result in wrong behaviour. > There's a few things that didn't work. > > First, the patch didn't apply cleanly the the CVS trunk. I had to > manually apply a few of the patches. t_vb_arbshader.c was the main one. > > In r300_state.c you need to replace "r300_outputs_written" with "union > r300_outputs_written". In C++ you don't need the 'union', but you do > for C. > > In savetris.c you need to replace _TNL_BIT_TEX1 with _TNL_ATTRIB_TEX1 > at line 880. > > BTW, I'd still like to see the code re-indented to the Mesa standard > someday (3-space indentation, etc) and filtered to remove the carriage > return chars. > Okay, I understand that with this changes I can safely commit the code now. -- Pozdrawiam, Michal Krol --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 6484] 64 Bit mesa-6.4.2 crashes on Solaris 9 compiled with gcc 4.0.2
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6484 --- Additional Comments From [EMAIL PROTECTED] 2006-04-08 01:28 --- If there's ever a need Brian - give me a shout. I've got an Ultra 60 here that you can either ssh into or I'll build test. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 6484] 64 Bit mesa-6.4.2 crashes on Solaris 9 compiled with gcc 4.0.2
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6484 --- Additional Comments From [EMAIL PROTECTED] 2006-04-08 01:22 --- OK, I've added sunos5-64-gcc to the toplevel Makefile. The src/mesa/sparc/glapi_sparc.S file wasn't getting regenerated so it was missing those three functions you listed. Should be OK now. I suppose having an old sparc machine would be handy, but I've already got at least 10 computers in my office. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Re: DRI and Mesa core patch for GLSL varyings
Michał Król wrote: On 06/04/06, Brian Paul <[EMAIL PROTECTED]> wrote: I think the arbitrary-length bitset type is overkill. We really just need a 64-bit bitfield for the foreseeable future, right? These macros in bitset.h are pretty "heavy" if all the bitsets are just 64 bits or less. [...] The code would be far more efficient this way. What do you think? I still need to review the rest of the patch in more detail. Maybe this evening - I've got other things I need to work on. The specialization given above is okay, but to make it future proof, I would suggest the following. 1) Leave the generic bitset macros as they are. 2) Suffix 64-bit versions with "64", e.g. BITSET64_COPY. 3) In "t_context.h", where DECLARE_RENDER_INPUTS is declared, also define macro names for operations, not just declarations, e.g. #define RENDERINPUTS_COPY(x,y) BITSET64_COPY(x,y) ... and then use them in drivers and mesa core, in place of BITSET_* as it is now, in the patch. I could live with that. The key thing is to use simple types and native 64-bit types whenever possible and avoid the memcpy(), etc. This way we can do transition to, say, 128-bit flags without touching drivers. Also, this reduces the overall burden, when more bit-fields will need multi-word handling. This will happen to swrast, when more than 64 varyings are needed. Before we get to that point, I'd like to reconsider a few things in the code. Specifically, the way the tnl and swrast modules interface in terms of vertex attributes. The span_arrays struct is getting pretty big (over 800KB now) and the s_tritemp.h code is becoming unwieldy. There's got to be a better way of handling all the interpolants and use less memory. For now, I just need a confirmation that my changes will not break compilation of drivers. Then I can safely apply your proposals in my next cvs commit. There's a few things that didn't work. First, the patch didn't apply cleanly the the CVS trunk. I had to manually apply a few of the patches. t_vb_arbshader.c was the main one. In r300_state.c you need to replace "r300_outputs_written" with "union r300_outputs_written". In C++ you don't need the 'union', but you do for C. In savetris.c you need to replace _TNL_BIT_TEX1 with _TNL_ATTRIB_TEX1 at line 880. BTW, I'd still like to see the code re-indented to the Mesa standard someday (3-space indentation, etc) and filtered to remove the carriage return chars. -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 6484] 64 Bit mesa-6.4.2 crashes on Solaris 9 compiled with gcc 4.0.2
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=6484 --- Additional Comments From [EMAIL PROTECTED] 2006-04-08 01:05 --- Hello Brian, thank you for the changed configs file for solaris (sunos5-64-gcc). To run make sunos5-64-gcc I've to correct the Makefile first: /opt/sfw/bin/cvs diff Makefile Index: Makefile === RCS file: /cvs/mesa/Mesa/Makefile,v retrieving revision 1.63 diff -r1.63 Makefile 128a129 > sunos5-64-gcc \ So, please add this line to the main Makefile. (Does anybody of the Mesa developer team has access to an old cheap ultrasparc solaris system? That could make bug fixing more easy) The build stopped at: make[2]: Entering directory `/mnt/home/egger/src/Mesa/cvs/Mesa/progs/demos' gcc -I../../include -Wall -O3 -m64 -mcpu=ultrasparc -mv8plus -mvis -g -fomit-frame-pointer -pipe -fPIC -m64 -D_REENTRANT -DUSE_XSHM -DUSE_SPARC_ASM -std=c99 -ffast-math -I/usr/openwin/include arbfplight.c readtex.o -L../../lib -lX11 -lglut -lGLU -lGL -lm -o arbfplight Undefined first referenced symbol in file glGetQueryObjecti64vEXT ../../lib/libGL.so glBlitFramebufferEXT../../lib/libGL.so glGetQueryObjectui64vEXT../../lib/libGL.so ld: fatal: Symbol referencing errors. No output written to arbfplight collect2: ld returned 1 exit status make[2]: *** [arbfplight] Error 1 make[2]: Leaving directory `/mnt/home/egger/src/Mesa/cvs/Mesa/progs/demos' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/mnt/home/egger/src/Mesa/cvs/Mesa/progs' make: *** [default] Error 1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
