Register EXT_depth_clamp for GLES #240
Conversation
gerddie
force-pushed
the
master
branch
2 times, most recently
from
46bbf68 to
c8732c0
Compare
|
Thanks for the review, I've force pushed a new version, but I didn't update the history, because I'm not sure whether this would be needed at this point. I hope that my changes are what you would expect, and I'm thankful for additional pointers if needed. |
ARB_depth_clamp does for OpenGL. v2: Add GL_DEPTH_CLAMP_EXT for this extension (thanks @kusma) v3: - correct use of DEPTH_CLAMP to DEPTH_CLAMP_EXT - point o the issues in ARB_depth_clamp and only retain (and update) the wording for primitive with w_c <= 0 and point out differences to ARB_depth_clamp otherwise. (all thanks @dgkoch) v4: - remove header changes from commit (@oddhack) Signed-off-by: Gert Wollny <[email protected]>
|
@oddhack done, the feedback should also be resolved, I'm not sure why github is still putting that marker there, the attribute column that the first comment mentions has been removed. |
|
Adding @pdaniell-nv to add to the ES WG agenda to see if there is any other feedback/interest from other ES vendors. @gerddie do you have any tests planned for this? |
|
@dgkoch I'm not sure what tests you mean, but we want to implement this in mesa to be able to run OpenGL in a virtualised environment on top on a host that supports only GLES via virglrenderer. There we have piglit tests that test ARB_depth_clamp in the virtualized guest and that will rely on the host exposed EXT_depth_clamp. If this is of interest we can also see how to add tests to the OpenGL ES CTS. |
|
@gerddie I was thinking of the OpenGL ES CTS. |
This extension provides the same interaction for OpenGL ES that ARB_depth_clamp does for OpenGL.
I went for an EXT extension because it is based on this already available ARB extension, and for that reason it makes sense to me to get it fully approved, but I could also put it in the MESA namespace (since there I will implement it). Many thanks for any comments.