Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here is my first pass at run-time dispatch generation code for x86-64. > It's not particularly well tested yet (or I'd just commit it now). I > wrote a test program that called fill_in_entrypoint with a few different > parameter signature strings, and I verified that the generated code > looked correct. > > After some discussion on IRC, I've been thinking about how we might make > run-time dispatch generation work on "hardend" systems. Those systems > don't allow a memory region to be both writable and executable. We can > use mprotect to adjust the protections. There are a couple sublte > problems that need to be overcome to make this really work: > > 1. mprotect works at page granularity. > > 2. Once a page is marked (PROT_READ|PROT_EXEC) we can *never* make it > PROT_WRITE again. Multithreaded applications are the problem here. > Imagine one thread jumping to a dispatch function right when another > thread makes the page containing that dispatch function PROT_WRITE. > > 3. Since glXGetProcAddress returns a pointer to the dispatch stub, > memory must be allocated at that time. > > 4. On x86-64 and PowerPC, the dispatch functions cannot be fully created > until the driver asks for them to be created. x86 has the same problem > currently, but that will be changed soon. > > Normally when an application calls glXGetProcAddress a dummy stub is > created. In the current implementation, a dispatch offset is not > assigned at this time. The existing code expects that the driver will > later ask for the function to be added and will provide a dispatch > offset. This is actually a bug, and it prevents drivers that support, > for example, APPLE_vertex_array_object from working with versions of > libGL that don't. Once I commit a fix for that, libGL could assign a > dispatch offset when glXGetProcAddress is called. > > This would allow libGL to create a fully functional dispatch stub on > x86. In fact, libGL could create an entire page of dispatch stubs the > first time glXGetProcAddress is called. This can be done on x86 because > the dispatch function is independent of the parameter signature of the > function being dispatched. > > x86-64 and PowerPC do not share this feature. Since these platforms > pass all parameters in registers, the dispatch function for glBegin is > different from the dispatch function for glTexImage2D. When > glXGetProcAddress is called it is impossible to know what the parameter > signature, and thus the contents of the dispatch stub, should be. This > prevents those platforms from being able to create a page of dispatch > stubs at a time.
How many distinct functions do you expect to generate? You could generate a page worth of each particular function as requested, or you could generate pages with a mix of all the different types of functions if you know the total number to be small... > I guess we could do a single dispatch function per page, but since the > dispatch functions are on the order of 128 bytes, that seems awfully > wasteful. Agreed. 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=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
