-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jerome Glisse wrote:
| 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. I think various drivers have tried to optimize it. I think it's just a case where an application managed suballocator will just always be faster. | 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. Be careful here. An object must be unmapped in the context where it is used for drawing. However, buffer objects can be shared between contexts. This means that even today in OpenGL 1.5 context A can be drawing with a buffer object while context B has it mapped. Of course, context A doesn't have to see the changes caused by context B until the next time it binds the buffer. This means that copying data for the map will "just work." But to actually answer the original question, a buffer that will be used as a source or destination by the GL must be unmapped at Begin time. | 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. Because it forces them to make extra copies of their data and do extra copy operations. As an app developer, I *much* prefer: glBindBuffer(GL_ARRAY_BUFFER, my_buf); GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE); if (data == NULL) { /* fail */ } /* Fill in buffer data */ glUnmapBuffer(GL_ARRAY_BUFFER); Over: GLfloat *data = malloc(buffer_size); if (data == NULL) { /* fail */ } /* Fill in buffer data */ glBindBuffer(GL_ARRAY_BUFFER, my_buf); glBufferSubData(GL_ARRAY_BUFFER, 0, buffer_size, data); free(data); The second version obviously has extra overhead and takes a performance hit. So, now I have to go back and spend time caching the buffer allocations and doing other things to make it fast. In the MapBuffer version, I can leverage the work done by the smart guys that write drivers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMbf5X1gOwKyEAw8RAvvRAJ4gEjByIWndSs4NWmVFTAOgBQHqAgCaA3pK 2ShJGYatMlCxHR57CSYbuTk= =FOBu -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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