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

Re: [Public WebGL] GL_MAX_TEXTURE_SIZE power of two ?

Ok, I propose the following addition:

6.25 Non-power-of-two MAX_TEXTURE_SIZE
MAX_TEXTURE_SIZE is explicitly allowed to be a non-power-of-two value.

I still believe there to be wiggle-room in the spec in this regard. I see no reason that we can't define limits for our integer levels based on a continuous equation.
Regardless, I believe this is easy to resolve: We just explicitly specify one way or the other.


----- Original Message -----
From: "Mark Callow" <callow.mark@artspark.co.jp>
To: "Jeff Gilbert" <jgilbert@mozilla.com>
Cc: "Kenneth Russell" <kbr@google.com>, "Guillaume Abadie" <guillaume.abadie@gmail.com>, "Brandon Jones" <bajones@google.com>, "public webgl" <public_webgl@khronos.org>
Sent: Tuesday, July 16, 2013 11:46:26 PM
Subject: 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.



が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情
たら削除を行い配信者にご連絡をお願いいたし ます.

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.

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl