Bug 3380 - Dynamically generate GL dispatch functions for PowerPC
Dynamically generate GL dispatch functions for PowerPC
Status: NEW
Product: Mesa
Classification: Unclassified
Component: GLX
5.0.2
Other Linux (All)
: high enhancement
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-23 13:57 UTC by Ian Romanick
Modified: 2013-03-15 14:21 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
early version of the generating script (8.24 KB, application/x-python)
2005-12-05 17:29 UTC, Zack Rusin
Details
script generating dispatch code for ppc32 (7.62 KB, application/x-python)
2005-12-07 15:55 UTC, Zack Rusin
Details
Mesa patch to use generated PPC assembly (2.67 KB, patch)
2005-12-08 03:34 UTC, Michel Dänzer
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Romanick 2005-05-23 13:57:43 UTC
Dynamic generation of GL dispatch functions is currently only supported on x86
and SPARC.  PowerPC and PPC64 should also be supported.
Comment 1 Zack Rusin 2005-12-05 17:29:35 UTC
Created attachment 3995 [details]
early version of the generating script

I had a minute right now so i did the generating script. I'll try to integrate
it, add ppc64 support and in general just clean it up some time this week when
I'll have a little bit more time. I'm attaching in case someone has more spare
time than I do. Ah, and the offset computation in BRANCH_OFFSET is more
pseudo-code than assembly right now ;)
Comment 2 Zack Rusin 2005-12-07 15:55:26 UTC
Created attachment 4014 [details]
script generating dispatch code for ppc32 

k, as far as ppc32 generation, this should be it.
Comment 3 Michel Dänzer 2005-12-07 20:08:16 UTC
I managed to build libGL with this, but when running glxinfo, it dies with
SIGILL in glGetString (the first gl[^X] function called).
Comment 4 Michel Dänzer 2005-12-08 03:34:03 UTC
Created attachment 4026 [details] [review]
Mesa patch to use generated PPC assembly

Testing instructions:

* Save the current version of the generator script as
Mesa/src/mesa/glapi/gl_ppc_asm.py
* Apply the Mesa patch
* make -C Mesa/src/mesa/glapi
* Rebuild libGL (you may have to manually remove at least
Mesa/src/mesa/main/dispatch.o) and watch glxinfo die with SIGILL ;)
Comment 5 Benjamin Herrenschmidt 2006-03-01 17:05:40 UTC
Ok, I suppose I can fix that :) But first I need to understand how the whole 
thing is supposed to work... It's not very clear between python stuff 
generating asm stubs, magic macros, etc etc... (btw. I think there are bugs 
there but I'll have to dbl check when I understand what the stuff is actually 
supposed to do in the first place). 
 
Can somebody explain me how it works without the asm stuff (the pure C stuff) 
and what the "optimized" version is supposed to do ? I have enabled 
-DGLX_USE_TLS and the resulting stubs look not too bad, but I could probably 
make them a bit better with asm (like doing a proper tail call). 
 
However, I suppose that if I could acutally generate code at runtime, I could 
do even better and generating a branch island that loads the absolute address 
of the target and branch to it (basically about 4 or 5 insns in 32 bits, maybe 
a bit more in 64 bits). But first I need to get a bit more familiar with how 
this all fits together in the mesa source, so far I'm just confused :) 
 
Comment 6 Marcin Kurek 2006-10-06 05:32:00 UTC
Added myself to cc as this one looks promising.
Comment 7 Benjamin Herrenschmidt 2006-10-06 14:45:56 UTC
Sorry, I didn't go back on that yet... I read the code for about 2 hours and
just got more confused about what is it supposed to do. Some comments would have
been useful. I might get back to it at one point, I'm a bit too busy at the moment
Comment 8 chemtech 2013-03-15 14:21:56 UTC
Ian Romanick 
Do you still experience this issue with newer soft ?
Please check the status of your issue.