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

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



I don't think it's slight difference.

Even if we expose these functions, there are a lot of modifications to
the original ES3 semantics.

1) We can't expose INVALIDATE_BUFFER bit
2) We can't expose FLUSH bit with mapping implementations (we can only
allow it in copying implementations), therefore also not
glFlushMappedBufferRange() for mapping implementations.

You lose perf in copying implementation, lose functionality in mapping
implementation.  In my opinion, defining it as an extension is the
clearest way to expose the subset of them.



On Fri, Mar 6, 2015 at 1:37 PM, Florian Bösch <pyalot@gmail.com> wrote:
> I don't think the need to communicate implementation slight implementation
> differences justifies adding yet another extension.
>
> On Fri, Mar 6, 2015 at 10:35 PM, Zhenyao Mo <zmo@chromium.org> wrote:
>>
>> That seems like what developers do for an extension.  You have a shim
>> or something for code simplicity, but an understanding that without
>> the extension, it doesn't work as well as with it.
>>
>> To me, it's better being explicit about it rather than implicit. It's
>> better for WebGL as a whole, and also better for developers.
>>
>> On Fri, Mar 6, 2015 at 1:27 PM, Florian Bösch <pyalot@gmail.com> wrote:
>> > If maBufferRange was an extension, here's what I'd do to support it:
>> >
>> > 1. Write a shim for mapBufferRange using bufferSubData
>> > 2. Use that shim that internally switches to the bufferSubData extension
>> > if
>> > available, so that
>> > 3. I don't need to bifurcate all my data handling code on 2 functions
>> >
>> > That's probably just about (in one flavor or other) what everybody would
>> > do.
>> >
>> > Anyway, it's not like performance in WebGL was some kind of constant
>> > value.
>> > Platforms you test on routinely have a 10000% performance variance. It's
>> > nice if you can accelerate a usecase by 50% or so, very useful too, but
>> > it's
>> > not something you lose sleep over as far as platform differences go.
>> >
>> > On Fri, Mar 6, 2015 at 10:21 PM, Zhenyao Mo <zmo@chromium.org> wrote:
>> >>
>> >> It's the case where you write and test an app on an efficient
>> >> implementation (if we sort out all the BIT control) and expect it to
>> >> run the same everywhere else (which is what WebGL core promises) and
>> >> then this expectation in reality isn't real.
>> >>
>> >> On Fri, Mar 6, 2015 at 1:18 PM, Florian Bösch <pyalot@gmail.com> wrote:
>> >> > It's a bit ugly to recast an ES 3.0 core feature as an extension
>> >> > isn't
>> >> > it?
>> >> >
>> >> > Anyway, at worst mapBufferRange is no better than bufferSubData, and
>> >> > it'd
>> >> > help keep the code simple if you didn't need to write two codepaths
>> >> > depending on if you have it available or not.
>> >> >
>> >> > On Fri, Mar 6, 2015 at 10:12 PM, Zhenyao Mo <zmo@chromium.org> wrote:
>> >> >>
>> >> >> To me the MapBufferRange function seems more fit as an extension
>> >> >> rather than part of core for WebGL 2.  We want to preserve the
>> >> >> perception that this is something more efficient, but also make sure
>> >> >> developers understand that in WebGL 2 this efficiency is not
>> >> >> expected
>> >> >> everywhere.
>> >> >>
>> >> >>
>> >> >> On Fri, Mar 6, 2015 at 1:48 AM, Mark Callow <khronos@callow.im>
>> >> >> wrote:
>> >> >> >
>> >> >> >> On Mar 6, 2015, at 9:59 AM, Mark Callow <khronos@callow.im>
>> >> >> >> wrote:
>> >> >> >>
>> >> >> >> If implementation is a problem, how about requiring that
>> >> >> >> MAP_READ_BIT |
>> >> >> >> MAP_WRITE_BIT must always be specified?
>> >> >> >
>> >> >> > Shortly after writing this I realized it is a bad idea but was not
>> >> >> > in
>> >> >> > a
>> >> >> > position to correct myself until now. Why? Because it forces any
>> >> >> > implementation (WebGL or OpenGL) that implements map via copy to
>> >> >> > always copy
>> >> >> > in both map and unmap.
>> >> >> >
>> >> >> > I think the reason why these access bits exist is to allow such
>> >> >> > implementations to avoid a copy in map (write-only set) or unmap
>> >> >> > (read-only
>> >> >> > set). For implementations that actually map the buffers I expect
>> >> >> > there is
>> >> >> > probably no performance difference between single access and RW
>> >> >> > access.
>> >> >> >
>> >> >> > WebGL implementations that would copy during map/unmap could very
>> >> >> > easily
>> >> >> > enforce errors for bad applications without any changes to
>> >> >> > ArrayBuffers by
>> >> >> > not copying, as described above and providing a buffer initialized
>> >> >> > to
>> >> >> > 0 for
>> >> >> > the write-only case to prevent data leakage.
>> >> >> >
>> >> >> > Unfortunately the only way I see for WebGL implementations that
>> >> >> > would
>> >> >> > actually map buffers to work is to specify RW when calling the
>> >> >> > underlying
>> >> >> > OpenGL. This would be fine for correct applications (see above
>> >> >> > about
>> >> >> > performance), but would mean that bad applications would run
>> >> >> > without
>> >> >> > error.
>> >> >> > Thus bad apps would work in some implementations but not on others
>> >> >> > which is
>> >> >> > unacceptable for WebGL.
>> >> >> >
>> >> >> > So I think supporting MapBuffer does require read-only and
>> >> >> > write-only
>> >> >> > ArrayBuffers.
>> >> >> >
>> >> >> > Regards
>> >> >> >
>> >> >> >     -Mark
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>

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