http://bugs.freedesktop.org/show_bug.cgi?id=13299
Summary: Mesa 7.0.1 implementation error: i915_program_error:
Exceeded max ALU instructions
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Hi,
I think i found a dead lock in the code:
in drm_bo_move.c:drm_buffer_object_transfer the dev-struct_mutex is taken
while this mutex is take there is a call to
drm_fence.c:drm_fence_reference_unlocked
and the function try to acquire dev-struct_mutex lock so deadlock i believe
that
Jerome Glisse wrote:
Hi,
I think i found a dead lock in the code:
in drm_bo_move.c:drm_buffer_object_transfer the dev-struct_mutex is taken
while this mutex is take there is a call to
drm_fence.c:drm_fence_reference_unlocked
and the function try to acquire dev-struct_mutex lock so deadlock
Thomas Hellström wrote:
Jerome Glisse wrote:
Hi,
I think i found a dead lock in the code:
in drm_bo_move.c:drm_buffer_object_transfer the dev-struct_mutex is
taken
while this mutex is take there is a call to
drm_fence.c:drm_fence_reference_unlocked
and the function try to acquire
Thomas Hellström wrote:
Jerome Glisse wrote:
Hi,
If my driver emit fence function fail should there be a way
to clean unfenced buffer ? Or should i do this by myself in
the function which validate buffer ? If so then i915 execbuffer
is likely buggy in this regards (don't try to unload
Jerome Glisse wrote:
Thomas Hellström wrote:
Jerome Glisse wrote:
Hi,
If my driver emit fence function fail should there be a way
to clean unfenced buffer ? Or should i do this by myself in
the function which validate buffer ? If so then i915 execbuffer
is likely buggy in this regards
Hi all,
While playing with modesetting ttm i have put some thought on how we send
things to card. And i would like to test the following scheme:
-split card state into a bunch of separate chunk (z state, fog state, ...)
-the driver build the state it want and register each state chunk to the drm
Jerome Glisse wrote:
Hi,
So while playing with buffer move i am facing a problem and
would like to know if anyone ever faced it. I emitting a bitblt
multi to move data from ttm to vram just after the bitblt multi
there is a WAIT_UNTIL packet emitted with WAIT_2D_IDLECLEAN,
Keith Whitwell wrote:
Jerome Glisse wrote:
Hi all,
While playing with modesetting ttm i have put some thought on how
we send
things to card. And i would like to test the following scheme:
-split card state into a bunch of separate chunk (z state, fog state,
...)
-the driver build the
Roland Scheidegger wrote:
Jerome Glisse wrote:
Hi,
So while playing with buffer move i am facing a problem and
would like to know if anyone ever faced it. I emitting a bitblt
multi to move data from ttm to vram just after the bitblt multi
there is a WAIT_UNTIL packet emitted with
What are the prospects of the DRM TTM changes making it into 2.6.24? I noticed
that Andrew has them [1] in his mm tree... any chance of that getting pushed
into Linus' tree for 2.6.24?
Cheers,
Waldo
[1] http://userweb.kernel.org/~akpm/mmotm/broken-out/git-drm.patch
Intel Corporation -
What are the prospects of the DRM TTM changes making it into 2.6.24? I
noticed that Andrew has them [1] in his mm tree... any chance of that
getting pushed into Linus' tree for 2.6.24?
No the merge window for 2.6.24 closed a few weeks ago. TTM wasn't in -mm
for the 2.6.23 cycle as we
On Mon, 19 Nov 2007 21:53:05 + (GMT)
Dave Airlie [EMAIL PROTECTED] wrote:
What are the prospects of the DRM TTM changes making it into 2.6.24? I
noticed that Andrew has them [1] in his mm tree... any chance of that
getting pushed into Linus' tree for 2.6.24?
No the merge
http://bugs.freedesktop.org/show_bug.cgi?id=13080
--- Comment #23 from [EMAIL PROTECTED] 2007-11-19 18:05 PST ---
Created an attachment (id=12634)
-- (http://bugs.freedesktop.org/attachment.cgi?id=12634action=view)
simple zreaddraw hack
interesting though I can't see much
http://bugs.freedesktop.org/show_bug.cgi?id=13080
--- Comment #24 from [EMAIL PROTECTED] 2007-11-19 18:32 PST ---
Created an attachment (id=12635)
-- (http://bugs.freedesktop.org/attachment.cgi?id=12635action=view)
ddx patch to really disable depth surface setup
Oh, and could you
15 matches
Mail list logo
