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

Re: [Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

I've been dabbling with multiple GL contexts on different threads
recently in desktop GL code, and multiple people who I see as quite
the GL experts and who've been through this before gave me the good
advice that 'it's not worth it', and that the whole topic is 'a world
of pain' mainly because the whole area not well specified, lousily
documented, drivers behave differently, and if they work, they still
suffer from thread synchronization issues. I guess that WebGL could
still mimic different contexts in worker threads and allow to call
WebGL functions from workers, as long as the calls can be queued
efficiently to the 'main GL context' under the hood. IMHO the most
interesting topic for parallelization, and which could also be
achieved in WebGL and WebGL2 is resource setup, not trying to
parallelize all types of WebGL calls.


On Wed, Mar 4, 2015 at 7:22 PM, Florian Bösch <pyalot@gmail.com> wrote:
> Hm, I see. Though the blocking behavior might differ from when the browser
> transfers data between JS-thread and GPU-process, than when the GPU-process
> exchanges with the GPU. Also it's not outside the realm of possibilities
> that at some point WebGL contexts might stand in for real contexts, and
> WebGL code runs in a dedicated WebWorker process that owns that context.
> On Wed, Mar 4, 2015 at 7:15 PM, Zhenyao Mo <zmo@chromium.org> wrote:
>> On Wed, Mar 4, 2015 at 10:10 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> > On Wed, Mar 4, 2015 at 7:07 PM, Zhenyao Mo <zmo@chromium.org> wrote:
>> >>
>> >> Basically we can't just return the pointer from glMapBufferRange to
>> >> the javascript in read-only or write-only modes, because there is no
>> >> mechanism to enforce read-only or write-only.
>> >
>> > So what you're saying is there isn't a ReadOnlyArrayBuffer and
>> > WriteOnlyArrayBuffer correct? If I'm not mistaken, returning ArrayBuffer
>> > conformant objects, which impose additional restrictions shouldn't be
>> > terribly hard.
>> You also need to consider some browsers (for example, Chrome) runs GPU
>> in a separate process.  Copying data out and copying data back is the
>> only way to implement this.

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