-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Hellström wrote: | Ian Romanick wrote: |> Jerome Glisse wrote: |> | On Mon, 19 May 2008 12:04:16 -0700 |> | Ian Romanick <[EMAIL PROTECTED]> wrote: |> | |> |> 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. |> | |> | I quickly browsed glx spec and failed to spot where this topic appear. |> | And what does B binds mean in this context, i am thinking to this use: |> | A & B share obj |> | A map |> | B map |> | A do some drawing |> | Hmm, | According to the GL spec, section 2.9 a GL buffer object cannot be | mapped again while in the mapped state | Given that, am I wrong in assuming that it's legal for B map to fail | with an INVALID_OPERATION error, even if there's no intermediate context | B bind?
My recollection is that it was supposed to be possible, but the language seems to indicate otherwise. It would be interesting to see what other implementations do in this case. | Also, what should be the correct action by the driver when an attempt is | made to | dereference a mapped buffer object with a GL command? Generate INVALID_OPERATION. This is in the GL_ARB_vertex_buffer_object spec: ~ "INVALID_OPERATION is generated if a buffer object that is currently ~ mapped is used as a source of GL render data, or as a destination of ~ GL query data." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFINL/2X1gOwKyEAw8RArfBAJ9EJLaYQHkQK9LLwtfeSLSwfDHbEACeLd6r +kqRG76ZO7kG5wlTcOWm9js= =VJ/M -----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
