- Original Message -
Jose Fonseca jfons...@vmware.com 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
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 bit,
- 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 the
Jose Fonseca jfons...@vmware.com 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.
- Original Message -
- Original Message -
Jose Fonseca jfons...@vmware.com writes:
Yeah, that's what the patch was trying to do. Even though the formats
were defined as ints, the int layout was extra information on top of
what's already there. The int information
Michel Dänzer mic...@daenzer.net 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
On 06.06.2013 10:34, Richard Sandiford wrote:
Michel Dänzer mic...@daenzer.net 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
Christoph Bumiller e0425...@student.tuwien.ac.at writes:
On 06.06.2013 10:34, Richard Sandiford wrote:
Michel Dänzer mic...@daenzer.net 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
- Original Message -
Michel Dänzer mic...@daenzer.net 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
On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
- Original Message -
Michel Dänzer mic...@daenzer.net 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 -
- Original Message -
Michel Dänzer mic...@daenzer.net 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
Jose Fonseca jfons...@vmware.com writes:
Yeah, that's what the patch was trying to do. Even though the formats
were defined as ints, 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
- Original Message -
On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
- Original Message -
Michel Dänzer mic...@daenzer.net writes:
On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
I agree that with non-array formats, like B5G6R5 and R5G6B5,
- Original Message -
Jose Fonseca jfons...@vmware.com writes:
Yeah, that's what the patch was trying to do. Even though the formats
were defined as ints, the int layout was extra information on top of
what's already there. The int information didn't change or replace the
array
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 thought
Michel Dänzer mic...@daenzer.net 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).
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 mic...@daenzer.net 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
- Original Message -
Hi Jose,
Thanks for the review.
Jose Fonseca jfons...@vmware.com writes:
- Original Message -
From: Richard Sandiford r.sandif...@uk.ibm.com
RGBA has R at byte 0 and A at byte 3, regardless of platform
endianness.
Maybe I'm missing
On Die, 2013-05-21 at 23:15 -0700, Jose Fonseca wrote:
- Original Message -
Jose Fonseca jfons...@vmware.com writes:
- Original Message -
From: Richard Sandiford r.sandif...@uk.ibm.com
RGBA has R at byte 0 and A at byte 3, regardless of platform
endianness.
- Original Message -
On Die, 2013-05-21 at 23:15 -0700, Jose Fonseca wrote:
- Original Message -
Jose Fonseca jfons...@vmware.com writes:
- Original Message -
From: Richard Sandiford r.sandif...@uk.ibm.com
RGBA has R at byte 0 and A at byte
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 jfons...@vmware.com writes:
- Original Message -
From: Richard Sandiford
Michel Dänzer mic...@daenzer.net 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
Hi Jose,
Thanks for the review.
Jose Fonseca jfons...@vmware.com writes:
- Original Message -
From: Richard Sandiford r.sandif...@uk.ibm.com
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
- Original Message -
From: Richard Sandiford r.sandif...@uk.ibm.com
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,
From: Richard Sandiford r.sandif...@uk.ibm.com
RGBA has R at byte 0 and A at byte 3, regardless of platform
endianness.
Reviewed-by: Adam Jackson a...@redhat.com
---
src/gallium/include/pipe/p_format.h | 38 +
1 file changed, 30 insertions(+), 8
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 a...@redhat.com wrote:
From: Richard Sandiford r.sandif...@uk.ibm.com
RGBA has R at byte 0 and A at byte 3, regardless of
27 matches
Mail list logo
