[Mesa-dev] [PATCH] mesa: add OES_EGL_image_external_essl3 support

[Ilia Mirkin]

On Tue, Mar 24, 2015 at 1:41 AM, Tapani Pälli <tapani.palli at intel.com> wrote:
>
>
> On 03/23/2015 02:41 PM, Ilia Mirkin wrote:
>>
>> On Mon, Mar 23, 2015 at 8:06 AM, Tapani Pälli <tapani.palli at intel.com>
>> wrote:
>>>
>>>
>>>
>>> On 03/23/2015 01:43 PM, Ilia Mirkin wrote:
>>>>
>>>>
>>>> On Mon, Mar 23, 2015 at 3:20 AM, Tapani Pälli <tapani.palli at intel.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 03/22/2015 12:07 AM, Ilia Mirkin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>>>>>> ---
>>>>>>
>>>>>> Not sure what kind of testing is needed here... thought I'd just send
>>>>>> this out though, as the extension is simple enough. Wasn't sure
>>>>>> whether mesa already handles the requirements re marking the texture
>>>>>> as incomplete if the sampler has funny settings.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Looks good to me, one thing that might need additional work or maybe
>>>>> just
>>>>> comments for now is the interaction with image load store for compute
>>>>> shaders, judging from the format checks in shaderimage.c, external
>>>>> textures
>>>>> would not work at the moment for BindImageTexture, I'm not sure if this
>>>>> extension is expected to work without compute shaders but just using
>>>>> GL_ARB_image_load_store (?)
>>>>
>>>>
>>>>
>>>> This extension is written against ESSL3 which doesn't have either of
>>>> those. In ESSL3.1, both of those would be available. See issue 10 --
>>>> they're accessed using image2D. I don't really see anything in the
>>>> current shader image logic that would prevent that from working.
>>>
>>>
>>>
>>> OK, the thing puzzling me is that how the format check in
>>> BindImageTexture
>>> will work out if you would call BindImageTexture with external texture
>>> that
>>> has some exotic format?
>>
>>
>> Oh right. I was thinking about it wrt target, not format. Yeah.... not
>> sure about that. I just saw a really simple extension, figured I'd add
>> it. Happy to drop it as well...
>>
>
> I don't want to shoot it down, I was just trying to figure out some 'new'
> things that could be tested and possible interaction with
> GL_ARB_image_load_store looks like one of those. Otherwise it looks like the
> features are tested by existing "ext_image_dma_buf_import" tests that use
> GL_OES_EGL_image_external.
>
> // Tapani

So... what's the verdict? Push or drop?

  -ilia