Kristian Høgsberg wrote:
> 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.
That particular format/type combo is invalid for glTexImage, btw.
> Alternatively we can expose the MESA_FORMAT_* values as __DRI_FORMAT_*
> tokens and use that in the __DRIimage extension.
I haven't followed this too closely... but FYI, there's no guarantee
that the MESA_FORMAT_x token values won't change at any time. If you
create some __DRI_FORMAT_x tokens they should probably have different
values just to be safe.
-Brian
> 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® 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
------------------------------------------------------------------------------
Download Intel® 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
