| Summary: |
_glapi_add_entrypoint does not generate offset for drivers |
| Product: |
DRI
|
Reporter: |
Ian Romanick <idr> |
| Component: |
libGL | Assignee: |
Default DRI bug account <dri-devel> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
|
| Severity: |
normal
|
|
|
| Priority: |
high
|
|
|
| Version: |
DRI git | |
|
| Hardware: |
x86 (IA32) | |
|
| OS: |
Linux (All) | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
| Bug Depends on: |
3377
|
|
|
| Bug Blocks: |
1690
|
|
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
_glapi_add_entrypoint accepts an offset of ~0 for two reaons. The primary reason is so that glXGetProcAddress can always return a non-NULL value. If an unknown function is requested, a dummy stub will be generated and returned to the application. The intention being that a loaded driver will later fill-in the offset to complete the function. The other reason is so that drivers can extend the GL API with functions that do not have statically assigned offsets. For example, an IHV could add a new, perhaps experimental, extension. It would register its functions by calling '_glapi_add_entrypoint("glNewFunctionIHV", ~0)' and get the actual offset by calling '_glapi_get_proc_offset("glNewFunctionIHV")'. This second usage requires that libGL assign an offset. Currently, there is NO code to do this. If a loaded driver calls _glapi_add_entrypoint with an offset of ~0, the offset will remain ~0!