[Mesa-dev] [PATCH 1/5] include/GL: add mesa_glinterop.h for OpenGL-OpenCL interop (v3)

[Marek Olšák]

On Mon, Apr 11, 2016 at 8:58 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 9 April 2016 at 01:21, Marek Olšák <maraeo at gmail.com> wrote:
>> On Fri, Apr 1, 2016 at 2:13 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 16 March 2016 at 10:40, Marek Olšák <maraeo at gmail.com> wrote:
>>>
>>>> "offset_after" isn't nasty. :) Yeah, I was inspired by other APIs I
>>>> had seen. The sizes make even more sense when they are function
>>>> parameters, because the caller can just do:
>>>> (sizeof(in), &in, sizeof(out), &out)
>>>>
>>> A nice list of arguments:
>>>  - If the majority of people like offset_after, the question "Why
>>> barely any projects use it (from a quick search) ?" comes to mind.
>>>  - I wasn't the only one advocating for versioned interfaces ;-)
>>>  - They will just work in an identical way and the code will be less.
>>>  - Regardless of how ugly/nasty/etc, mesa uses versioned interfaces
>>> throughout. "Consistency is the key" a wise man have said once.
>>>  - The interfaces using explicit size argument, that I'm aware of, are
>>> not designed with extensibility in mind.
>>
>> Updated branch with your suggestions applied:
>> https://cgit.freedesktop.org/~mareko/mesa/log/?h=interop
>>
> Thank you very much.
>
> Hopefully, some of the arguments made sense, as opposed to doing this
> just to make me happy (read 'shut me up').
>
> From a quick look:
>  - Food for thought: An feeling about "can we get away without
> including glx.h and EGL.h in mesa_glinterop.h" kicks in. As-is
> specifics from one winsys are leaked while building the other and
> vice-versa. I'm wondering about incomplete/forward declaration of the
> needed types, although that might be a bad idea ?

Maybe. I can't really make forward declarations if I don't know if
they are pointers to structs, pointers to void, or int handles.
Suggestions welcome.

>  - The struct_version checks seem off -> they are == 0, while they
> should be < 1. The idea is for newer versions to be backward
> compatible, correct ?

Version 0 isn't allowed. The first supported version is 1.

It is backward compatible as far as I can see.

Marek