> At the bottom is another block with GLES 3.1 requirements, which also > contains GL_ARB_f_n_a.
At first, I said "Oh futz, I did not mark that one". Then I did some thinking. Before expressing my thoughts I want to emphasize that I really do not know what is the best answer, or potentially even a good one. With the caveat in mind, maybe it is best that it is not marked as ready for GL ES. Maybe. The potentially flawed reasoning is as follows: The patch series enables the extension for OpenGL and the extension stuff, I think, only applies to GL, and not GL ES, contexts. In particular, the "wiring" for the new functions is not implemented for GL ES. Secondly, the code in Mesa core from patch 3 of this series just checks for the driver reporting it supports the extension; it does not do the check "if driver supports extension AND it is GL". However, the default geometry values are zero, so the correct error code gets emitted anyways, but the text-error is not correct. This part makes me twitch, though it follows the letter of the specs jut tine. Lastly, and this is just paranoia and quite likely not an issue. I had not checked, much less quote, the relevant sections of the GL ES 3.1 spec. I think they are the same, but I did not check it at all. As one can see from the above, when implementing this, GLES did not even cross my mind. My tendency is to mark the "enabling" of this feature for ES3.1 a separate patch, but on the other hand it is not code, it is just saying the feature is ready for eventual use by ES3.1. Now in mid e-mail, I am thinking it should be marked. Beats me what is best. In truth what is making me twitch is Patch 3 under GL ES 3.1. I think that the function might need to be revisited a little when GL ES 3.1 support goes live. Thoughts on this are welcome, particular in reference to Patch 3 of the series. -Kevin
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
