2010/2/18 Brian Paul <bri...@vmware.com>:
> 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.
That was meant as an internalformat/type combo - that's valid right?
>> 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.
Yeah, they would be different tokens, the idea was to specify color
components and layout with one token similar to how the MESA_FORMAT_*
defines work, not to expose the MESA_FORMAT_* values directly. But
I'm leaning aginst not going for this idea.
I'm trying to figure out if it's appropriate to assume that all
drivers for a given chipset will choose the same pixel layout for, say
GL_RGBA8 or GL_RGB5. Then when we create an EGLImage from a GEM (or
TTM) handle we only need to pass GL_RGBA8 as the format value and the
driver will know how the components are laid out. Or do we need to
specify the pixel layout as well. Still not sure...
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
