[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] GL_MAX_TEXTURE_SIZE power of two ?
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.
----- Original Message -----
From: "Mark Callow" <firstname.lastname@example.org>
To: "Jeff Gilbert" <email@example.com>
Cc: "Kenneth Russell" <firstname.lastname@example.org>, "Guillaume Abadie" <email@example.com>, "Brandon Jones" <firstname.lastname@example.org>, "public webgl" <email@example.com>
Sent: Tuesday, July 16, 2013 12:05:41 AM
Subject: Re: [Public WebGL] GL_MAX_TEXTURE_SIZE power of two ?
On 2013/07/16 15:34, Jeff Gilbert wrote:
> I don't think 'k' is usually lod, and in particular 'k' is not lod in that passage, as 'lod' is lod. 'k' does generally appear as an integer in the spec, but it's usually unambiguously specified as such. As written, the passage in question works fine as a continuous formula, restricted in practice by the inability to specify fractional texture levels.
> I personally find the argument that MAX_TEXTURE_SIZE is coerced to POT by this passage weak. If we want to specify it as such, we should just do so explicitly. The spec should be clear, and it's always a little embarrassing when something as simple as this results in such subtly-positioned arguments.
The spec. says "2**(k-lod) for image arrays of level zero through k"
which means k is the maximum image level (or LoD) which is how k is used
throughout this portion of the spec. "lod" in this expression refers to
the particular image level whose size is being calculated.
> I think it is much more useful to allow NPOT MAX_TEXTURE_SIZE, since we require NPOT texture support anyways.
Huh? Only limited NPOT support is required which means no mipmaps. Any
addition of an NPOT MAX_TEXTURE_SIZE will require numerous specification
changes to permit creating mipmaps for certain texture sizes and not for
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 firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: