On Mon, 19 May 2008 02:22:00 -0700 Ian Romanick <[EMAIL PROTECTED]> wrote: > > There is also a bunch of up-and-coming GL functionality that you may not > be aware of that changes this picture a *LOT*. > > - - GL_EXT_texture_buffer_object allows a portion of a buffer object to be > used to back a texture. > > - - GL_EXT_bindable_uniform allows a portion of a buffer object to be used > to back a block of uniforms. > > - - GL_EXT_transform_feedback allows the output of the vertex shader or > geometry shader to be stored to buffer objects. > > - - Long's Peak has functionality where a buffer object can be mapped > *without* waiting for all previous GL commands to complete. > GL_APPLE_flush_buffer_range has similar functionality. > > - - Long's Peak has NV_fence-like synchronization objects. > > The usage scenario that ISVs (and that other vendors are going to make > fast) is one where transform feedback is used to "render" a bunch of > objects to a single buffer object. There is a fair amount of overhead > in changing all the output buffer object bindings, so ISVs don't want to > be forced to take that performance hit. If a fence is set after each > object is sent down the pipe, the app can wait for one object to finish > rendering, map the buffer object, and operate on the data. > > Similar situations can occur even without transform feedback. Imagine > an app that is streaming data into a buffer object. It streams in one > object (via MapBuffer), does a draw command, sets a fence, streams in > the next, etc. When the buffer is full, it waits on the first fence, > and starts back at the beginning. Apparently, a lot of ISVs are wanting > to do this. I'm not a big fan of this usage. It seems that nobody ever > got fire-and-forget buffer objects (repeated cycle of allocate, fill, > use, delete) to be fast, so this is what ISVs are wanting instead. > > In other news, app developers *hate* BufferSubData. They much prefer to > just map the buffer and write to it or read from it. > > All of this points to mapping buffers to the CPU in, on, and around GPU > usage being a very common operation. It's also an operation that app > developers expect to be fast. >
Thanks Ian to stress current and future usage, i was really hopping that with GL3 buffer object mapping would have vanish but i guess as you said that the fire-and-forget path never get optimized. Does in GL3 object must be unmapped before being use ? IIRC this what is required in current GL 1.x and GL 2.x. If so i think i can still use VRAM as cache ie i put their object which are barely never mapped (like a constant texture, or constant vertex table). This avoid me to think to complexe solution for cleanly handling unmappable vram. A side question is there any data on tlb flush ? ie how much map/unmap, from client vma, cycle cost. In the meantime i think we can promote use of pread/pwrite or BufferSubData to take advantage of offset & size information in software we do (mesa, EXA, ...). Ian do you know why dev hate BufferSubData ? Is there any place i can read about it ? I have been focusing on driver dev and i am little bit out dated on today typical GL usage, i assumed that hw manufacturer did promote use of BufferSubData to software dev. Cheers, Jerome Glisse ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
