[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] GL_MAX_TEXTURE_SIZE power of two ?



On 2013/07/17 6:39, Jeff Gilbert wrote:
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.
ES 2.0 spec. p 68 (78):  "The level argument to TexImage2D is an integer level-of-detail number."

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 MAX_TEXTURE_SIZE."

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 driver.

Regards

    -Mark

--
注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

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.