ES 2.0 spec. p 68 (78): "The level argument to TexImage2D is an integer level-of-detail number."I posit that it doesn't technically require any changes, and if any vendor had shipped NPOT MAX_TEXTURE_SIZE in the past, we would be dismissing the idea of a POT limit out of hand. If we treat the equations in question as continuous, I don't believe any further changes are required to support NPOT MAX_TEXTURE_SIZE. MAX_TEXTURE_SIZE is fairly poorly defined, likely deliberately. If you can find any other places in the spec that would need changing to support NPOT MAX_TEXTURE_SIZE, I would be interested in seeing them. Otherwise, I think we should be more willing to actually *spec* assumptions, or admit that our assumptions were not backed by the spec, and revise them. If anything requires a 'sufficiently close reading of the spec', which we can't even agree on, it would seem obvious that we should clarify it! We should really not be checking the conformance suite when we have a question about the spec. Spec questions should largely ignore the existence of the tests, since the tests are supposed to be strictly following the spec. Changes to the spec should not be dismissed because they'd require test changes. Changes to other spec-compliant implementations should not be suggested in lieu of spec clarification and/or conformance test changes. 'This is an old assumption, so you should assume it too' is not a healthy thing to put weight on, (glFlush vs. glFinish? TexImage2D origin? 'OpenGL is right-handed'?) and in this case is only an assumption because most of the instances we've seen so far follow this pattern. I will reiterate that it would likely be in our best interest to allow NPOT MAX_TEXTURE_SIZE, as a decent share of machines are about to be limited to 4k, when they would otherwise be able to use 8191. If a user wants to ask if they can store a 3*1080p panarama-like texture, they will think they can't do it on these machines if we drop them all the way back to 4k. In the absence of spec changes, we will continue to try to let users get the most out of their hardware.
This is the first mention of level-of-detail in the
specification. A few lines later on on p 69 (79) is
"The maximum allowable width and height of a two-dimensional
texture image must be at least 2**(k-lod) for image arrays of
level zero through k, where k is the log base 2 of
I don't think it could be much clearer that levels-of-detail are
integers, therefore k is an integer, therefore MAX_TEXTURE_SIZE
will be a power of 2.
I will refrain from wading into the other "assumptions" you raise
as they are not relevant here. They are also not assumptions.
If you want to propose changing the specification please propose
suitable language changes. You cannot simply treat the equation as
continuous. To use a mipmap, the texture must be POT (in
unextended OpenGL ES/WebGL), therefore the equation specifying the
maximum size of the levels cannot be continuous.
If a "decent share of machines" is limited to 4k textures,
perhaps that will put pressure on the vendor to fix its buggy
NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.