[Mesa-dev] [PATCH 1/5] include/GL: add mesa_glinterop.h for OpenGL-OpenCL interop (v3)
Marek Olšák
maraeo at gmail.com
Wed Mar 9 17:11:27 UTC 2016
On Wed, Mar 9, 2016 at 4:31 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 8 March 2016 at 22:29, Marek Olšák <maraeo at gmail.com> wrote:
>
>> Actually, I don't see how the version number would make it any better
>> for the structures, but returning the version number by
>> QueryDeviceInfo would be useful for the caller to know what to expect
>> if Mesa version < caller version. The sizes are still useful if Mesa
>> version > caller version.
>>
> If any of this is an issue, then the whole DRI model just won't work ;-)
The DRI extension versions only determine the number of function
callbacks, not function parameters and return values. This interop
thing is a lot more complicated than that, since it allows the "in"
and "out" structures to grow, and different rules apply to each. Also,
the implementation of DRI extensions allocates the structures, while
in the interop the user allocates the structures. It's a totally
different model.
>
> I'm thinking that the following should work. Please let me know if I'm
> loosing the plot.
>
> Caller sets the structure and sets version of the interface it
> provides. Then callee first checks if it can work with the provider
> version. then proceeds as planned.
The callee must always proceed even if the version is too low or too
high. The caller knows the Mesa interop version from QueryDeviceInfo
(defined in v4 and later) and knows what it should expect. Mesa only
checks the sizes, but otherwise doesn't care about the caller's
version.
> Passing around multiple sizes is ugly and error prone to a point. One
> gets the order wrong (swaps in_size and out_size) or just the same
> sizeof(struct foo) in both places.
The order of parameters in v5 is: in_size, *in, out_size, *out
If the implementation swaps in_size and out_size, it's no my problem.
Testing should show pretty quickly that's it's broken.
Marek
More information about the mesa-dev
mailing list