2010/2/12 Ian Romanick <i...@freedesktop.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
>> b/src/mesa/drivers/dri/intel/intel_screen.c
>> index f7ce87e..c2c8c6e 100644
>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>> @@ -41,6 +41,7 @@
>>  #include "intel_fbo.h"
>>  #include "intel_screen.h"
>>  #include "intel_tex.h"
>> +#include "intel_regions.h"
>>
>>  #include "i915_drm.h"
>>
>> @@ -141,11 +142,84 @@ static const struct __DRI2flushExtensionRec 
>> intelFlushExtension = {
>>      intelDRI2FlushInvalidate,
>>  };
>>
>> +static __DRIimage *
>> +intel_create_image_internal(__DRIcontext *context,
>> +                         int width, int height, int internal_format,
>> +                         int name, int pitch, void *loaderPrivate)
>> +{
>> +    __DRIimage *image;
>> +    struct intel_context *intel = context->driverPrivate;
>> +    int cpp;
>> +
>> +    image = CALLOC(sizeof *image);
>> +    image->internal_format = internal_format;
>> +    switch (internal_format) {
>> +    case GL_RGBA:
>> +       image->format = MESA_FORMAT_ARGB8888;
>> +       image->data_type = GL_UNSIGNED_BYTE;
>> +       break;
>> +    case GL_RGB:
>> +       image->format = MESA_FORMAT_XRGB8888;
>> +       image->data_type = GL_UNSIGNED_BYTE;
>> +       break;
>> +    }
>
> No love for 565 or 4444 pixmaps?

Good question.  What is a sufficient way to specify the pixel format?
Internal format + datatype?  That's what glTexImage2D uses and should
be enough to describe the type of content and layout of the color
components, for example GL_RGB8 + GL_UNSIGNED_INT_8_8_8_8.
Alternatively we can expose the MESA_FORMAT_* values as __DRI_FORMAT_*
tokens and use that in the __DRIimage extension.  That would be
client-api independent, but GL tokens and types are already a
dependency in the DRI driver interface, so reusing the glTexImage2D
arguments wouldn't introduce new dependencies.  The problem with this
approach is that it requires the caller to know too much about the
pixel layout.  We don't actually know the pixel layout for a pixmap,
so the EGL doesn't know which layout to tell the DRI driver to use.

For DRI2 drawables, we assert that the DDX and DRI drivers agree on
the detail layout of the color components and we just need to
communicated the bits per pixel.  Can we keep do that for EGLImages
too?  Note, we don't need to provide enough information that clients
can map and access the pixels in the EGLImage.  The various client
APIs already provide mechanisms and detail information on pixel layout
for that.  We just need enough information to make sure that when we
pass buffers around, client APIs (OpenGL/OpenVG/etc) and external
users (DDX, cairo-drm, KMS) agree on the format.  As such, GL_RGBA8,
for example, is enough, since the drivers will all pick the same
underlying layout.

So... I think just using the internalFormat values will be fine.  The
semantics will be "pick the driver preferred layout for the provided
internalFormat".  Does that sounds feasible?

Kristian

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to