I think TBDR should be disabled when gl_FragDepth is written in Fragment Shader.
TBDR cannot be disabled, as it is the architecture of the hardware (i.e. it is part of the hardware chips design, so is impossible to change).
gl_FragDepth is not supported in OGLES 2.0 (the only shader based OGLES API currently available), but if this feature was available in the API, the TBDR architecture would be capable of resolving it.
Joe wrote:
TBDR cannot be disabled, as it is the architecture of the hardware (i.e. it is part of the hardware chips design, so is impossible to change).
gl_FragDepth is not supported in OGLES 2.0 (the only shader based OGLES API currently available), but if this feature was available in the API, the TBDR architecture would be capable of resolving it.
gl_FragDepth is not supported in OGLES 2.0 (the only shader based OGLES API currently available), but if this feature was available in the API, the TBDR architecture would be capable of resolving it.
IMG announced in https://www.imgtec.com/powervr/powervr-graphics.asp that "All major APIs are supported including OpenGL ES 2.0/1.1, OpenVG 1.1, OpenGL 2.0/3.0 and DirectX9/10.1 and OpenCL.", and it is a must for OpenGL 3.0 to support GLSL1.3 which supports gl_FragDepth. So, there will be bugs if gl_FragDepth is writtent in GLSL?
yjguo wrote:
So, there will be bugs if gl_FragDepth is writtent in GLSL?
No. Where gl_FragDepth is available, writing to it works as expected.
Xmas wrote:
yjguo wrote:
So, there will be bugs if gl_FragDepth is writtent in GLSL?
No. Where gl_FragDepth is available, writing to it works as expected.
Does this mean that TBDR is dynamically disabled for the case gl_FragDepth is written, and TBDR is dynamically enabled for the case that gl_FragDepth is not written?
yjguo wrote:
Does this mean that TBDR is dynamically disabled for the case gl_FragDepth is written, and TBDR is dynamically enabled for the case that gl_FragDepth is not written?
No, rendering is always tile-based and shader evaluation is deferred as much as possible. Writing gl_FragDepth just means that the fragment shader may have to be evaluated earlier than normal.
Xmas wrote:
yjguo wrote:
Does this mean that TBDR is dynamically disabled for the case gl_FragDepth is written, and TBDR is dynamically enabled for the case that gl_FragDepth is not written?
No, rendering is always tile-based and shader evaluation is deferred as much as possible. Writing gl_FragDepth just means that the fragment shader may have to be evaluated earlier than normal.
i don't think it is possible to know the data written into gl_FragDepth at ISP stage, so i think the hidden surface remove is disabled for this case, is this right?
Output to gl_FragDepth is fed back to the ISP stage, hidden surfaces will still be removed. But of course the ISP cannot perform the depth test before the fragment depth is known.
regarding “Output to gl_FragDepth is fed back to the ISP stage”, so it is possible for one pixle to go through the Fragment Shader twice, the first time is to caculate gl_FragDepth and feed back to ISP, after ISP, it will again go through the following stages including Fragment Shader. Is this right? thanks.
The fragment won’t be processed a second time.
When it is processed (the first and only time), the colour is calculated and stored in the on-chip colour buffer. The visibility information that is known once the fragment has been processed is given back to the ISP so the on-chip depth and stencil buffers can be updated accordingly.
