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

Re: [Public WebGL] GL_MAX_TEXTURE_SIZE power of two ?

I object to this change because it violates longstanding assumptions
in the OpenGL API.

I would support a change which mandated that MAX_TEXTURE_SIZE be a
power of two. As a matter of fact, Olli Etuaho has already contributed
a change to the top of tree conformance suite asserting this:
https://github.com/KhronosGroup/WebGL/pull/324 .


On Thu, Jul 18, 2013 at 6:36 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
> 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.
> -Jeff
> ----- 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.
> 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.