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

RE: [Public WebGL] GL_MAX_TEXTURE_SIZE power of two ?



I agree that with a very careful reading, the spec does seem to imply that MAX_TEXTURE_SIZE is a power of two, even if you throw away some reasonable but unwritten assumptions. "level zero through k" doesn't really make sense unless k is an integer. And in practice MAX_TEXTURE_SIZE is a power of two unless there's a bug somewhere. However, I'd add checking this to the conformance test to clarify this interpretation, the very existence of this discussion shows that this is not immediately clear from the spec. Here's a patch: https://github.com/KhronosGroup/WebGL/pull/324

Regards, Olli
________________________________________
From: owner-public_webgl@khronos.org [owner-public_webgl@khronos.org] On Behalf Of Mark Callow [callow.mark@artspark.co.jp]
Sent: Tuesday, July 16, 2013 10:05 AM
To: Jeff Gilbert
Cc: Kenneth Russell; Guillaume Abadie; Brandon Jones; public webgl
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 others.

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.


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