- Original Message -
> Jose Fonseca writes:
> > - Original Message -
> >> On Sun, 2013-06-16 at 10:22 -0700, Jose Fonseca wrote:
> >>
> >> > Ok. I think this patch series is sound from an implementation POV. I
> >> > see no point in delaying further. We can tweak things afterwar
Jose Fonseca writes:
> - Original Message -
>> On Sun, 2013-06-16 at 10:22 -0700, Jose Fonseca wrote:
>>
>> > Ok. I think this patch series is sound from an implementation POV. I
>> > see no point in delaying further. We can tweak things afterwards if
>> > deemed necessary.
>> >
>> > Let
- Original Message -
> On Sun, 2013-06-16 at 10:22 -0700, Jose Fonseca wrote:
>
> > Ok. I think this patch series is sound from an implementation POV. I
> > see no point in delaying further. We can tweak things afterwards if
> > deemed necessary.
> >
> > Lets squash the commits, rename
On Sun, 2013-06-16 at 10:22 -0700, Jose Fonseca wrote:
> Ok. I think this patch series is sound from an implementation POV. I
> see no point in delaying further. We can tweak things afterwards if
> deemed necessary.
>
> Lets squash the commits, rename the XYZW formats to go from
> low->high b
- Original Message -
> - Original Message -
> > Jose Fonseca writes:
> > >> Yeah, that's what the patch was trying to do. Even though the formats
> > >> were defined as "int"s, the int layout was extra information on top of
> > >> what's already there. The int information didn'
Christoph Bumiller writes:
> On 06.06.2013 10:34, Richard Sandiford wrote:
>> Michel Dänzer writes:
>>> On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
(2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
mesa-like ones with msb first. (I'm happy to ch
On 06.06.2013 10:34, Richard Sandiford wrote:
> Michel Dänzer writes:
>> On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
>>> (2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
>>> mesa-like ones with msb first. (I'm happy to change the names to
>>> somethin
Michel Dänzer writes:
> On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
>>
>> (2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
>> mesa-like ones with msb first. (I'm happy to change the names to
>> something else though.)
>>
>> The patch isn't in a subm
On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
>
> (2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
> mesa-like ones with msb first. (I'm happy to change the names to
> something else though.)
>
> The patch isn't in a submittable state yet. I just thou
- Original Message -
> Jose Fonseca writes:
> >> Yeah, that's what the patch was trying to do. Even though the formats
> >> were defined as "int"s, the int layout was extra information on top of
> >> what's already there. The int information didn't change or replace the
> >> array inform
- Original Message -
> On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
> > - Original Message -
> > > Michel Dänzer writes:
> > > > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> > > >>
> > > >> I agree that with non-array formats, like B5G6R5 and R5G6B5, replac
Jose Fonseca writes:
>> Yeah, that's what the patch was trying to do. Even though the formats
>> were defined as "int"s, the int layout was extra information on top of
>> what's already there. The int information didn't change or replace the
>> array information.
>>
>> So the idea is that the a
- Original Message -
> - Original Message -
> > Michel Dänzer writes:
> > > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> > >>
> > >> I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
> > >> them with endian-variant BGR565 and RGB565 makes a lot o
On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
> - Original Message -
> > Michel Dänzer writes:
> > > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> > >>
> > >> I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
> > >> them with endian-variant BGR565
- Original Message -
> Michel Dänzer writes:
> > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> >>
> >> I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
> >> them with endian-variant BGR565 and RGB565 makes a lot of sense (as
> >> the swapped version will p
Michel Dänzer writes:
> On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
>>
>> I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
>> them with endian-variant BGR565 and RGB565 makes a lot of sense (as
>> the swapped version will probably never be needed).
>>
>> But I'm
On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
>
> I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
> them with endian-variant BGR565 and RGB565 makes a lot of sense (as
> the swapped version will probably never be needed).
>
> But I'm not sure about RGBA8 variants.
- Original Message -
> Michel Dänzer writes:
> >> > For packed formats such as RGBA, the order used in these patches
> >> > (which is what I suggested in my proposal) matches the order humans use
> >> > for digits of numbers, as well as the Mesa formats. That seems more
> >> > import
Michel Dänzer writes:
>> > For packed formats such as RGBA, the order used in these patches
>> > (which is what I suggested in my proposal) matches the order humans use
>> > for digits of numbers, as well as the Mesa formats. That seems more
>> > important to me than 'matching' any non-packed
On Mit, 2013-05-22 at 01:56 -0700, Jose Fonseca wrote:
> - Original Message -
> > On Die, 2013-05-21 at 23:15 -0700, Jose Fonseca wrote:
> > > - Original Message -
> > > > Jose Fonseca writes:
> > > > > - Original Message -
> > > > >> From: Richard Sandiford
> > > > >>
>
- Original Message -
> On Die, 2013-05-21 at 23:15 -0700, Jose Fonseca wrote:
> >
> > - Original Message -
> > > Jose Fonseca writes:
> > > > - Original Message -
> > > >> From: Richard Sandiford
> > > >>
> > > >> RGBA has R at byte 0 and A at byte 3, regardless of
On Die, 2013-05-21 at 23:15 -0700, Jose Fonseca wrote:
>
> - Original Message -
> > Jose Fonseca writes:
> > > - Original Message -
> > >> From: Richard Sandiford
> > >>
> > >> RGBA has R at byte 0 and A at byte 3, regardless of platform
> > >> endianness.
> > >
> > > Maybe
- Original Message -
> Hi Jose,
>
> Thanks for the review.
>
> Jose Fonseca writes:
> > - Original Message -
> >> From: Richard Sandiford
> >>
> >> RGBA has R at byte 0 and A at byte 3, regardless of platform
> >> endianness.
> >
> > Maybe I'm missing something, but this
Hi Jose,
Thanks for the review.
Jose Fonseca writes:
> - Original Message -
>> From: Richard Sandiford
>>
>> RGBA has R at byte 0 and A at byte 3, regardless of platform
>> endianness.
>
> Maybe I'm missing something, but this naming convention seems to me
> the exact opposite of w
- Original Message -
> From: Richard Sandiford
>
> RGBA has R at byte 0 and A at byte 3, regardless of platform
> endianness.
Maybe I'm missing something, but this naming convention seems to me the exact
opposite of what was decided [1], which is:
- R at byte 0, ..., and A at byte
It should be documented somewhere why certain formats are named
xyzw and the others are named x8y8z8w8.
Marek
On Thu, May 16, 2013 at 3:06 PM, Adam Jackson wrote:
> From: Richard Sandiford
>
> RGBA has R at byte 0 and A at byte 3, regardless of platform
> endianness.
>
> Reviewed-by: Ad
From: Richard Sandiford
RGBA has R at byte 0 and A at byte 3, regardless of platform
endianness.
Reviewed-by: Adam Jackson
---
src/gallium/include/pipe/p_format.h | 38 +
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/src/gallium/include/
27 matches
Mail list logo
