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

Re: [Public WebGL] Sharing Resources across contexts



I'm in favor of option 4 as well.

As for the "can we do it later" option, I guess that the maps team has already expressed that reading from multiple contexts is a much desired feature. I'm not sure what their exact use case is, but it sounded like they at least had a real world scenario in mind.

On Friday, March 1, 2013, Kenneth Russell wrote:

Option 4 sounds like the best of the alternatives.

If the use case is to render to a big texture from one thread and
sample that texture from multiple workers, would it be too large a
restriction to say that for now, the behavior is that of option 1, and
then when ES 3.0 functionality is added, it will evolve to that of
option 4? Or is it necessary to render to a large texture from the
main thread and actually attach it to multiple framebuffers in
multiple workers?

The reason I ask is that it is always difficult to carve off a small
piece of functionality from a later version of OpenGL. There may be
unintended consequences of introducing the DRAW_FRAMEBUFFER and
READ_FRAMEBUFFER concepts in restricted form.

-Ken



On Mon, Feb 25, 2013 at 11:41 AM, Gregg Tavares <gman@google.com> wrote:
> So I ran into my first issue prototyping this. Ideally
> checkFramebufferStatus will return FRAMEBUFFER_INCOMPLETE_ATTACHMENT if an
> attachment is not acquired but... if you're only going to read from a
> framebuffer (calling readPixels) you should only need READ_ONLY permission
> where as if you are going to draw to the framebuffer
> (clear/drawArrays/drawElements) you need EXCLUSIVE permission. Since
> checkFramebufferStatus doesn't know your intent it can't give you the
> correct answer.
>
> Several solutions came up so far.
>
> 1) Require EXCLUSIVE permission for framebuffer attachments
>
> That's not really a solution since one of the required use cases is multiple
> workers reading from the same texture.
>
>
> 2) checkFramebufferStatus assumes READ_ONLY permission only
>
> That means you might still get a INVALID_FRAMEBUFFER_OPERATION if you
> acquired attachments for READ_ONLY access and then try to draw.
>
>
> 3) expose the DRAW_FRAMEBUFFER and READ_FRAMEBUFFER bind targets
>
> On systems that support multi-sampling there are 2 framebuffer bind targets.
> DRAW_FRAMEBUFFER and READ_FRAMEBUFFER. DRAW is where drawing happens. READ
> is where reading happens.  Unfortunately since multi-sampling isn't
> supported everywhere allowing you to bind separate framebuffers to
> DRAW_FRAMEBUFFER and READ_FRAMEBUFFER won't work.
>
>
> 4) allow DRAW_FRAMEBUFFER and READ_FRAMEBUFFER as arguments to
> checkFramebufferStatus
>
> In this case you'd still only be able to bind to gl.FRAMEBUFFER but you can
> call checkFramebufferStatus with either DRAW_FRAMEBUFFER or READ_FRAMEBUFFER
> or FRAMEBUFFER. The OpenGL spec defines FRAMEBUFFER as meaning both
> READ_FRAMEBUFFER and DRAW_FRAMEBUFFER so this proposal would just work and
> be future compatible.
>
> In other words.
>
>    gl.checkFramebufferStatus(gl.FRAMEBUFFER)  // checks for EXCLUSIVE access
>    gl.checkFramebufferStatus(gl.DRAW_FRAMEBUFFER)  // checks for EXCLUSIVE
> access
>    gl.checkFramebufferStatus(gl.READ_FRAMEBUFFER)  // checks for READ_ONLY
> access
>
>
> #4 seems like the best/correct choice but I thought see if there were other
> ideas.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Feb 12, 2013 at 8:38 AM, Brandon Jones <bajones@google.com> wrote:
>>
>> On Tuesday, February 12, 2013, Kirill Prazdnikov wrote:
>>>
>>>
>>> Hi Gregg,
>>>
>>>> void cancelAcquireSharedResource(long id);
>>>
>>>
>>> The purpose of cancelAcquireSharedResource is not clear from the
>>> document.
>>
>>
>> acquireSharedResource is an asynchronous operation.
>> cancleAcquireSharedResource would indicate that a previous acquire call,
>> presumably one that has not yet completed, is no longer desired. It should
>> function like clearTimeout for a setTimeout call.
>>
>> One thing that's not explicitly mentioned in the wiki is the behavior of
>> cancelAcquireSharedResource if the acquisition has already succeeded. I
>> would imagine it's a no-op at that point?
>>
>>>
>>>
>>> Why simply not to use COM like ref counting ?
>>>   acquireSharedResource = addRef
>>>   releaseSharedResources = release ?
>>>
>>> Thanks
>>
>>
>> The effect of these functions is different than addRef/release. Acquiring
>> a WebGL resource would allow the acquiring context access to the resource,
>> and may prevent other contexts from accessing it if it was acquired with
>> gl.EXCLUSIVE. If acquired exclusively, other contexts would not be able to
>> acquire or access the resources until it had been released. This is to
>> maintain safety across threads and to explicitly manage the requirements of