2010/6/4 Kristian Høgsberg :
> 2010/6/3 Chia-I Wu :
>> 2010/6/3 Kristian Høgsberg :
>>> 2010/6/3 Chia-I Wu :
2010/6/3 Kristian Høgsberg :
>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR
>> to be
>> queryable, which is stemmed from using EGLImageKHR to r
2010/6/4 Jakob Bornecrantz :
>> And also because the use case for it was solved in another way. But in
>> defence of my create_image extension, its quite small and limited in
>> scope. But in Chia-I fav the fact that we lack configs to say which
>> formats we support is a bit sad. But I can also se
On Thu, 3 Jun 2010 13:24:08 -0400, Kristian Høgsberg wrote:
> On Thu, Jun 3, 2010 at 1:16 PM, Brian Paul wrote:
> > Jakob Bornecrantz wrote:
> >>
> >> Currently these extensions try to address two use cases. Creating
> >> Images to be shared between processes. Creating resources to be used
> >> a
> And also because the use case for it was solved in another way. But in
> defence of my create_image extension, its quite small and limited in
> scope. But in Chia-I fav the fact that we lack configs to say which
> formats we support is a bit sad. But I can also see how this thing can
> feature cr
2010/6/3 Kristian Høgsberg :
> 2010/6/3 Chia-I Wu :
>> 2010/6/3 Kristian Høgsberg :
>>> 2010/6/3 Chia-I Wu :
2010/6/3 Kristian Høgsberg :
>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR
>> to be
>> queryable, which is stemmed from using EGLImageKHR to r
On Thu, Jun 3, 2010 at 1:16 PM, Brian Paul wrote:
> Jakob Bornecrantz wrote:
>>
>> 2010/6/3 Chia-I Wu :
>>>
>>> 2010/6/3 Kristian Høgsberg :
2010/6/3 Chia-I Wu :
>
> 2010/6/3 Kristian Høgsberg :
>>>
>>> But it is less flexible IMHO. Also, I am not convinced that
>>>
Jakob Bornecrantz wrote:
2010/6/3 Chia-I Wu :
2010/6/3 Kristian Høgsberg :
2010/6/3 Chia-I Wu :
2010/6/3 Kristian Høgsberg :
But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to be
queryable, which is stemmed from using EGLImageKHR to represent pipe_resource.
Using an E
2010/6/3 Chia-I Wu :
> 2010/6/3 Kristian Høgsberg :
>> 2010/6/3 Chia-I Wu :
>>> 2010/6/3 Kristian Høgsberg :
> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR
> to be
> queryable, which is stemmed from using EGLImageKHR to represent
> pipe_resource.
>
2010/6/3 Chia-I Wu :
> 2010/6/3 Kristian Høgsberg :
>> 2010/6/3 Chia-I Wu :
>>> 2010/6/3 Kristian Høgsberg :
> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR
> to be
> queryable, which is stemmed from using EGLImageKHR to represent
> pipe_resource.
>
2010/6/3 Kristian Høgsberg :
> 2010/6/3 Chia-I Wu :
>> 2010/6/3 Kristian Høgsberg :
But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR
to be
queryable, which is stemmed from using EGLImageKHR to represent
pipe_resource.
Using an EGLImageKHR also impl
2010/6/3 Chia-I Wu :
> 2010/6/3 Kristian Høgsberg :
>>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to
>>> be
>>> queryable, which is stemmed from using EGLImageKHR to represent
>>> pipe_resource.
>>> Using an EGLImageKHR also implies that an implementation must imple
2010/6/3 Chia-I Wu :
> 2010/6/3 Kristian Høgsberg :
>>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to
>>> be
>>> queryable, which is stemmed from using EGLImageKHR to represent
>>> pipe_resource.
>>> Using an EGLImageKHR also implies that an implementation must imple
2010/6/3 Kristian Høgsberg :
>> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to
>> be
>> queryable, which is stemmed from using EGLImageKHR to represent
>> pipe_resource.
>> Using an EGLImageKHR also implies that an implementation must implement
>> EGLImage in EGL/GLES
On Sat, May 29, 2010 at 6:35 PM, Chia-I Wu wrote:
> Hi Jakob,
>
> I like the way the extensions are separated and presented. But I have some
> thoughts about the entrypoints and EGL types to use.
>
> To begin with, I think the goal of this series of extensions is to export a
> subset of pipe_scre
On Sun, May 30, 2010 at 6:35 AM, Chia-I Wu wrote:
> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to be
> queryable, which is stemmed from using EGLImageKHR to represent pipe_resource.
> Using an EGLImageKHR also implies that an implementation must implement
> EGLImage i
Hi Jakob,
I like the way the extensions are separated and presented. But I have some
thoughts about the entrypoints and EGL types to use.
To begin with, I think the goal of this series of extensions is to export a
subset of pipe_screen->resource_create, pipe_screen->resource_from_handle, and
pip
Hi all!
This patch series add a series of extension that enables an application to
create stand alone images, get attributes from images, create images that
are sutiable for scantout and sharing and finally get drm handles from images
to be either shared or used with kms as scanouts.
Each set of
17 matches
Mail list logo
