On 05/18/2015 06:36 PM, Dave Airlie wrote: > On 19 May 2015 at 11:02, Ian Romanick <i...@freedesktop.org> wrote: >> On 05/18/2015 05:35 PM, Ian Romanick wrote: >>> On 05/18/2015 02:34 PM, Dave Airlie wrote: >>>> On 19 May 2015 at 07:28, Ian Romanick <i...@freedesktop.org> wrote: >>>>> With the patches already on the piglit list, the only change is >>>>> gettextureimage-formats, gettextureimage-formats init-by-rendering, and >>>>> gettextureimage-luminance change from pass to skip. >>>> >>>> This might be a naive question, with dummy false core only, >>>> >>>> how do we ensure these APIs are never called in non-core scenarios? >>>> >>>> does the dispatch layer handle that for us? >>> >>> Yes, but I need to add another patch to make that happen. Thanks for >>> reminding me. :) That will end up being patch 14.5 / 15. >> >> Ugh. It turns out that Ilia is correct. We can control just about >> everything else, but we can't make functions core profile-only. And >> this is already a bug for functions added by: >> >> ARB_draw_indirect >> ARB_multi_draw_indirect >> ARB_gpu_shader_fp64 >> ARB_texture_buffer_object >> ARB_texture_buffer_range >> ARB_vertex_attrib_64bit >> ARB_viewport_array >> >> These extensions are all marked "GLC" in extensions.c. The functions >> check the extension bits, but they don't check the API... and drivers >> set the bit without regard for the API. >> >> GOOD TIMES WERE HAD BY ALL. > > I got bad feelings when I was doing ARB_shader_subroutine, and removing > all the if enabled bits if it was going to be core only, glad I held off!
The enable bits don't help. If you make a compatibility-profile context, right now GL_ARB_draw_indirect is not in the extensions string. However, if you call glDrawIndirect, something (other than just setting GL_INVALID_OPERATION) will happen. _mesa_DrawIndirect will check the extension bit, see that the driver set it, and merrily go about its business. Either way, I think I've figured out how I want this implemented, and I should have patches out in a few hours. > Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
