On Mon, Apr 11, 2016 at 12:06 PM, Jason Ekstrand <[email protected]> wrote: > Another pretty easy task is to find GL ES extensions where the desktop > variant is already implemented. Then 95% of the code is there, you just > have to see what (if anything) is different with the ES variant and wire it > up. If you're going to do that, might be good to coordinate with Ilia. > He's been knocking them out like crazy lately.
That streak is mostly over... I did the easy ones :) The only other "easy" one left is GL_OES_texture_view (and its EXT companion), but there are no dEQP tests for it. If one were to not be lazy, then one would modify the existing piglit tests to work with GL ES as well, and test the impl that way. The rest of the stuff required for AEP and GLES 3.2 is trickier - geometry/tess depend on GL_OES_shader_io_blocks, which in turn depends on making the input/output interface validation logic work for SSO programs. [Right now it just crashes on gallium since we release the IR, but even if we don't, it's till piles-o-fail.] I've been giving advanced blend some thought, but it's not trivially simple, and then there's the primitive bounding box thing which depends on tess, and cube arrays which depend on gs. And that's it. Maybe fixing GL_EXT/OES_shader_io_blocks *would* be a good newbie project, esp for someone already familiar with GL. There are dEQP tests for it, which is nice, and this is a start on the mesa bits: https://github.com/imirkin/mesa/commit/9b0ea7da1bf0850dbb4bfdfe36bb9b1c354690ae If you do go for it, make sure to consult with people about how to solve the issues once you identify them, since everyone will have (opposing) opinions on it. [Esp the whole reliance on the ir being around after linking -- that needs to go.] -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
