Repository navigation
Should uninitialized depth resources default to 1.0 or 0.0? #312
Description
1.0 is the typical "far" value, and this is the value chosen by WebGL as well.
But for inverted-z, it would be 0.0. Fortunately, whatever we choose here shouldn't hurt performance for one or the other case, since if the app explicitly clears then it we won't have to do the implicit clear.
As an aside (cc #268 #276), whatever default is chosen here, it may make sense to use it for the clear value default.
Of course, this becomes irrelevant if we end up disallowing the use of uninitialized resources in validation, which IIRC was still on the table.
Activity
kvark commentedon May 31, 2019
I don't quite like the idea of having default initialization sensitive to the semantics of the resource in question. Ideally, it wouldn't care about what 3D depth strategies the users aim to apply. Not clearing the depth to 1 before doing a forward-Z path is not a fault we need to cover up implicitly.
I take it as a point supporting the choice of forced validation as opposed to silent initialization.
kainino0x commentedon May 31, 2019
Agreed.
Kangz commentedon Jun 3, 2019
Note that this initial value is also irrelevant if implementations use lazy-zero initialization and the application correctly use loadOp clear to 1.0 in their render pass.
kvark commentedon Jun 3, 2019
@Kangz this sounds like "if they do it right, they don't have a problem", which goes back to our discussion about the implicit initialization, and eventually to Hyrum's Law:
If we define what the default is, people will use it and rely on it. The only way to force people to write "correct" code (that uses
LoadOp) is to forbid uninitialized states.Kangz commentedon Jun 3, 2019
If they don't get it right they get 0.0, and it's probably fine for applications to rely on getting resources initialized to zero.
kainino0x commentedon Jun 11, 2019
I think we agreed in the last meeting it makes sense to use 0.0 here, so everything is uniformly zero-initialized. (Plus, in a future with resource aliasing, this is the only reasonable solution).
(Disallowing uninitialized use is still on the table.)