On 10.08.2015 21:48, Oded Gabbay wrote:
>
> I believe the deeper problem is from the fact we move from gallium
> format name x8y8z8w8, which doesn't take into account platform
> endianness, to mesa format name, which does take platform endianness
> into account (using the swizzle).
That should on
Am 10.08.2015 um 07:00 schrieb Jason Ekstrand:
> On Sun, Aug 9, 2015 at 6:46 AM, Roland Scheidegger wrote:
>> Am 09.08.2015 um 12:11 schrieb Oded Gabbay:
>>> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
> On Sun, Aug 9, 2015 at
On Mon, Aug 10, 2015 at 10:43 AM, Jason Ekstrand wrote:
> On Mon, Aug 10, 2015 at 12:41 AM, Oded Gabbay wrote:
>> On Mon, Aug 10, 2015 at 10:30 AM, Jason Ekstrand
>> wrote:
>>> On Mon, Aug 10, 2015 at 12:07 AM, Oded Gabbay wrote:
On Mon, Aug 10, 2015 at 7:58 AM, Jason Ekstrand
wrot
On Mon, Aug 10, 2015 at 12:41 AM, Oded Gabbay wrote:
> On Mon, Aug 10, 2015 at 10:30 AM, Jason Ekstrand wrote:
>> On Mon, Aug 10, 2015 at 12:07 AM, Oded Gabbay wrote:
>>> On Mon, Aug 10, 2015 at 7:58 AM, Jason Ekstrand
>>> wrote:
On Sun, Aug 9, 2015 at 3:11 AM, Oded Gabbay wrote:
> O
On Mon, Aug 10, 2015 at 10:30 AM, Jason Ekstrand wrote:
> On Mon, Aug 10, 2015 at 12:07 AM, Oded Gabbay wrote:
>> On Mon, Aug 10, 2015 at 7:58 AM, Jason Ekstrand wrote:
>>> On Sun, Aug 9, 2015 at 3:11 AM, Oded Gabbay wrote:
On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand
wrote:
>
On Mon, Aug 10, 2015 at 12:07 AM, Oded Gabbay wrote:
> On Mon, Aug 10, 2015 at 7:58 AM, Jason Ekstrand wrote:
>> On Sun, Aug 9, 2015 at 3:11 AM, Oded Gabbay wrote:
>>> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
> On Sun, Au
On Mon, Aug 10, 2015 at 7:58 AM, Jason Ekstrand wrote:
> On Sun, Aug 9, 2015 at 3:11 AM, Oded Gabbay wrote:
>> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand
wrote:
>>>
On Sun, Aug 9, 2015 at 6:46 AM, Roland Scheidegger wrote:
> Am 09.08.2015 um 12:11 schrieb Oded Gabbay:
>> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand
wrote:
If
On Sun, Aug 9, 2015 at 3:11 AM, Oded Gabbay wrote:
> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
>>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand
>>> wrote:
>>>
>>> If I understand your patch, instead of using the endian-depend
Am 09.08.2015 um 12:11 schrieb Oded Gabbay:
> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
>>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand
>>> wrote:
>>>
>>> If I understand your patch, instead of using the endian-dependent
>>>
On Sun, Aug 9, 2015 at 12:14 PM, Oded Gabbay wrote:
> On Sun, Aug 9, 2015 at 12:56 PM, Marek Olšák wrote:
>> He was probably talking about the gallium swrast (softpipe/llvmpipe).
>> I don't know of anybody using classic swrast (except classic drivers
>> as software fallback).
>>
>> All Gallium fo
On Sun, Aug 9, 2015 at 12:56 PM, Marek Olšák wrote:
> He was probably talking about the gallium swrast (softpipe/llvmpipe).
> I don't know of anybody using classic swrast (except classic drivers
> as software fallback).
>
> All Gallium formats are array-based except those which can't be arrays
> l
On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand wrote:
>>
>> If I understand your patch, instead of using the endian-dependent
>> defines, you use the LE defines all the time when conver
He was probably talking about the gallium swrast (softpipe/llvmpipe).
I don't know of anybody using classic swrast (except classic drivers
as software fallback).
All Gallium formats are array-based except those which can't be arrays
like 332, 565, 5551, , 10_10_10_2, 11_11_10, 24_8, 8_24, 32_8
On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand wrote:
>> On Sat, Aug 8, 2015 at 2:14 PM, Roland Scheidegger
>> wrote:
>>> Am 08.08.2015 um 22:45 schrieb Jason Ekstrand:
Mesa formats and gallium formats are defined a bit differently. In
On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand wrote:
> On Sat, Aug 8, 2015 at 2:14 PM, Roland Scheidegger wrote:
>> Am 08.08.2015 um 22:45 schrieb Jason Ekstrand:
>>> Mesa formats and gallium formats are defined a bit differently. In mesa
>>> there are "packed" formats which are based on byte-
Am 08.08.2015 um 23:26 schrieb Jason Ekstrand:
> On Sat, Aug 8, 2015 at 2:14 PM, Roland Scheidegger wrote:
>> Am 08.08.2015 um 22:45 schrieb Jason Ekstrand:
>>> Mesa formats and gallium formats are defined a bit differently. In mesa
>>> there are "packed" formats which are based on byte-order wit
On Sat, Aug 8, 2015 at 2:14 PM, Roland Scheidegger wrote:
> Am 08.08.2015 um 22:45 schrieb Jason Ekstrand:
>> Mesa formats and gallium formats are defined a bit differently. In mesa
>> there are "packed" formats which are based on byte-order within a 8, 16, or
>> 32-bit word and there are "array"
Am 08.08.2015 um 22:45 schrieb Jason Ekstrand:
> Mesa formats and gallium formats are defined a bit differently. In mesa
> there are "packed" formats which are based on byte-order within a 8, 16, or
> 32-bit word and there are "array" formats which are simply an array of 8,
> 16, or 32-bit values.
It's worth noting that this only fixes some of the more obvious
problems. For the formats that mesa defines as array formats, I think
things are still pretty broken.
This also brings into question how "worth it" it is having different
format enums. I personally prefer the way that mesa core has
Mesa formats and gallium formats are defined a bit differently. In mesa
there are "packed" formats which are based on byte-order within a 8, 16, or
32-bit word and there are "array" formats which are simply an array of 8,
16, or 32-bit values. In gallium, they do something different called
"plain
21 matches
Mail list logo