2010/2/18 Kristian Høgsberg <k...@bitplanet.net>:
> 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?
Yes. It's the glTexImage format and type parameters that have
particular combinations that are legal or illegal.
>>> 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...
-Brian
------------------------------------------------------------------------------
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
