GL.BufferObjects patch request (1-liner)
I think withMappedBuffer does not cover all the use cases of mapped PBO - please add mapBuffer, unmapBuffer to the list of module exports. They come in handy when trying to do concurrent/async texture streaming.
On Thursday 06 November 2008 08:01:56 Neal Alexander wrote:
I think withMappedBuffer does not cover all the use cases of mapped PBO - please add mapBuffer, unmapBuffer to the list of module exports.
They come in handy when trying to do concurrent/async texture streaming.
OK, this would really be easy and I have no objections. But I would really like to understand why withMappedBuffer is not sufficient. Could you please post some code snippets plus an explanation? Leaving a buffer mapped without a matching unmapping sounds a bit strange at first, but I am really willing to learn and improve the buffer API. I am thinking about a new version of my OpenGL binding, which supports only OpenGL 3.x features, without any deprecated API entries/constants. This would be much smaller and probably a bit nicer, but at the price of losing backwards compatibility. Buffers play a much more central role in OpenGL 3.x, so supporting common use cases in the binding is really important. Anyway, improving support for OpenGL 2.1 in the current binding is important, too. Cheers, S.
Sven Panne wrote:
OK, this would really be easy and I have no objections. But I would really like to understand why withMappedBuffer is not sufficient. Could you please post some code snippets plus an explanation? Leaving a buffer mapped without a matching unmapping sounds a bit strange at first, but I am really willing to learn and improve the buffer API.
If you use a single thread for OpenGL, but want to offload resource loading to a worker thread, you can mapBuffer in the GL thread then send the pointer to a worker thread (no GL context), then queue the unmapBuffer in the GL thread. withMappedBuffer locks everything into the calling thread.
I am thinking about a new version of my OpenGL binding, which supports only OpenGL 3.x features, without any deprecated API entries/constants. This would be much smaller and probably a bit nicer, but at the price of losing backwards compatibility.
Nice. It would probably work fine to have a separate package for OGL3 stuff and let people use the old one if they need compatibility.
Am Donnerstag, 20. November 2008 17:17:43 schrieb Neal Alexander:
[...] If you use a single thread for OpenGL, but want to offload resource loading to a worker thread, you can mapBuffer in the GL thread then send the pointer to a worker thread (no GL context), then queue the unmapBuffer in the GL thread.
withMappedBuffer locks everything into the calling thread. [...]
I am not 100% convinced that there is no way around this using withMappedBuffer (e.g. by passing the pointer from the wrapped action to another thread), but nevertheless, I've added mapBuffer and unmapBuffer to the exported API of the OpenGL package. Note the signature of mapBuffer: mapBuffer :: BufferTarget -> BufferAccess -> IO (Maybe (Ptr a)) Although not strictly necessary, I've explicitly wrapped the resulting pointer into a Maybe, making it crystal-clear that the caller should handle errors somehow. For consistency reasons, I've added the beginQuery/endQuery pair as an alternative for withQuery, too. Although I'm really striving for API minimality, anticipating all possible uses of an API is really hard. Having 2 ways of achieving things is not nice, but it is probably the safest thing to do here. *sigh* Cheers, S.
Sven Panne wrote:
I am not 100% convinced that there is no way around this using withMappedBuffer (e.g. by passing the pointer from the wrapped action to another thread)
The ptr gets globally unmapped by withMappedBuffer though.
Although I'm really striving for API minimality, anticipating all possible uses of an API is really hard. Having 2 ways of achieving things is not nice, but it is probably the safest thing to do here. *sigh*
Yea. Maybe you could do like the ByteString library and export things like this from an "internals" module. http://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data... Or just separate the package into a direct C-API translation (with some haskell style error handling), then build a higher level haskell API ontop of it (withXXXX functions, added type safety, etc) - maybe even as a seperate hackage library.
Am Dienstag, 28. April 2009 23:42:55 schrieb Neal Alexander:
[...] Or just separate the package into a direct C-API translation (with some haskell style error handling), then build a higher level haskell API ontop of it (withXXXX functions, added type safety, etc) - maybe even as a seperate hackage library.
Separating the OpenGL library into two layers would be a dream, but it won't happen until the OpenGL ARB manages to release a consistent, machine-usable, complete specification of the OpenGL API. The .spec files really, really suck, they need a lot of manual work to make them usable, are incomplete and redundant at the same time, and do not contain enough information for some important purposes. The Mesa3D project described them once as a P.I.T.A., which is exactly my opinion, too... *sigh* Cheers, S.
participants (4)
-
Neal Alexander -
Neal Alexander -
Sven Panne -
Sven Panne