[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] GLSL loops and constant expressions
- To: Mark Callow <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] GLSL loops and constant expressions
- From: Steve Baker <email@example.com>
- Date: Tue, 07 Dec 2010 22:59:18 -0600
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sjbaker.org; bh=2kC2b TMyRI8nUP7LqCw0fTiT0No=; b=GnUeTDZELUWXFov3ClE0M0PXTzPjzlMBqobqE tHQG48jucy0IuLe51trd+qsXTL8KXx3nfcH9cfJBGo2edWq8nS5tqyphmC2zpNwI uUpuka1oJQcrqwbp606xE9lpQNjTWoXz2maCGhBm3Qktuvxp923/ecdTPi1Yh5uH LU97NA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=p1glKG7A0Goldjj0DEWZn1bsK2PmKSDGUm5luQ5IFrFTNGIMqJiBVJGem5R6K bFcum0nvpfDgRvAkOBh+v4kHSIy4eBOkywYb6kI4TCrwzVTO7UFpNBukIiOA6/j7 qSyc1l76F/chVhLeK5LVbwbvCpPVUESIIL1Sm0FiogvtOM=
- In-reply-to: <4CFEF49E.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <1913432303.493203.1291669487612.JavaMail.firstname.lastname@example.org> <4CFE7CBE.email@example.com> <4CFEF49E.firstname.lastname@example.org>
- Sender: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
On 12/07/2010 08:59 PM, Mark Callow wrote:
>> Not having the possibility to use "while" loops or "for" loops with
>> non-constant expressions is very, very sad.
>> As with some other things, like multiple rendering targets and depth
>> texture formats, I knew the specs say that, but I hoped in some loose
>> validation whenever the underlying GL implementation allows them.
>> Maybe these features (and others) deserve their extensions?
>> For example, the gl_FragData[i] is accepted only if i is zero, as the
>> specs say that there is only a COLOR0_ATTACHMENT. But can we actually
>> relax these limitations whenever the system is capable?
>> Sure, they won't work on all GL|ES 2.0 systems, but, as usual, a
>> developer can ask the capabilities before going on.
> The issue I see is, and this applies to the whole extension registry
> thing, is that many webgl applications will fail to run on all
> implementations. This is because not all developers will provide
> fall-backs, due to lack of knowledge, the sheer complexity of dealing
> with an increasingly large number of extensions, laziness, 'thoughts
> like "I'm just making this to amuse myself" and similar reasons.
> In the early days of WebGL this could be a death knell. I think the
> extension registry is premature. We should wait until WebGL establishes
> a reputation for 'just working' before we create opportunities for
It's a tough call. Sure, having extensions and features that aren't
always there (eg vertex textures) will result in more 'amateur' efforts
failing on more machines - but shipping without any really compelling,
professional titles because the feature set is just too limited is also
"A Bad Thing". One really good "killer app" title would serve to
convince developers that this can work - and the tidal wave that would
ensue would convince the nay-sayers. I think we're doing a reasonable
job of balancing those two extremes...but there are one or two
extensions that would REALLY help - I agree with Marco that Multiple
Render Targets would get the most bang-for-buck of any addition - and
strictly, it's not even an extension - just a glGet to tell you the max
number of render targets you're allowed to use would suffice. I'm not
sure what percentage of hardware out there can support it though.
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: