Hi mesa-dev, The Intel team has been discussing how fix population of the GLES3 dispatch table. The fix may require a modification of the data flow during context creation for all drivers. I just wanted to post the discussion here for public record.
On 11/13/2012 12:21 PM, Kenneth Graunke wrote: > On 11/13/2012 11:55 AM, Chad Versace wrote: >> CC'ing mesa-dev, with some private bits removed. >> >> On 11/13/2012 09:57 AM, Paul Berry wrote: >>> On 13 November 2012 09:16, Jordan Justen <jljus...@gmail.com >>> <mailto:jljus...@gmail.com>> wrote: >>> >>> On Mon, Nov 12, 2012 at 10:18 PM, Paul Berry <stereotype...@gmail.com >>> <mailto:stereotype...@gmail.com>> wrote: >>> > Ideally I'd like to change the initialization order so that >>> > _mesa_create_exec_table happens after _mesa_compute_version. Ian and >>> I have >>> > been planning to make this change in the long run for other reasons >>> (so that >>> > _mesa_create_exec_table can avoid populating dispatch table entries >>> for >>> > unsupported extensions). What I don't know is whether other yaks >>> have >>> to be >>> > shaved before we can make that change. >>> >>> I'm not sure, but I think we currently have: >>> 1. Create the core dispatch tables >>> 2. Return back to mesa driver >>> 3. Return to app code and wait for context to be made current >>> 4. Compute version >>> >>> It seems like a lot could be happening between #1 and #4 that would >>> make it challenging to move #1 after #4. >>> >>> >>> Wow, I had no idea. I don't think it's necessary to postpone computing the >>> version until this late--it should be possible to do during context >>> creation. >>> In fact, several of the other drivers do exactly that: Nouveau, r200, and >>> radeon >>> all call _mesa_compute_version unconditionally from their context creation >>> functionsm and the gallium state tracker calls _mesa_compute_version from >>> its >>> context creation function when the client requests an API version > 1.0. I >>> think that means that the only other driver that does stuff in the same >>> order we >>> do is swrast. >>> >>> I propose that we switch to what the other drivers do--just call >>> _mesa_compute_version unconditionally in intelInitContext. As long as we >>> do it >>> after the call to intelInitExtensions we should be fine. >>> >>> As a follow up task, we should see if it's feasible to modify swrast to do >>> the >>> same, and modify gallium so that it calls _mesa_compute_version >>> unconditionally. If that works, then we can drop the call to >>> _mesa_compute_version from _mesa_make_current, since all drivers will have >>> already called _mesa_compute_version by the time their context is made >>> current >>> for the first time. >> >> I agree. The Intel drivers and swrast should call _mesa_compute_version >> during >> context creation, just like the gallium drivers. Then the call to >> _mesa_compute_version should be removed from *MakeCurrent. >> >> Not only does _mesa_compute_version need to be called during context >> creation, >> but it must be called from within or before _mesa_initialize_context, because >> that function initializes the dispatch tables. Therefore, I'd like to go one >> step further: the responsibility of calling _mesa_compute_version >> should be moved outside the drivers and into _mesa_initialize_context. Doing >> so >> would require some modifications to the context creation data flow, but >> Jordan >> and my investigations determined that it wouldn't be too difficult. > > Seems like a fine plan. > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
