On Wed, Mar 27, 2013 at 4:45 AM, Christian König
deathsim...@vodafone.de wrote:
Am 27.03.2013 01:43, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie airl...@gmail.com wrote:
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense
Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
From: Jerome Glisse jgli...@redhat.com
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
Am 26.03.2013 14:42, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 6:22 AM, Christian König
deathsim...@vodafone.de wrote:
Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
From: Jerome Glisse jgli...@redhat.com
Same as on r600, trace cs execution by writting cs offset after each
states,
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
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
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de 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
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de 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
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013
Am 26.03.2013 20:28, schrieb Marek Olšák:
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
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.
It will be a
On 27 Mar 2013 08:45, Dave Airlie airl...@gmail.com 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 Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie airl...@gmail.com 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
12 matches
Mail list logo
