summaryrefslogtreecommitdiff
path: root/src/mesa/glapi/gl_SPARC_asm.py
AgeCommit message (Collapse)Author
2009-02-26mesa: Resurrect SPARC asm code.David S. Miller
This rewrites the sparc GLAPI code so that it's PIC friendly and works with all of the TLS/PTHREADS/64-bit/32-bit combinations properly. As a result we can turn SPARC asm back on. Currently it's only enabled on Linux, as that's the only place where I can test this stuff out. For the moment the cliptest SPARC asm routines are disabled as they are non-working. The problem is that they use register %g7 as a temporary which is where the threading libraries store the thread pointer on SPARC. I will fix that code up in a future change as it's a pretty important routine to optimize. Like x86 we do the runtime patch as a pthread once-invoked initializer in init_glapi_relocs(). Unlike x86, however, our GLAPI stubs on SPARC are just two instruction sequences that branch to a trampoline and put the GLAPI offset into a register. The trampoline is what we run-time patch. The stubs thus all look like: glFoo: ba __glapi_sparc_foo_stub sethi GLAPI_OFFSET(glFOO) * PTR_SIZE, %g3 This actually makes generate_entrypoint() a lot simpler on SPARC. For this case in generate_entrypoint() we generate stubs using a 'call' instead of the 'ba' above to make sure it can reach. In order to get a proper tail call going here, in the unpatched case, we do several tricks. To get the current PC, for example, we save the return address register into a temporary, do a call, save the return address register written by the call to another temporary, then restore the original return address register value. This is to avoid having to allocate a stack frame. This is necessary for PIC address formation. This new GLAPI scheme lets us get rid of the ugly SPARC GLAPI hacks in __glXInitialize() and one_time_init(). Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-11Fix bug #4681.Ian Romanick
glDeleteTextures and glDeleteTexturesEXT were erroneously listed as aliases of each other. For anything /except/ GLX protocol they are aliases. This set of changes allows functions that are functionally identical but have different GLX protocol to be listed as aliases. When building with GLX_INDIRECT_RENDERING set, different static functions are used. These functions determine whether the current context is direct rendering or not. If the context is direct rendering, the aliased function (e.g., glDeleteTextures in the case of glDeleteTexturesEXT) is called. If the context is not direct rendering, the correct GLX protocol is sent. For a deeper explanation of what is changed, please see: http://dri.freedesktop.org/wiki/PartiallyAliasedFunctions
2006-08-26Explicitly store the names for each function that should have a staticIan Romanick
entry point generated. This allows us to do things like generate a static entry point for glPointParameterfvARB but not for glPointParameterfvSGIS.
2006-08-22Add new attribute called static_dispatch to the <function> element. ThisIan Romanick
boolean attribute, which defaults to true, determines whether or not a static dispatch function is available in libGL for applications to link against. Ideally, any new functions that are not part of the ABI should not have directly accessable dispatch functions. This forces applications to use glXGetProcAddress to access these functions. By doing this we can gracefully remove functions from libGL without breaking the linkage of applications. Note that the static dispatch functions are still generated. However, they are given names like gl_dispatch_stub_820 and are marked with the "hidden" linker attribute. All extension functions added since the previous Mesa release (6.5) have been marked as 'static_dispatch="false"'.
2005-07-28Fix SPARC assembly for 64-bitIan Romanick
- The test for whether or not we're building for 64-bit is '#ifdef __arch64__'. This appears to be correct on both Linux and Solaris. - The test for Solaris is now '#if defined(SVR4) || defined(__SVR4) || defined(__svr4__)'. GCC 3.4.0 has all three defined on Solaris 9. - Enables assembly language clip routines. - Fixes to make GLSL code build on Solaris. - Update gl_SPARC_asm.py.
2005-06-21Mammoth update to the Python code generator scripts that live inIan Romanick
src/mesa/glapi. Basically, the scripts that did simple things (like gl_offsets.py) were simple, and the scripts that did more complicated things (like glX_proto_send.py) were getting progressively more and more out of control. So, I re-write the foundation classes on which everything is based. One problem with the existing code is that the division between the GL API database representation and the way the output code is generated was either blury or nonexistant. The new code somewhat follows the Model-View-Controller pattern, minus the Controller. There is a distinct set of classes that model the API data, and there is a distinct set of classes that generate code from that data. One big change is in the class that represents GL functions (was glFunction, is now gl_function). There used to be an instance of this calls for each function and for each alias to that function. For example, there was an instance for PointParameterivSGIS, PointParameterivEXT, PointParameterivARB, and PointParameteriv. In the new code, there is one instance. Each instance has a list of entrypoint names for the function. In the next revision, this will allow a couple useful things. The script will be able to verify that the parameters, return type, and GLX protocol for a function and all it's aliases match. It will also allow aliases to be represented in the XML more compactly. Instead of repeating all the information, an alias can be listed as: <function name="PointParameterivARB" alias="PointParameterivEXT"/> Because the data representation was changed, the order that the alias functions are processed by the scripts also changed. This accounts for at least 2,700 of the ~3,600 lines of diffs in the generated code. Most of the remaining ~900 lines of diffs are the result of bugs *fixed* by the new scripts. The old scripts also generated code with some bugs in it. These bugs were discovered while the new code was being written. These changes were discussed on the mesa3d-dev mailing list back at the end of May: http://marc.theaimsgroup.com/?t=111714569000004&r=1&w=2 Xorg bug: 3197, 3208
2005-04-18Refactor a bunch of common code from the "leaf" scripts to a new functions,Ian Romanick
parse_GL_API, in gl_XML.py.
2005-04-18Convert all Python scripts to use XML namespaces.Ian Romanick
2004-11-22applied SPARC patch (freedesktop bug 1898)Brian Paul
2004-05-25Modify the generate assembly code to not use global registers %g2,Ian Romanick
%g3, %g6, or %g7. This should eliminate the warnings about global registers used without a ".register" directive.
2004-05-24Fixed a bug that caused every dispatch function to call glNewList.Ian Romanick
2004-05-24Generates assembly dispatch stubs for SPARC. Generates different outputIan Romanick
than glsparcasm.py, but the assembled code should be the same. The seems to only work with GCC version >= 3.0. The older preprocessor doesn't like the embedded # in the GLOBL_FN macro. On the SPARC system I used, /ccs/bin/as didn't like the @function, it would only accept #function.