On Fri, 2006-09-22 at 14:06 +0100, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Fri, 2006-09-22 at 11:14 +0100, Keith Whitwell wrote:
> >> Maybe enable for the paths that are well understood and tested, but
> >> where it is still behaving contrary to expectations, leave it disabled.
> >>
Keith Whitwell wrote:
> Brian Paul wrote:
>
>> Michel Dänzer wrote:
>>
>>> Keith wrote:
>>>
> I think from Brian's description of the meaning of the
> texture format struct naming, a driver that wanted a
> different component order in a packed field would have
> to specify a differ
Michel Dänzer wrote:
> On Fri, 2006-09-22 at 11:14 +0100, Keith Whitwell wrote:
>
>>Maybe enable for the paths that are well understood and tested, but
>>where it is still behaving contrary to expectations, leave it disabled.
>>I'd say it is behaving as expected in the software mesa cases an
Keith Whitwell wrote:
> Michel Dänzer wrote:
>>My gut feeling is that the destination byte order should be handled
>>slightly more explicitly; in particular, I don't see a way for drivers
>>to specify which byte order they want for packed formats where component
>>boundaries don't fall on byte bou
Brian Paul wrote:
> Michel Dänzer wrote:
>> Keith wrote:
>>
I think from Brian's description of the meaning of the
texture format struct naming, a driver that wanted a
different component order in a packed field would have
to specify a different texformat struct - ie the
c
On Thursday 21 September 2006 17:57, Brian Paul wrote:
> Interestingly, these two variations produce different code (gcc -O2):
>
> static INLINE GLboolean
> _mesa_little_endian(void)
> {
> static const GLuint ui = 1;// NOTE: static
> return *((const GLubyte *) &ui);
> }
>
> static
Michel Dänzer wrote:
>Keith wrote:
>
>>> I think from Brian's description of the meaning of the
>>> texture format struct naming, a driver that wanted a
>>> different component order in a packed field would have
>>> to specify a different texformat struct - ie the
>>> component ordering for a giv
Michel Dänzer wrote:
> On Fri, 2006-09-22 at 11:14 +0100, Keith Whitwell wrote:
>> Maybe enable for the paths that are well understood and tested, but
>> where it is still behaving contrary to expectations, leave it disabled.
>> I'd say it is behaving as expected in the software mesa cases an
On Fri, 2006-09-22 at 11:14 +0100, Keith Whitwell wrote:
>
> Maybe enable for the paths that are well understood and tested, but
> where it is still behaving contrary to expectations, leave it disabled.
> I'd say it is behaving as expected in the software mesa cases and
> argb.
Our con
Michel Dänzer wrote:
> On Fri, 2006-09-22 at 10:58 +0100, Keith Whitwell wrote:
>> Michel Dänzer wrote:
>>> On Fri, 2006-09-22 at 10:41 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
> - if (dstFormat == &_mesa_texformat_argb) {
> + if (!littleEndian || dstFor
On Fri, 2006-09-22 at 10:58 +0100, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Fri, 2006-09-22 at 10:41 +0100, Keith Whitwell wrote:
> >> Michel Dänzer wrote:
> >>
> >>> - if (dstFormat == &_mesa_texformat_argb) {
> >>> + if (!littleEndian || dstFormat == &_mesa_texformat_arg
Michel Dänzer wrote:
> On Fri, 2006-09-22 at 10:41 +0100, Keith Whitwell wrote:
>> Michel Dänzer wrote:
>>
>>> - if (dstFormat == &_mesa_texformat_argb) {
>>> + if (!littleEndian || dstFormat == &_mesa_texformat_argb) {
>> In cases like this, wouldn't you want the exclusive or of
On Fri, 2006-09-22 at 10:41 +0100, Keith Whitwell wrote:
> Michel Dänzer wrote:
>
> > - if (dstFormat == &_mesa_texformat_argb) {
> > + if (!littleEndian || dstFormat == &_mesa_texformat_argb) {
>
> In cases like this, wouldn't you want the exclusive or of the two
> values, ie
On Fri, 2006-09-22 at 10:34 +0100, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Fri, 2006-09-22 at 09:17 +0100, Keith Whitwell wrote:
> >> Michel Dänzer wrote:
> >>> On Thu, 2006-09-21 at 19:28 +0100, Keith Whitwell wrote:
> >
> 2) How bigEndian affects how we layout hardware texture
Michel Dänzer wrote:
> - if (dstFormat == &_mesa_texformat_argb) {
> + if (!littleEndian || dstFormat == &_mesa_texformat_argb) {
In cases like this, wouldn't you want the exclusive or of the two
values, ie
((littleEndian && dstFormat == &_mesa_texformat_argb88
Michel Dänzer wrote:
> On Fri, 2006-09-22 at 09:17 +0100, Keith Whitwell wrote:
>> Michel Dänzer wrote:
>>> On Thu, 2006-09-21 at 19:28 +0100, Keith Whitwell wrote:
1) How bigEndian affects how we interpret source data relative to its
format and type.
>>> Should just require byte swappi
On Fri, 2006-09-22 at 09:17 +0100, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Thu, 2006-09-21 at 19:28 +0100, Keith Whitwell wrote:
> >>
> >> 1) How bigEndian affects how we interpret source data relative to its
> >> format and type.
> >
> > Should just require byte swapping for the conv
Michel Dänzer wrote:
> On Thu, 2006-09-21 at 19:28 +0100, Keith Whitwell wrote:
>> Michel Dänzer wrote:
>>> On Thu, 2006-09-21 at 16:29 +0100, Keith Whitwell wrote:> > OK, that's
>>> kooky. I guess I haven't got a handle on the problem yet for > bigEndian,
>>> it may be that there's another con
On Thu, 2006-09-21 at 19:28 +0100, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Thu, 2006-09-21 at 16:29 +0100, Keith Whitwell wrote:> > OK, that's
> > kooky. I guess I haven't got a handle on the problem yet for > bigEndian,
> > it may be that there's another conversion needed on the bac
19 matches
Mail list logo
