If you read Nvidia's white paper on VBOs, they explicitly state that
you can generate a new VBO buffer while it is being used. Take a look
at p.10 under glBufferDataARB():
"If we call BufferDataARB again before the GPU is done, we can simply assign
the buffer object a new chunk of the large pool. This is possible because
BufferDataARB says we're going to re-specify all the data in the buffer
(as opposed to BufferSubDataARB). "
I wouldn't be surprised if you could do something similar with
textures although it would be nice to know.
wes
On Wed, May 14, 2008 at 4:08 PM, Ben Supnik <email@hidden> wrote:
> Hi Kamil,
>
> Yeah, in particular from the Apple docs:
>
> #
> Contexts that are on different threads can share object resources. For
> example, it is acceptable for one context in one thread to modify a texture
> and a second context in a second thread to modify the same texture. Why?
> Because the shared object handling provided by the Apple APIs automatically
> protects against thread errors. And, your application is following the "one
> thread per context" guideline.
> #
>
> made me think I could load a tex and use it at the same time...the visual
> artifacts are making me reconsider! I could call glFinish (or glFlush
> maybe) but those calls are moot without already putting some synchronization
> between the threads..
>
> For VBO loading I already do that, e.g. load a VBO from thread 1, call
> finish to ensure the cmd is submitted, then send a signal to the other
> thread, the receipt of which indicates the first legal use of the VBO, hence
> load is serialized before draw.
>
> But in this texture case the texture is already loaded and is just being
> _reloaded_, so my hope was to not require any locking. Perhaps a
> "double-buffering" scheme will be needed.
>
> cheers
> Ben
>
> Kamil Rocki wrote:
>>
>> Hi, I do not know the exact context of Your application and its
>> limitations, but some garbage can be produced with concurrent read/write.
>> Note that texture loading tasks are You can use glFinish() to explicitly end
>> particular texture processing tasks if that is Your question, but it may
>> block Your other threads as well. As I have written I do not now, how does
>> Your application look like.
>> Did you Read that?
>> http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_threading/chapter_12_section_3.html
>>
>> On 2008-05-14, at 23:08, Ben Supnik wrote:
>>
>>> Hi Y'all,
>>>
>>> My code will re-specify the contents of textures using
>>> glTexSubImage2d...right now there is no locking between the main thread
>>> (which may be using the texture) and the worker threads (which are reloading
>>> textures).
>>>
>>> On the GF8800 I see one-frame flashes in my scene as the textures are
>>> reloaded.
>>>
>>> At one point I got a crash in gDrawElements while other threads were
>>> calling glSubTexImage2d...both stacks went into the driver a bit.
>>>
>>> Do I need to be applying a bit more locking, either to be correct or to
>>> avoid artifacts?
>>>
>>> cheers
>>> ben
>>> --
>>> Scenery Home Page: http://scenery.x-plane.com/
>>> Scenery blog: http://xplanescenery.blogspot.com/
>>> Plugin SDK: http://www.xsquawkbox.net/xpsdk/
>>> X-Plane Wiki: http://wiki.x-plane.com/
>>> Scenery mailing list: email@hidden
>>> Developer mailing list: email@hidden
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Mac-opengl mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/mac-opengl/email@hidden
>>>
>>> This email sent to email@hidden
>>
>>
>
> --
> Scenery Home Page: http://scenery.x-plane.com/
> Scenery blog: http://xplanescenery.blogspot.com/
> Plugin SDK: http://www.xsquawkbox.net/xpsdk/
> X-Plane Wiki: http://wiki.x-plane.com/
> Scenery mailing list: email@hidden
> Developer mailing list: email@hidden
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Mac-opengl mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/mac-opengl/email@hidden
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
