Roland Scheidegger writes:
> Am 22.07.2014 12:26, schrieb Richard Sandiford:
>> Roland Scheidegger writes:
>>> Am 21.07.2014 17:53, schrieb Richard Sandiford:
>>>> lp_build_iround has a fallback case that tries to emulate a
>>>> round-to-nearest
&g
Roland Scheidegger writes:
> Am 21.07.2014 17:53, schrieb Richard Sandiford:
>> lp_build_iround has a fallback case that tries to emulate a round-to-nearest
>> float->int conversion by adding 0.5 and using a truncating fptosi. For odd
>> numbers in the range [2^23,
't too onerous
since both orders are already handled.
Signed-off-by: Richard Sandiford
---
src/mesa/main/texstore.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index ae52bd3..22fc1e2 100644
--- a/src/mesa/main/
The function was using the "X" component as the alpha channel,
rather than setting alpha to 1.0.
Signed-off-by: Richard Sandiford
---
src/mesa/main/format_unpack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/forma
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already exist.
Signed-off-by: Richard Sandiford
---
src/gallium/include/pipe/p_format.h | 24
1 file changed, 24 insertions(+)
diff
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c
This means that each RnGnBnxn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
The associated UNORM and SRGB formats already exist.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format.csv | 3 +++
src/gallium/i
> Similar to the L/A and R/G series I just posted, this one fixes the SNORM
> and SRGB formats. The UNORM ones were done last year as part of the
> original big-endian work.
v2, with subject lines fixed to include the "component:" bit. No code changes
from v1.
R
MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM
while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB.
This patch renames the SNORM function to have the same order as the
MESA_FORMAT name, like the SRGB function does.
Signed-off-by: Richard Sandiford
MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of
the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw.
PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory.
This patch fixes up the mesa<->gallium mapping accordingly.
Signed-off-by: R
...i.e. formats in which the first listed component is in the least
significant half of the integer.
Signed-off-by: Richard Sandiford
---
src/gallium/include/pipe/p_format.h | 32
1 file changed, 32 insertions(+)
diff --git a/src/gallium/include/pipe/p_format.h
...i.e. formats in which the alpha or green channel is first in memory.
This means that each LnAn and RnGn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format.cs
MESA_FORMAT_LnAn puts the luminance in the least significant part of
the containing integer, which is equivalent to PIPE_FORMAT_LAnn.
PIPE_FORMAT_LnAn puts the luminance first in memory.
This patch fixes up the mesa<->gallium mapping accordingly.
Signed-off-by: Richard Sandiford
---
sr
B.
> AFAICT all other L/A and R/G formats are handled correctly.
v2, with subject lines fixed to include the "component:" bit. No code changes
from v1.
Richard Sandiford (5):
swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endian
util: Add PIPE_FORMAT_AnLn and PIPE_FORMAT_GnR
Luminance is the least-significant byte of the uint16, rather than the
lowest byte in memory. Other parts of mesa already handle this correctly
for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats
correctly. This case was just an odd-one-out.
Signed-off-by: Richard
The associated UNORM format already existed.
This means that each LnAn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
src/mes
Marek Olšák writes:
> Hi Richard,
>
> For anything that changes the shared core code in src/gallium, the
> commit message prefix should be "gallium:". You can also use
> "gallium/util:" if you just change auxiliary/util.
>
> For anything that changes src/mesa/state_tracker, the prefix should be
>
---
src/gallium/auxiliary/util/u_format.csv | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index b68f6c2..1cd4954 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/aux
...fixing the associated TODO.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 34 -
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/src/gallium/auxiliary/gallivm
tch only uses the x+0.5 trick if the ulp of the input is fractional.
This still doesn't give ties-to-even semantics, but that doesn't seem to
matter much in practice.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 43 ++---
1 fil
Fallback cases in lp_bld_arit.c used 2^24 to mean "2 to the power 24",
but in C it's "2 xor 24", i.e. 26. Fixed by using 1<< instead.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 8
1 file changed, 4 insertions(+), 4
The pack64 routines were hardwired for little-endian layout.
On big-endian, loading a PIPE_FORMAT_Z32_FLOAT_S8X24_UINT
as a 64-bit integer puts the depth float in the high 32 bits
and the stencil in the low 8 bits, like for the associated
MESA_FORMAT_*.
Signed-off-by: Richard Sandiford
---
src
its;
The format_desc describes the whole 64-bit block, so the z shift
will be 32 for big-endian. But since we're accessing the z channel
as a 32-bit value rather than a 64-bit value, we need to mask the shift
with 31.
Signed-off-by: Richard Sandiford
---
src/gallium/drivers/llvmpipe/lp_bld_dept
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already exist.
---
src/gallium/include/pipe/p_format.h | 24
1 file changed, 24 insertions(+)
diff --git a/src/gallium/include/pipe/p_form
MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM
while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB.
This patch renames the SNORM function to have the same order as the
MESA_FORMAT name, like the SRGB function does.
---
src/mesa/main/format_unpack.c
The function was using the "X" component as the alpha channel,
rather than setting alpha to 1.0.
---
src/mesa/main/format_unpack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index ae14478..fddb067 100644
--- a/s
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c | 60 +
src/mesa/main/format_unp
MESA_FORMAT_x8y8z8w8 means a format in which "x" is the least
signficant byte and "w" is the most significant byte. Most
functions get that right, but the signed ones access the
bytes from an array rather than an integer, so they need
to take endianness into account. This isn't too onerous
since
This means that each RnGnBnxn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
The associated UNORM and SRGB formats already exist.
---
src/gallium/auxiliary/util/u_format.csv | 3 +++
src/gallium/include/pipe/p_format.h | 3 +++
2 files ch
Similar to the L/A and R/G series I just posted, this one fixes the SNORM
and SRGB formats. The UNORM ones were done last year as part of the
original big-endian work.
Richard Sandiford (7):
util: Add PIPE_FORMAT_x8B8G8R8_SNORM formats
util: Define PIPE_FORMAT_xyzw_{SNORM,SRGB
MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of
the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw.
PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory.
This patch fixes up the mesa<->gallium mapping accordingly.
---
src/mesa/state_tracker/st_f
...i.e. formats in which the alpha or green channel is first in memory.
This means that each LnAn and RnGn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
---
src/gallium/auxiliary/util/u_format.csv | 9 +
src/gallium/include/pipe/p_
The associated UNORM format already existed.
This means that each LnAn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
src/mesa/main/format_pack.c | 37 +
MESA_FORMAT_LnAn puts the luminance in the least significant part of
the containing integer, which is equivalent to PIPE_FORMAT_LAnn.
PIPE_FORMAT_LnAn puts the luminance first in memory.
This patch fixes up the mesa<->gallium mapping accordingly.
---
src/mesa/state_tracker/st_format.c | 64 ++
Luminance is the least-significant byte of the uint16, rather than the
lowest byte in memory. Other parts of mesa already handle this correctly
for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats
correctly. This case was just an odd-one-out.
---
src/mesa/swrast/s_texfetch_t
correctly.
Richard Sandiford (5):
swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endian
util: Add PIPE_FORMAT_AnLn and PIPE_FORMAT_GnRn formats
util: Define PIPE_FORMAT_{LA,AL,RG,GR}nn aliases
Add MESA_FORMAT_A8L8_{SNORM,SRGB}
Fix handling of LA and RG formats for big-endian
src
...i.e. formats in which the first listed component is in the least
significant half of the integer.
---
src/gallium/include/pipe/p_format.h | 32
1 file changed, 32 insertions(+)
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_forma
---
src/gallium/auxiliary/util/u_format.csv | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index c43210e..b68f6c2 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary
---
src/gallium/auxiliary/util/u_format.csv | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index c596de9..834b08b 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/galliu
This series adds a way of specifying a separate big-endian layout in
u_format.csv and uses it for the formats where the layout depends on
endianness.
Richard Sandiford (6):
util: Add big-endian layout for depth/stencil formats
util: Add big-endian layout for 5551 and 565 formats
util: Add
---
src/gallium/auxiliary/util/u_format.csv | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index 834b08b..1dec8ce 100644
--- a/src/gallium/auxiliary/util/u_format.
---
src/gallium/auxiliary/util/u_format.csv | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index 1dec8ce..c43210e 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxil
This patch builds on 6c8f547f66e68b495c708f8ffcb67370caa5ffe8 and
previous patches by allowing u_format.csv to specify separate big-endian
and little-endian layouts. It then uses this to specify the correct layouts
for various depth/stencil formats. Later patches handle other formats.
To recap,
Hi,
Sorry for the much longer than intended delay, but I've finally got back
to the big-endian stuff that Adam an I started last year. To recap,
the initial patches were enough to get a gnome desktop working on big-endian
PowerPC and System z, which was the initial goal, but due to time constrain
, but I failed to noticed the RFC to me.
>
> I glanced over it and the series looks good to me AFAICT. I agree that
> it is a better to defer the endianess to C-preprocessing time.
>
> Jose
>
> - Original Message -
>> Ping
>>
>> Richard Sandiford
Ping
Richard Sandiford writes:
> Ping (with fixed subject)
>
> Richard Sandiford writes:
>> This is a refresh of:
>>
>>http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html
>>
>> At the moment the python code uses sys.byteorder to decid
Ping
Richard Sandiford writes:
> Ping (with fixed subject)
>
> Richard Sandiford writes:
>> This is a refresh of:
>>
>>http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html
>>
>> At the moment the python code uses sys.byteorder to decid
Ping.
Richard Sandiford writes:
> Ping (with fixed subject)
>
> Richard Sandiford writes:
>> This is a refresh of:
>>
>>http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html
>>
>> At the moment the python code uses sys.byteorder to decid
Ping (with fixed subject)
Richard Sandiford writes:
> This is a refresh of:
>
>http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html
>
> At the moment the python code uses sys.byteorder to decide whether
> u_format_table.c should be for big or little endian.
The AoS version of ld_build_blend_factor was assuming that if the first
channel was alpha, there were no rgb components.
Fixes glean/blendFunc on System z. No piglit regressions on x86_64.
The shortcut is still used in tests like spec/ARB_framebuffer_object/
fbo-alpha.
Signed-off-by: Richard
Rather than iterate over format.channels and format.swizzles directly,
use Python subfunctions that take the channel and swizzle lists as
arguments. This allow the channel and swizzle lists to depend on
endianness.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard
With the big-endian changes, there can be two swizzle orders for each format.
This patch turns Format.inv_swizzle() into a global function that takes the
swizzle list as a parameter.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium
Splits out the code that parses the channel list, so that we
can have different lists for little and big endian.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format_parse.py | 96 +++-
1 file
-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format_pack.py | 13 --
src/gallium/auxiliary/util/u_format_parse.py | 65 +++-
2 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format_pack.py
b/src/gallium
The main aim is to reduce the number of places that access channels[0],
swizzles[0] and swizzles[1] directly.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format_pack.py | 27 ++-
src/gallium/auxiliary/util
This is a refresh of:
http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html
At the moment the python code uses sys.byteorder to decide whether
u_format_table.c should be for big or little endian. With this series
it instead generates both forms, using blocks like:
#ifdef PIPE_
Michel Dänzer writes:
> On Die, 2014-03-11 at 11:08 +0000, Richard Sandiford wrote:
>> Michel Dänzer writes:
>> > On Mon, 2014-03-10 at 10:11 +0100, Christian Zigotzky wrote:
>> >>
>> >> The Fedora guys have solved the problem with the patch
>>
Christian Zigotzky writes:
> Am 11.03.14 12:08, schrieb Richard Sandiford:
>> Michel Dänzer writes:
>>> On Mon, 2014-03-10 at 10:11 +0100, Christian Zigotzky wrote:
>>>> On 10.03.2014 02:49, Michel Dänzer wrote:
>>>>> Congratulations, you ju
the patch
>> "mesa-9.2-llvmpipe-on-big-endian.patch". What do you think of this patch?
>
> It sounds like an older downstream attempt at fixing llvmpipe on big
> endian hosts, which was superseded by the upstream fixes, which were
> incidentally pushed by the 'Fedor
swrastGetImage rounds the pitch up to 4 bytes for compatibility reasons
that are explained in drisw_glx.c:bytes_per_line, so drisw_update_tex_buffer
must do the same.
Fixes window skew seen while running firefox over vnc on a 16-bit screen.
Signed-off-by: Richard Sandiford
---
src/gallium
: Richard Sandiford
---
src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c
b/src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c
index c4d04a2..7c485e7 100644
--- a/src/gallium/drivers/llvmpipe
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
Will Schmidt writes:
> On Thu, 2013-06-13 at 14:50 +0100, Richard Sandiford wrote:
>>
>
> The entirety of the comment looks pretty good to me. :-) One
> question, and this is mostly curiosity on my part, I'm not specifically
> asking for another revision.
>
&g
Fixes window skew seen while running gnome on a 16-bit screen over vnc.
Signed-off-by: Richard Sandiford
---
src/gallium/state_trackers/glx/xlib/xm_api.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c
b/src/gallium
Fixes a crash seen while running gnome on a 16-bit screen over vnc.
Signed-off-by: Richard Sandiford
---
src/gallium/state_trackers/glx/xlib/xm_api.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c
b/src/gallium
Michel Dänzer writes:
> On Die, 2013-06-11 at 16:26 +0100, Richard Sandiford wrote:
>> Signed-off-by: Richard Sandiford
>> ---
>> src/gallium/auxiliary/util/u_format.h | 42
>> ++-
>> 1 file changed, 41 insertions(+), 1 de
With the big-endian changes, there can be two swizzle orders for each format.
This patch turns Format.inv_swizzle() into a global function that takes the
swizzle list as a parameter.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format.h | 42 ++-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index e4b9c36..db6c290 100644
--- a
The new field eats up all the remaining bits of the bitfield,
but it could easily be shrunk in future.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format.h| 1 +
src/gallium/auxiliary/util/u_format_table.py | 4 ++--
2 files changed, 3 insertions(+), 2 deletions
iffer. This will change
as more formats are "fixed" for big endian.
No piglit regressions on x86_64. This patch on its own doesn't
help the results much on big-endian, but it's needed by later
patches that do.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/ut
Store the shift value for a bitmask channel in the Channel object,
rather than working it out on the fly. This allows the shift to
depend on endianness.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format_pack.py | 8
Splits out the code that parses the channel list, so that we
can have different lists for little and big endian.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format_parse.py | 96 +++-
1 file
Rather than iterate over format.channels and format.swizzles directly,
use Python subfunctions that take the channel and swizzle lists as
arguments. This allow the channel and swizzle lists to depend on
endianness.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard
The main aim is to reduce the number of places that access channels[0],
swizzles[0] and swizzles[1] directly.
There is no change to the generated u_format_table.c.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format_pack.py | 27 ++-
src/gallium/auxiliary/util
it fixes glxgears on System z. It also fixes many
piglit tests.
No piglit regressions on x86_64.
Thanks,
Richard
commit 40dca05874d21afdb62a03f593e256f93e988ac0
Author: Richard Sandiford
Date: Wed Jun 12 10:14:48 2013 +0100
util: Fix stencil and depth formats for big endian
diff --git a/s
as
spec/ARB_color_buffer_float/GL_RGBA8-render.
The patch deliberately doesn't tackle the more complicated
SNORM case.
Tested against piglit on x86_64 and System z with no regressions.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 8
1 file ch
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
>>>> mes
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 thou
Without this, llvmpipe ends up giving a zero size to all uncompressed textures
on non-x86 systems, since align() cannot handle a 0 alignment.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_cpu_detect.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium
for 0.
>>
>> Signed-off-by: Richard Sandiford
>> ---
>> src/gallium/auxiliary/util/u_cpu_detect.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/src/gallium/auxiliary/util/u_cpu_detect.c
>> b/src/gallium/auxiliary/util/u_cpu_de
Without this, llvmpipe ends up giving a zero size to all uncompressed textures
on non-x86 systems, since align() cannot handle a 0 alignment. Making the
default 1 seemed preferable to adding checks for 0.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_cpu_detect.c | 5
The main change is to use MCJIT rather than the old JIT, which will never
be supported for System z. The endianness part is by example since the
patch was tested on a glibc system.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 2 +-
src/gallium/include/pipe
btw, please ignore the 20/20 in the subject line :-) The patch was
tested in isolation and there aren't 19 other patches to come.
Richard
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
been to try to get the LLVM code to use the equivalent of
size_t too. However, in practice, the size is taken from things like ~0
or width0, both of which are int-sized, so it seemed simpler to make the
size field int-sized as well.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/draw
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
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
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
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 conventi
88 matches
Mail list logo
