This commit replaces the ttm_bo_cleanup_ref function with two new functions.
One for the case where the bo is not yet on the delayed destroy list, and
one for the case where the bo was on the delayed destroy list, at least at
the time of call. This makes it possible to optimize the two cases
Release the lru spinlock early.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 30 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 10 --
include/drm/ttm/ttm_bo_driver.h |2 --
3 files changed, 5 insertions(+), 37
These patches attempt to optimize the delayed destroy handling.
The first patch removes the need for the newly introduced mem_put_locked
callback. The second patch optimizes the delayed buffer destruction somewhat,
but has not yet seen extensive testing.
So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
a name (with flink) we could endup with 2 handle pointing to the same
object (flink object and open it from same file descriptor). Would it be ok
if i change gem open to first look if we already have an handle for the
The enter argument as implemented by commit 413d45d3627 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.
There is no runtime behavior change as a result of this patch.
Reported-by: Jesse Barnes
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever
This reverts commit ff773714dd30b802c336064109c535d8b2774e2f.
A generic solution is needed to save and retore the LUT information.
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Jason Wessel
---
drivers/gpu/drm/radeon/radeon_display.c | 32
This patch series contains fixes against the original merge of the
atomic kernel mode setting for the radeon and nouveau drivers. The
first change is a revert of a prior patch that was radeon specific.
It turns out, as David Airlie suspected, that a generic solution is
needed for saving and
https://bugs.freedesktop.org/show_bug.cgi?id=30188
--- Comment #27 from Alex Deucher 2010-10-13 13:53:07 PDT
---
This patch, scheduled hopefully for 2.6.36 should also fix the issue:
Signed-off-by: Randy Dunlap
---
drivers/gpu/drm/Kconfig |2 +-
drivers/gpu/drm/nouveau/Kconfig |5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
--- linux-next-20101013.orig/drivers/gpu/drm/nouveau/Kconfig
+++ linux-next-20101013/drivers/gpu/drm/nouveau/Kconfig
@@ -1,16
https://bugs.freedesktop.org/show_bug.cgi?id=30694
Kevin DeKorte changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/r600
https://bugs.freedesktop.org/show_bug.cgi?id=30823
--- Comment #3 from Fabio Pedretti 2010-10-13 04:47:57
PDT ---
I can't see any difference between 7.9 and master (there are some minor
glitches on both however).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=30823
--- Comment #2 from Marek Ol??k 2010-10-13 04:03:37 PDT
---
Ignore that Bad param message, it's not important.
The other messages are weird, Wine should not ask for float textures if the
driver doesn't support them. Are there any rendering
https://bugs.freedesktop.org/show_bug.cgi?id=29244
--- Comment #7 from Fabio Pedretti 2010-10-13 01:43:48
PDT ---
(In reply to comment #6)
> I guess you guys are all running Mesa master. Could you please test the 7.9
> branch as well?
It's fixed in 7.9 branch and also runs better here. With
https://bugs.freedesktop.org/show_bug.cgi?id=30823
--- Comment #1 from Fabio Pedretti 2010-10-13 01:41:14
PDT ---
Created an attachment (id=39410)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39410)
wine output with mesa 7.9 branch
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=30823
Summary: r300: Implementation error: Bad param 40
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority:
https://bugs.freedesktop.org/show_bug.cgi?id=30823
--- Comment #1 from Fabio Pedretti fabio@libero.it 2010-10-13 01:41:14
PDT ---
Created an attachment (id=39410)
-- (https://bugs.freedesktop.org/attachment.cgi?id=39410)
wine output with mesa 7.9 branch
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=29244
--- Comment #7 from Fabio Pedretti fabio@libero.it 2010-10-13 01:43:48
PDT ---
(In reply to comment #6)
I guess you guys are all running Mesa master. Could you please test the 7.9
branch as well?
It's fixed in 7.9 branch and also runs
https://bugs.freedesktop.org/show_bug.cgi?id=30823
--- Comment #2 from Marek Olšák mar...@gmail.com 2010-10-13 04:03:37 PDT ---
Ignore that Bad param message, it's not important.
The other messages are weird, Wine should not ask for float textures if the
driver doesn't support them. Are there
https://bugs.freedesktop.org/show_bug.cgi?id=30823
--- Comment #3 from Fabio Pedretti fabio@libero.it 2010-10-13 04:47:57
PDT ---
I can't see any difference between 7.9 and master (there are some minor
glitches on both however).
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=30694
Kevin DeKorte kdeko...@yahoo.com changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/r600
These patches attempt to optimize the delayed destroy handling.
The first patch removes the need for the newly introduced mem_put_locked
callback. The second patch optimizes the delayed buffer destruction somewhat,
but has not yet seen extensive testing.
Release the lru spinlock early.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 30 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 10 --
include/drm/ttm/ttm_bo_driver.h |2 --
3 files changed, 5
This reverts commit ff773714dd30b802c336064109c535d8b2774e2f.
A generic solution is needed to save and retore the LUT information.
CC: Jesse Barnes jbar...@virtuousgeek.org
CC: David Airlie airl...@linux.ie
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Jason Wessel
This patch series contains fixes against the original merge of the
atomic kernel mode setting for the radeon and nouveau drivers. The
first change is a revert of a prior patch that was radeon specific.
It turns out, as David Airlie suspected, that a generic solution is
needed for saving and
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever
The enter argument as implemented by commit 413d45d3627 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.
There is no runtime behavior change as a result of this patch.
Reported-by: Jesse Barnes
, 4 insertions(+), 3 deletions(-)
--- linux-next-20101013.orig/drivers/gpu/drm/nouveau/Kconfig
+++ linux-next-20101013/drivers/gpu/drm/nouveau/Kconfig
@@ -1,16 +1,17 @@
config DRM_NOUVEAU
tristate Nouveau (nVidia) cards
- depends on DRM PCI
+ depends on DRM PCI HWMON
https://bugs.freedesktop.org/show_bug.cgi?id=30188
--- Comment #27 from Alex Deucher ag...@yahoo.com 2010-10-13 13:53:07 PDT ---
This patch, scheduled hopefully for 2.6.36 should also fix the issue:
So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
a name (with flink) we could endup with 2 handle pointing to the same
object (flink object and open it from same file descriptor). Would it be ok
if i change gem open to first look if we already have an handle for the
On Thu, 2010-10-14 at 08:14 +1000, Dave Airlie wrote:
On Wed, 2010-10-13 at 17:57 -0400, Jerome Glisse wrote:
So we are facing a deadlock with the radeon cs ioctl. When a buffer is given
a name (with flink) we could endup with 2 handle pointing to the same
object (flink object and open it
31 matches
Mail list logo
