On 9 March 2016 at 17:28, Marek Olšák <mar...@gmail.com> wrote:
> On Wed, Mar 9, 2016 at 4:47 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>> On 8 March 2016 at 15:39, Marek Olšák <mar...@gmail.com> wrote:
>>> On Thu, Mar 3, 2016 at 11:56 PM, Emil Velikov <emil.l.veli...@gmail.com>
>>> wrote:
>>>> Hi Marek,
>>>>
>>>> A small question, and a few trivial suggestions. Hopefully I'm not too
>>>> late for the party.
>>>>
>>>> On 3 March 2016 at 19:46, Marek Olšák <mar...@gmail.com> wrote:
>>>>
>>>>> +typedef struct _mesa_glinterop_device_info {
>>>>> + uint32_t size; /* size of this structure */
>>>>> +
>>>> I believe Michel suggested a similar thing: Wouldn't it be better to
>>>> use a version one just like we do for the DRI extensions ? Many other
>>>> interfaces also use version, some with a combination of size, but this
>>>> is the first one in my experience that does only size.
>>>>
>>>>
>>>>> +typedef struct _mesa_glinterop_export_in {
>>>>
>>>>> + /* Size of memory pointed to by out_driver_data. */
>>>>> + uint32_t out_driver_data_size;
>>>>> +
>>>>> + /* If the caller wants to query driver-specific data about the OpenGL
>>>>> + * object, this should point to the memory where that data will be
>>>>> stored.
>>>>> + */
>>>>> + void *out_driver_data;
>>>> I take it that the structure and format of this data will be
>>>> internal/implementation specific, correct ? As on each side there will
>>>
>>> Yes.
>>>
>>>> be some sanity checking, wouldn't to be better to have size (version
>>>> and/or other) within that structure format.
>>>
>>> Since amdgpu isn't going to use this feature, I don't care too much about
>>> it.
>>>
>>> Having the size outside of the driver-specific structure seems safer.
>>>
>> Trying future proof things does not work nicely, most of the time.
>> Imho it should be added as there is a user for it.
>
> I agree, but:
> 1) Intel want it, so there is a future user.
> 2) One of our OpenCL guys and I have agreed to keep it in case we need
> in the future too.
>
Don't mean to sound snarky - two sentences, each consisting the word
"future" :-)
There was a song somewhere called "Tomorrow never comes".
>>
>>>>
>>>> IMHO it's worth mentioning any of that, plus some information about
>>>> the lifetime expectancy of the data. Thus it's perfectly clear to the
>>>> user how to manage/use it.
>>>
>>> The data pointer should only be used for querying stuff from Mesa. The
>>> same rules as for the "out" pointer apply.
>>>
>> I think there is some misunderstanding here. I wasn't asking "Who is
>> going to use this data ?", but "Can they use the pointer reliably, or
>> should they copy the data from it before using it. Copy, because the
>> opposite end will discard/free the block shortly after the call". I've
>> seen some people referring to this as lifetime expectancy, not sure if
>> it's the correct terminology to use here.
>
> I'm not sure I fully understand. It can be a local variable in the
> OpenCL stack or a variable in a long-living OpenCL object. Mesa/GL can
> only write data to it inside the interop call.
>
It was a misunderstanding from my end. Sorry for the noise.
Thanks again, for keeping up with my question/suggestions.
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
