On Wed, Apr 20, 2016 at 12:35 PM, Marek Olšák wrote:
> On Wed, Apr 20, 2016 at 11:14 AM, Oded Gabbay wrote:
>> On Wed, Apr 20, 2016 at 12:04 PM, Michel Dänzer wrote:
>>> On 20.04.2016 17:48, Oded Gabbay wrote:
On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote:
> On 20.04.2016 03:13
On Wed, Apr 20, 2016 at 11:14 AM, Oded Gabbay wrote:
> On Wed, Apr 20, 2016 at 12:04 PM, Michel Dänzer wrote:
>> On 20.04.2016 17:48, Oded Gabbay wrote:
>>> On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote:
On 20.04.2016 03:13, Oded Gabbay wrote:
> On Tue, Apr 19, 2016 at 5:59 PM,
On Wed, Apr 20, 2016 at 12:04 PM, Michel Dänzer wrote:
> On 20.04.2016 17:48, Oded Gabbay wrote:
>> On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote:
>>> On 20.04.2016 03:13, Oded Gabbay wrote:
On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote:
> On Tue, Apr 19, 2016 at 3:11 PM, O
On 20.04.2016 17:48, Oded Gabbay wrote:
> On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote:
>> On 20.04.2016 03:13, Oded Gabbay wrote:
>>> On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote:
On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay wrote:
> On Mon, Apr 18, 2016 at 6:03 PM,
On Wed, Apr 20, 2016 at 11:28 AM, Michel Dänzer wrote:
> On 20.04.2016 03:13, Oded Gabbay wrote:
>> On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote:
>>> On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay wrote:
On Mon, Apr 18, 2016 at 6:03 PM,
Ilia Mirkin wrote:
> On Mon, Apr 18, 201
On 20.04.2016 03:13, Oded Gabbay wrote:
> On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote:
>> On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay wrote:
>>> On Mon, Apr 18, 2016 at 6:03 PM,
>>> Ilia Mirkin wrote:
On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay
wrote:
> On Thu, Apr 14,
On Tue, Apr 19, 2016 at 5:59 PM, Marek Olšák wrote:
> On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay wrote:
>> On Mon, Apr 18, 2016 at 6:03 PM,
>> Ilia Mirkin wrote:
>>> On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote:
On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
> On Thu, Ap
On Tue, Apr 19, 2016 at 3:11 PM, Oded Gabbay wrote:
> On Mon, Apr 18, 2016 at 6:03 PM,
> Ilia Mirkin wrote:
>> On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote:
>>> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay
wrote:
>> Wou
On Mon, Apr 18, 2016 at 6:03 PM,
Ilia Mirkin wrote:
> On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote:
>> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
>>> On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay wrote:
> Wouldn't it make more sense to handle such issues in transfer_map?
>>>
On Tue, Apr 19, 2016 at 9:10 AM, Michel Dänzer wrote:
> On 19.04.2016 00:03, Ilia Mirkin wrote:
>> On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote:
>>> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
>>>
>>> To make the GPU do a conversion during blitting, I need to configure
>>> registe
On Mon, Apr 18, 2016 at 5:38 PM, Marek Olšák wrote:
> Packed formats are the only formats that need byte-swapping between
> components. The only gallium packed formats are:
> - 10_10_10_2
> - 5_5_5_1
> - 5_6_5
> - 4_4_4_4
> - 3_3_2
> - 24_8
> - 8_24
> - 32_8_24 (not sure
> - 11_11_10
> - 5_5_5_9
>
On 19.04.2016 00:03, Ilia Mirkin wrote:
> On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote:
>> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
>>
>> To make the GPU do a conversion during blitting, I need to configure
>> registers. This is done in a couple of functions in the r600g driver
On Mon, Apr 18, 2016 at 5:03 PM, Ilia Mirkin wrote:
> On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote:
>> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
>>> On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay wrote:
> Wouldn't it make more sense to handle such issues in transfer_map?
>>>
On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote:
> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
>> On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay wrote:
Wouldn't it make more sense to handle such issues in transfer_map?
(i.e. create a staging memory area, and decode into it)?
On Mon, Apr 18, 2016 at 10:47 AM, Oded Gabbay wrote:
> On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
>> On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay wrote:
Wouldn't it make more sense to handle such issues in transfer_map?
(i.e. create a staging memory area, and decode into it)?
On Thu, Apr 14, 2016 at 6:44 PM, Ilia Mirkin wrote:
> On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay wrote:
>>> Wouldn't it make more sense to handle such issues in transfer_map?
>>> (i.e. create a staging memory area, and decode into it)? This assumes
>>> that the transfer_map() call has enough i
On Fri, Apr 15, 2016 at 2:35 AM, Ilia Mirkin wrote:
> On Thu, Apr 14, 2016 at 7:26 PM, Roland Scheidegger
> wrote:
>> Am 14.04.2016 um 14:18 schrieb Oded Gabbay:
>>> This patch adds a new field, called "endian_format", to
>>> "struct pipe_resource". The new field is of type "enum pipe_endian" an
On Thu, Apr 14, 2016 at 7:26 PM, Roland Scheidegger wrote:
> Am 14.04.2016 um 14:18 schrieb Oded Gabbay:
>> This patch adds a new field, called "endian_format", to
>> "struct pipe_resource". The new field is of type "enum pipe_endian" and
>> can receive one of two values:
>> - PIPE_ENDIAN_LITTLE
>
Am 14.04.2016 um 14:18 schrieb Oded Gabbay:
> This patch adds a new field, called "endian_format", to
> "struct pipe_resource". The new field is of type "enum pipe_endian" and
> can receive one of two values:
> - PIPE_ENDIAN_LITTLE
> - PIPE_ENDIAN_NATIVE
>
> PIPE_ENDIAN_NATIVE is initialized to ei
On Thu, Apr 14, 2016 at 11:08 AM, Oded Gabbay wrote:
>> Wouldn't it make more sense to handle such issues in transfer_map?
>> (i.e. create a staging memory area, and decode into it)? This assumes
>> that the transfer_map() call has enough information to "do the right
>> thing". I don't think it do
On Thu, Apr 14, 2016 at 5:47 PM, Ilia Mirkin wrote:
> On Thu, Apr 14, 2016 at 10:34 AM, Oded Gabbay wrote:
>> On Thu, Apr 14, 2016 at 5:01 PM, Ilia Mirkin wrote:
>>> This feels like an incredibly confused interface to me...
>> I agree it's not the prettiest design I made, but considering
>> big-
On Thu, Apr 14, 2016 at 10:34 AM, Oded Gabbay wrote:
> On Thu, Apr 14, 2016 at 5:01 PM, Ilia Mirkin wrote:
>> This feels like an incredibly confused interface to me...
> I agree it's not the prettiest design I made, but considering
> big-endian is a class F citizen, then that's the best I got rig
On Thu, Apr 14, 2016 at 5:01 PM, Ilia Mirkin wrote:
> This feels like an incredibly confused interface to me...
I agree it's not the prettiest design I made, but considering
big-endian is a class F citizen, then that's the best I got right now.
I'm open to suggestions, but please guys don't tell m
This feels like an incredibly confused interface to me... you talk
about CPU <-> GPU, but I think that's a misnomer. What happens if you
use up too much VRAM and something gets evicted to GART? Does it get
byteswapped to the CPU-endianness? Are you treating everything as
32-bit packed integers impl
This patch adds a new field, called "endian_format", to
"struct pipe_resource". The new field is of type "enum pipe_endian" and
can receive one of two values:
- PIPE_ENDIAN_LITTLE
- PIPE_ENDIAN_NATIVE
PIPE_ENDIAN_NATIVE is initialized to either PIPE_ENDIAN_LITTLE or
PIPE_ENDIAN_BIG during build ti
25 matches
Mail list logo
