On Wed, Mar 27, 2013 at 4:45 AM, Christian König
wrote:
> Am 27.03.2013 01:43, schrieb Jerome Glisse:
>
>> On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie wrote:
>>
>> correctly). But Marek is quite right that this only counts for state
>> objects
>> and makes no sense for set_* and
Am 27.03.2013 01:43, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie wrote:
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense for set_* and draw_* calls (and I'm currently thinking
how to avoid that and can't come up with a prope
Am 27.03.2013 00:30, schrieb Dave Airlie:
On 27 Mar 2013 08:45, "Dave Airlie" wrote:
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense for set_* and draw_* calls (and I'm currently thinking
how to avoid that and can't come up with a proper solution)
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie wrote:
>>
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense for set_* and draw_* calls (and I'm currently thinking
how to avoid that and can't come up with a proper solution). Anyway it's
On 27 Mar 2013 08:45, "Dave Airlie" wrote:
>
> >
> >>> correctly). But Marek is quite right that this only counts for state
> >>> objects
> >>> and makes no sense for set_* and draw_* calls (and I'm currently thinking
> >>> how to avoid that and can't come up with a proper solution). Anyway it's
>
>
>>> correctly). But Marek is quite right that this only counts for state
>>> objects
>>> and makes no sense for set_* and draw_* calls (and I'm currently thinking
>>> how to avoid that and can't come up with a proper solution). Anyway it's
>>> definitely not an urgent problem for radeonsi.
>>
>>
Am 26.03.2013 20:28, schrieb Marek Olšák:
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
wrote:
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
wrote:
Am 26.03.2013 15:34, schrieb Marek Olš
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
wrote:
> Am 26.03.2013 18:02, schrieb Jerome Glisse:
>
>> On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
>>>
>>> On Tue, Mar 26, 2013 at 3:59 PM, Christian König
>>> wrote:
Am 26.03.2013 15:34, schrieb Marek Olšák:
> Speak
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
wrote:
Am 26.03.2013 15:34, schrieb Marek Olšák:
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant sta
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
> On Tue, Mar 26, 2013 at 3:59 PM, Christian König
> wrote:
>> Am 26.03.2013 15:34, schrieb Marek Olšák:
>>
>>> Speaking of si_pm4_state, I think it's a horrible mechanism for
>>> anything other than constant state objects (create/bind/delete
>
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
wrote:
> Am 26.03.2013 15:34, schrieb Marek Olšák:
>
>> Speaking of si_pm4_state, I think it's a horrible mechanism for
>> anything other than constant state objects (create/bind/delete
>> functions). For everything else (set/draw functions), you wa
Am 26.03.2013 15:34, schrieb Marek Olšák:
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant state objects (create/bind/delete
functions). For everything else (set/draw functions), you want to emit
directly into the command stream. It's not so different f
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant state objects (create/bind/delete
functions). For everything else (set/draw functions), you want to emit
directly into the command stream. It's not so different from the bad
state management which r600g use
Am 26.03.2013 14:42, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 6:22 AM, Christian König
wrote:
Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command
On Tue, Mar 26, 2013 at 6:22 AM, Christian König
wrote:
> Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
>
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside command stream and
>> narrow down the sco
Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command stream and
narrow down the scope of lockup investigation.
v2: Use WRITE_DATA packet instead of WRITE_M
On Mon, Mar 25, 2013 at 1:12 PM, Christian König
wrote:
> Am 25.03.2013 17:50, schrieb Jerome Glisse:
>
>> On Mon, Mar 25, 2013 at 12:38 PM, Christian König
>> wrote:
>>>
>>> Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
>>>
From: Jerome Glisse
Same as on r600, trace cs executi
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command stream and
narrow down the scope of lockup investigation.
v2: Use WRITE_DATA packet instead of WRITE_MEM
Signed-off-by: Jerome Glisse
---
src/gallium/
Am 25.03.2013 17:50, schrieb Jerome Glisse:
On Mon, Mar 25, 2013 at 12:38 PM, Christian König
wrote:
Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside comman
On Mon, Mar 25, 2013 at 12:38 PM, Christian König
wrote:
> Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
>
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside command stream and
>> narrow down the sc
Am 25.03.2013 17:01, schrieb j.gli...@gmail.com:
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command stream and
narrow down the scope of lockup investigation.
Signed-off-by: Jerome Glisse
Could your r
On Mon, Mar 25, 2013 at 12:01 PM, wrote:
> From: Jerome Glisse
>
> Same as on r600, trace cs execution by writting cs offset after each
> states, this allow to pin point lockup inside command stream and
> narrow down the scope of lockup investigation.
>
> Signed-off-by: Jerome Glisse
> ---
> s
On Mon, Mar 25, 2013 at 12:17 PM, Michel Dänzer wrote:
> On Mon, 2013-03-25 at 12:01 -0400, j.gli...@gmail.com wrote:
>> From: Jerome Glisse
>>
>> Same as on r600, trace cs execution by writting cs offset after each
>> states, this allow to pin point lockup inside command stream and
>> narrow dow
On Mon, 2013-03-25 at 12:01 -0400, j.gli...@gmail.com wrote:
> From: Jerome Glisse
>
> Same as on r600, trace cs execution by writting cs offset after each
> states, this allow to pin point lockup inside command stream and
> narrow down the scope of lockup investigation.
>
> Signed-off-by: Jero
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command stream and
narrow down the scope of lockup investigation.
Signed-off-by: Jerome Glisse
---
src/gallium/drivers/radeonsi/r600_hw_context.c | 58
25 matches
Mail list logo