-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jerome Glisse wrote: | On Mon, 19 May 2008 10:25:16 -0700 | Ian Romanick <[EMAIL PROTECTED]> wrote: | |> | 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." | | Is the result defined by GL specification ? ie does B need to access an | old copy of the object or if A is rendering to this object can we let B | see the ongoing rendering. | | In latter case this likely lead to broken rendering if there is no | synchronization btw A & B.
The GLX spec says, basically, that the results of changes to a shared object in context A are guaranteed to be visible to context B when context B binds the object. It leaves a lot of slack for changes to show up earlier. This is part of the reason that app developers want NV_fence-like functionality. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMc8rX1gOwKyEAw8RAposAKCWQ8fTtIPHuvNXmj36eq+P7qeNIACfYHuB 564mXsChzRey46q8RXv15bI= =0GZC -----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
