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 somewh
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 deletions(-
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.
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 ope
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
obje
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 from same file descriptor). Would it be ok
> if i change
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
obje
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
Sign
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 restor
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:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=c919b371cb734f42b1130e706ecee262f8d92
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:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=c919b371cb734f42b1130e706ecee262f8d9
unlap
---
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 +1,17 @@
config DRM_NOUVEAU
unlap
---
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 +1,17 @@
config DRM_NOUVEAU
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
Sign
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 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 restor
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@lists.freedesktop.org
Signed-off-by: Jason Wessel
---
drivers/gpu/drm/radeon/radeon_display.c | 32 -
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 somewh
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 deletions(-
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.
https://bugs.freedesktop.org/show_bug.cgi?id=30694
Kevin DeKorte changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/r600
AssignedTo|
https://bugs.freedesktop.org/show_bug.cgi?id=30694
Kevin DeKorte changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/r600
AssignedTo|
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 #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 issue
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 issu
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 mas
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 mas
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/use
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: med
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/use
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: med
34 matches
Mail list logo