Ian Romanick wrote: > -----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."
OK, thanks Ian. /Thomas ------------------------------------------------------------------------- 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
