[Bug 40622] [radeon] - kms wrong resolution mode used after backlight on/off switch
https://bugzilla.kernel.org/show_bug.cgi?id=40622 --- Comment #11 from Torsten Krah 2011-08-07 09:54:20 --- Hm grepped my system - no one seems to listen for that event. To confirm this theory i did this: mv /usr/bin/xrandr > /usr/bin/xrandr.dist and replaced the xrandr with: #!/bin/bash touch /tmp/xrandr.out echo "Called" >> /tmp/xrandr.out /usr/bin/xrandr.dist $@ Pressing the backlight key there is no xrandr.out in tmp -> no one called the tool. Any other things to look for or to try? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #23 from Andy Furniss 2011-08-07 03:05:19 PDT --- (In reply to comment #22) > I followed Andy's advice and grabbed a d-r-t kernel, now everything seems to > be > running okay. > > On my HD5670 I haven't noticed any difference in performance, OTOH neither do > I > get the corruption mentioned, cubemap renders correctly. I've tested a bit more and I don't always see it when just running and individual app. I have a script that runs the mesa demos in alphabetical order - and so far running like this I have always seen it on some random selection of the 3D demos. fbo_firecube is often OK, but if it does show it, then the corruption will be along the diagonal of the faces of the rotating cube and not across the window like the others. Openarena is the only game I've seen it with. The corrupted squares/rectangles have varying content and also get the bloom effect applied to them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|unspecified |git Component|Driver/Radeon |Drivers/Gallium/r600 AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | --- Comment #1 from Alex Deucher 2011-08-07 07:41:53 PDT --- Is this a regression? Please attach your xorg log, dmesg output, and glxinfo output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40622] [radeon] - kms wrong resolution mode used after backlight on/off switch
https://bugzilla.kernel.org/show_bug.cgi?id=40622 --- Comment #12 from Alex Deucher 2011-08-07 14:44:59 --- The porgram may be talking randr directly to the Xserver. What happens if you hit the button when X isn't running (i.e., just console)? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #2 from runetmem...@gmail.com 2011-08-07 08:24:29 PDT --- Created an attachment (id=50014) --> (https://bugs.freedesktop.org/attachment.cgi?id=50014) Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #3 from runetmem...@gmail.com 2011-08-07 08:25:06 PDT --- Created an attachment (id=50015) --> (https://bugs.freedesktop.org/attachment.cgi?id=50015) dmesg output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #4 from runetmem...@gmail.com 2011-08-07 08:25:49 PDT --- Created an attachment (id=50016) --> (https://bugs.freedesktop.org/attachment.cgi?id=50016) glxinfo output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #5 from runetmem...@gmail.com 2011-08-07 08:37:01 PDT --- > Is this a regression? I don't know. I first time try R600g in this year. In previous year I didn't run games with R600g. > Please attach your xorg log, dmesg output, and glxinfo output. Attached. I also want to note: BEEP and WINE are x86. Unigine Heaven and OilRush are x86_64. So maybe it's somehow related to the problem. I also try to launch StarCraft II under WINE (x86). Same problem on splashscreen and also GPU lockup: https://bugs.freedesktop.org/show_bug.cgi?id=39902 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 Sven Arvidsson changed: What|Removed |Added CC||s...@whiz.se --- Comment #6 from Sven Arvidsson 2011-08-07 09:05:06 PDT --- I don't see any screenshot, did you forget to attach it? The games you mention (BEEP, Source titles) have been working fine here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #24 from Andy Furniss 2011-08-07 11:18:39 PDT --- (In reply to comment #19) > I don't get any exceptions or errors, but I do get some minor corruption on > some mesa demos and openarena. Nexuiz and etqw looked OK. Tried the patches on my AGP rv670 and rather than corruption I get GPU timeouts/resets. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or written. The point of this is to be able to avoid
unnecessary waiting, e.g. if a GPU has written something to a buffer and is now
reading that buffer, and a CPU wants to map that buffer for read, it needs to
only wait for the last write. If there were no write, there wouldn't be any
waiting needed.
This, or course, requires user space drivers to send read/write flags
with each relocation (like we have read/write domains in radeon, so we can
actually use those for something useful now).
Now how this patch works:
The read/write flags should passed to ttm_validate_buffer. TTM maintains
separate sync objects of the last read and write for each buffer, in addition
to the sync object of the last use of a buffer. ttm_bo_wait then operates
with one the sync objects.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/nouveau/nouveau_bo.c|3 +-
drivers/gpu/drm/nouveau/nouveau_gem.c |5 +-
drivers/gpu/drm/radeon/radeon_cs.c |1 +
drivers/gpu/drm/radeon/radeon_object.h |2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 97 ++
drivers/gpu/drm/ttm/ttm_bo_util.c | 26 +++--
drivers/gpu/drm/ttm/ttm_bo_vm.c |2 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 17 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |1 +
include/drm/ttm/ttm_bo_api.h| 16 +-
include/drm/ttm/ttm_execbuf_util.h |6 ++
11 files changed, 137 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 890d50e..e87e24b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1104,7 +1104,8 @@ nouveau_bo_vma_del(struct nouveau_bo *nvbo, struct
nouveau_vma *vma)
if (vma->node) {
if (nvbo->bo.mem.mem_type != TTM_PL_SYSTEM) {
spin_lock(&nvbo->bo.bdev->fence_lock);
- ttm_bo_wait(&nvbo->bo, false, false, false);
+ ttm_bo_wait(&nvbo->bo, false, false, false,
+ TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
nouveau_vm_unmap(vma);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 5f0bc57..322bf62 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -589,7 +589,8 @@ nouveau_gem_pushbuf_reloc_apply(struct drm_device *dev,
}
spin_lock(&nvbo->bo.bdev->fence_lock);
- ret = ttm_bo_wait(&nvbo->bo, false, false, false);
+ ret = ttm_bo_wait(&nvbo->bo, false, false, false,
+ TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
if (ret) {
NV_ERROR(dev, "reloc wait_idle failed: %d\n", ret);
@@ -825,7 +826,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
nvbo = nouveau_gem_object(gem);
spin_lock(&nvbo->bo.bdev->fence_lock);
- ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait);
+ ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait, TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
drm_gem_object_unreference_unlocked(gem);
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index fae00c0..14e8531 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -80,6 +80,7 @@ int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
p->relocs[i].lobj.wdomain = r->write_domain;
p->relocs[i].lobj.rdomain = r->read_domains;
p->relocs[i].lobj.tv.bo = &p->relocs[i].robj->tbo;
+ p->relocs[i].lobj.tv.usage = TTM_USAGE_READWRITE;
p->relocs[i].handle = r->handle;
p->relocs[i].flags = r->flags;
radeon_bo_list_add_object(&p->relocs[i].lobj,
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index ede6c13..e9dc8b2 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -130,7 +130,7 @@ static inline int radeon_bo_wait(struct radeon_bo *bo, u32
*mem_type,
if (mem_type)
*mem_type = bo->tbo.mem.mem_type;
if (bo->tbo.sync_obj)
- r = ttm_bo_wait(&bo->tbo, true, true, no_wait);
+ r = ttm_bo_wait(&bo->tbo, true, true, no_wait,
TTM_USAGE_READWRITE);
spin_unlock(&bo->tbo.bdev->fence_lock);
ttm_bo_unreserve(&bo
[PATCH 2/2] drm/radeon/kms: add a new gem_wait ioctl with read/write flags
The new DRM_RADEON_GEM_WAIT ioctl combines GEM_WAIT_IDLE and GEM_BUSY (there
is a NO_WAIT flag to get the latter) with USAGE_READ and USAGE_WRITE flags
to take advantage of the new ttm_bo_wait changes.
Also bump the DRM version.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/radeon.h|2 +
drivers/gpu/drm/radeon/radeon_cs.c |5 +++-
drivers/gpu/drm/radeon/radeon_drv.c|3 +-
drivers/gpu/drm/radeon/radeon_gem.c| 36 +--
drivers/gpu/drm/radeon/radeon_kms.c|1 +
drivers/gpu/drm/radeon/radeon_object.h |4 +-
include/drm/radeon_drm.h | 11 +
7 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 32807ba..0040d28 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1143,6 +1143,8 @@ int radeon_gem_set_tiling_ioctl(struct drm_device *dev,
void *data,
struct drm_file *filp);
int radeon_gem_get_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int radeon_gem_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
/* VRAM scratch page for HDP bug */
struct r700_vram_scratch {
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 14e8531..f0b9066 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -80,7 +80,10 @@ int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
p->relocs[i].lobj.wdomain = r->write_domain;
p->relocs[i].lobj.rdomain = r->read_domains;
p->relocs[i].lobj.tv.bo = &p->relocs[i].robj->tbo;
- p->relocs[i].lobj.tv.usage = TTM_USAGE_READWRITE;
+ if (r->read_domains)
+ p->relocs[i].lobj.tv.usage |= TTM_USAGE_READ;
+ if (r->write_domain)
+ p->relocs[i].lobj.tv.usage |= TTM_USAGE_WRITE;
p->relocs[i].handle = r->handle;
p->relocs[i].flags = r->flags;
radeon_bo_list_add_object(&p->relocs[i].lobj,
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index e71d2ed..bd187e0 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -52,9 +52,10 @@
* 2.9.0 - r600 tiling (s3tc,rgtc) working, SET_PREDICATION packet 3 on r600
+ eg, backend query
* 2.10.0 - fusion 2D tiling
* 2.11.0 - backend map, initial compute support for the CS checker
+ * 2.12.0 - DRM_RADEON_GEM_WAIT ioctl
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 11
+#define KMS_DRIVER_MINOR 12
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index aa1ca2d..2edc2a4 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -122,7 +122,7 @@ int radeon_gem_set_domain(struct drm_gem_object *gobj,
}
if (domain == RADEON_GEM_DOMAIN_CPU) {
/* Asking for cpu access wait for object idle */
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, NULL, false, TTM_USAGE_READWRITE);
if (r) {
printk(KERN_ERR "Failed to wait for object !\n");
return r;
@@ -273,7 +273,7 @@ int radeon_gem_busy_ioctl(struct drm_device *dev, void
*data,
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
- r = radeon_bo_wait(robj, &cur_placement, true);
+ r = radeon_bo_wait(robj, &cur_placement, true, TTM_USAGE_READWRITE);
switch (cur_placement) {
case TTM_PL_VRAM:
args->domain = RADEON_GEM_DOMAIN_VRAM;
@@ -303,7 +303,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void
*data,
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, NULL, false, TTM_USAGE_READWRITE);
/* callback hw specific functions if any */
if (robj->rdev->asic->ioctl_wait_idle)
robj->rdev->asic->ioctl_wait_idle(robj->rdev, robj);
@@ -311,6 +311,36 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
void *data,
return r;
}
+int radeon_gem_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp)
+{
+ struct drm_radeon_gem_wait *args = data;
+ struct drm_gem_object *gobj;
+ struct radeon_bo *robj;
+ bool no_wait = (args->flags & RADEON_GEM_NO_WAIT) != 0;
[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #55 from Lars G 2011-08-07 13:47:52 PDT --- Did some more testing and it works really great here! Can't trigger any bugs/regressions/crashes. So i would say it's ready for primetime! :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #7 from Alex Deucher 2011-08-07 14:34:19 PDT --- 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #8 from runetmem...@gmail.com 2011-08-07 19:30:04 PDT --- Created an attachment (id=50020) --> (https://bugs.freedesktop.org/attachment.cgi?id=50020) BEEP screenshot -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #9 from runetmem...@gmail.com 2011-08-07 19:30:54 PDT --- > I don't see any screenshot, did you forget to attach it? Yes, sorry. Attached. > 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver. Ok, I will check. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39877] Games rendered pixelated
https://bugs.freedesktop.org/show_bug.cgi?id=39877 Alex changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Alex 2011-08-07 21:39:22 PDT --- *** This bug has been marked as a duplicate of bug 39897 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 Alex changed: What|Removed |Added CC||cerebro.alex...@gmail.com --- Comment #10 from Alex 2011-08-07 21:39:22 PDT --- *** Bug 39877 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #11 from Alex 2011-08-07 21:50:01 PDT --- @Alex Deucher I didn't reply before to let you enjoy your week-end. But you were right, to fix this issue create or update a xorg.conf with the following content : Section "Device" Identifier "Configured Video Device" Option "ColorTiling""False" EndSection I have two questions though - "32 bit games require a 32 bit 3D driver" : how do we check that ? LIBGL_DEBUG=verbose glxinfo ? In my case, it opens r600_dri.so from a x86_64 folder. I tried to find a guide or a FAQ (as it seems a fairly common issue) in vain. - Is there a "proper" fix ? Do you want us to test something ? to apply a patch ? We'd be glad to do the "boring" thing (compiling+testing). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #12 from runetmem...@gmail.com 2011-08-07 23:03:44 PDT --- > 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver. This bug is not reproduced for me on pure x86 setup of Ubuntu Oneiric with and without xorg-edgers PPA updates. So I think it's a packaging problem of Oneiric/xorg-edgers Mesa or drivers packages. But I didn't know what exactly broken to file proper bugreport to Canonical. How can I check what's broken in packages for Oneiric/xorg-edgers? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40622] [radeon] - kms wrong resolution mode used after backlight on/off switch
https://bugzilla.kernel.org/show_bug.cgi?id=40622 --- Comment #11 from Torsten Krah 2011-08-07 09:54:20 --- Hm grepped my system - no one seems to listen for that event. To confirm this theory i did this: mv /usr/bin/xrandr > /usr/bin/xrandr.dist and replaced the xrandr with: #!/bin/bash touch /tmp/xrandr.out echo "Called" >> /tmp/xrandr.out /usr/bin/xrandr.dist $@ Pressing the backlight key there is no xrandr.out in tmp -> no one called the tool. Any other things to look for or to try? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #23 from Andy Furniss 2011-08-07 03:05:19 PDT --- (In reply to comment #22) > I followed Andy's advice and grabbed a d-r-t kernel, now everything seems to > be > running okay. > > On my HD5670 I haven't noticed any difference in performance, OTOH neither do > I > get the corruption mentioned, cubemap renders correctly. I've tested a bit more and I don't always see it when just running and individual app. I have a script that runs the mesa demos in alphabetical order - and so far running like this I have always seen it on some random selection of the 3D demos. fbo_firecube is often OK, but if it does show it, then the corruption will be along the diagonal of the faces of the rotating cube and not across the window like the others. Openarena is the only game I've seen it with. The corrupted squares/rectangles have varying content and also get the bloom effect applied to them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|unspecified |git Component|Driver/Radeon |Drivers/Gallium/r600 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | --- Comment #1 from Alex Deucher 2011-08-07 07:41:53 PDT --- Is this a regression? Please attach your xorg log, dmesg output, and glxinfo output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40622] [radeon] - kms wrong resolution mode used after backlight on/off switch
https://bugzilla.kernel.org/show_bug.cgi?id=40622 --- Comment #12 from Alex Deucher 2011-08-07 14:44:59 --- The porgram may be talking randr directly to the Xserver. What happens if you hit the button when X isn't running (i.e., just console)? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #2 from runetmember at gmail.com 2011-08-07 08:24:29 PDT --- Created an attachment (id=50014) --> (https://bugs.freedesktop.org/attachment.cgi?id=50014) Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #3 from runetmember at gmail.com 2011-08-07 08:25:06 PDT --- Created an attachment (id=50015) --> (https://bugs.freedesktop.org/attachment.cgi?id=50015) dmesg output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #4 from runetmember at gmail.com 2011-08-07 08:25:49 PDT --- Created an attachment (id=50016) --> (https://bugs.freedesktop.org/attachment.cgi?id=50016) glxinfo output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #5 from runetmember at gmail.com 2011-08-07 08:37:01 PDT --- > Is this a regression? I don't know. I first time try R600g in this year. In previous year I didn't run games with R600g. > Please attach your xorg log, dmesg output, and glxinfo output. Attached. I also want to note: BEEP and WINE are x86. Unigine Heaven and OilRush are x86_64. So maybe it's somehow related to the problem. I also try to launch StarCraft II under WINE (x86). Same problem on splashscreen and also GPU lockup: https://bugs.freedesktop.org/show_bug.cgi?id=39902 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 Sven Arvidsson changed: What|Removed |Added CC||sa at whiz.se --- Comment #6 from Sven Arvidsson 2011-08-07 09:05:06 PDT --- I don't see any screenshot, did you forget to attach it? The games you mention (BEEP, Source titles) have been working fine here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #24 from Andy Furniss 2011-08-07 11:18:39 PDT --- (In reply to comment #19) > I don't get any exceptions or errors, but I do get some minor corruption on > some mesa demos and openarena. Nexuiz and etqw looked OK. Tried the patches on my AGP rv670 and rather than corruption I get GPU timeouts/resets. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or written. The point of this is to be able to avoid
unnecessary waiting, e.g. if a GPU has written something to a buffer and is now
reading that buffer, and a CPU wants to map that buffer for read, it needs to
only wait for the last write. If there were no write, there wouldn't be any
waiting needed.
This, or course, requires user space drivers to send read/write flags
with each relocation (like we have read/write domains in radeon, so we can
actually use those for something useful now).
Now how this patch works:
The read/write flags should passed to ttm_validate_buffer. TTM maintains
separate sync objects of the last read and write for each buffer, in addition
to the sync object of the last use of a buffer. ttm_bo_wait then operates
with one the sync objects.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/nouveau/nouveau_bo.c|3 +-
drivers/gpu/drm/nouveau/nouveau_gem.c |5 +-
drivers/gpu/drm/radeon/radeon_cs.c |1 +
drivers/gpu/drm/radeon/radeon_object.h |2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 97 ++
drivers/gpu/drm/ttm/ttm_bo_util.c | 26 +++--
drivers/gpu/drm/ttm/ttm_bo_vm.c |2 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 17 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |1 +
include/drm/ttm/ttm_bo_api.h| 16 +-
include/drm/ttm/ttm_execbuf_util.h |6 ++
11 files changed, 137 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 890d50e..e87e24b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1104,7 +1104,8 @@ nouveau_bo_vma_del(struct nouveau_bo *nvbo, struct
nouveau_vma *vma)
if (vma->node) {
if (nvbo->bo.mem.mem_type != TTM_PL_SYSTEM) {
spin_lock(&nvbo->bo.bdev->fence_lock);
- ttm_bo_wait(&nvbo->bo, false, false, false);
+ ttm_bo_wait(&nvbo->bo, false, false, false,
+ TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
nouveau_vm_unmap(vma);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 5f0bc57..322bf62 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -589,7 +589,8 @@ nouveau_gem_pushbuf_reloc_apply(struct drm_device *dev,
}
spin_lock(&nvbo->bo.bdev->fence_lock);
- ret = ttm_bo_wait(&nvbo->bo, false, false, false);
+ ret = ttm_bo_wait(&nvbo->bo, false, false, false,
+ TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
if (ret) {
NV_ERROR(dev, "reloc wait_idle failed: %d\n", ret);
@@ -825,7 +826,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
nvbo = nouveau_gem_object(gem);
spin_lock(&nvbo->bo.bdev->fence_lock);
- ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait);
+ ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait, TTM_USAGE_READWRITE);
spin_unlock(&nvbo->bo.bdev->fence_lock);
drm_gem_object_unreference_unlocked(gem);
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index fae00c0..14e8531 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -80,6 +80,7 @@ int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
p->relocs[i].lobj.wdomain = r->write_domain;
p->relocs[i].lobj.rdomain = r->read_domains;
p->relocs[i].lobj.tv.bo = &p->relocs[i].robj->tbo;
+ p->relocs[i].lobj.tv.usage = TTM_USAGE_READWRITE;
p->relocs[i].handle = r->handle;
p->relocs[i].flags = r->flags;
radeon_bo_list_add_object(&p->relocs[i].lobj,
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index ede6c13..e9dc8b2 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -130,7 +130,7 @@ static inline int radeon_bo_wait(struct radeon_bo *bo, u32
*mem_type,
if (mem_type)
*mem_type = bo->tbo.mem.mem_type;
if (bo->tbo.sync_obj)
- r = ttm_bo_wait(&bo->tbo, true, true, no_wait);
+ r = ttm_bo_wait(&bo->tbo, true, true, no_wait,
TTM_USAGE_READWRITE);
spin_unlock(&bo->tbo.bdev->fence_lock);
ttm_bo_unreserve(&bo->
[PATCH 2/2] drm/radeon/kms: add a new gem_wait ioctl with read/write flags
The new DRM_RADEON_GEM_WAIT ioctl combines GEM_WAIT_IDLE and GEM_BUSY (there
is a NO_WAIT flag to get the latter) with USAGE_READ and USAGE_WRITE flags
to take advantage of the new ttm_bo_wait changes.
Also bump the DRM version.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon.h|2 +
drivers/gpu/drm/radeon/radeon_cs.c |5 +++-
drivers/gpu/drm/radeon/radeon_drv.c|3 +-
drivers/gpu/drm/radeon/radeon_gem.c| 36 +--
drivers/gpu/drm/radeon/radeon_kms.c|1 +
drivers/gpu/drm/radeon/radeon_object.h |4 +-
include/drm/radeon_drm.h | 11 +
7 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 32807ba..0040d28 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1143,6 +1143,8 @@ int radeon_gem_set_tiling_ioctl(struct drm_device *dev,
void *data,
struct drm_file *filp);
int radeon_gem_get_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int radeon_gem_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
/* VRAM scratch page for HDP bug */
struct r700_vram_scratch {
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 14e8531..f0b9066 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -80,7 +80,10 @@ int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
p->relocs[i].lobj.wdomain = r->write_domain;
p->relocs[i].lobj.rdomain = r->read_domains;
p->relocs[i].lobj.tv.bo = &p->relocs[i].robj->tbo;
- p->relocs[i].lobj.tv.usage = TTM_USAGE_READWRITE;
+ if (r->read_domains)
+ p->relocs[i].lobj.tv.usage |= TTM_USAGE_READ;
+ if (r->write_domain)
+ p->relocs[i].lobj.tv.usage |= TTM_USAGE_WRITE;
p->relocs[i].handle = r->handle;
p->relocs[i].flags = r->flags;
radeon_bo_list_add_object(&p->relocs[i].lobj,
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index e71d2ed..bd187e0 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -52,9 +52,10 @@
* 2.9.0 - r600 tiling (s3tc,rgtc) working, SET_PREDICATION packet 3 on r600
+ eg, backend query
* 2.10.0 - fusion 2D tiling
* 2.11.0 - backend map, initial compute support for the CS checker
+ * 2.12.0 - DRM_RADEON_GEM_WAIT ioctl
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 11
+#define KMS_DRIVER_MINOR 12
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index aa1ca2d..2edc2a4 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -122,7 +122,7 @@ int radeon_gem_set_domain(struct drm_gem_object *gobj,
}
if (domain == RADEON_GEM_DOMAIN_CPU) {
/* Asking for cpu access wait for object idle */
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, NULL, false, TTM_USAGE_READWRITE);
if (r) {
printk(KERN_ERR "Failed to wait for object !\n");
return r;
@@ -273,7 +273,7 @@ int radeon_gem_busy_ioctl(struct drm_device *dev, void
*data,
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
- r = radeon_bo_wait(robj, &cur_placement, true);
+ r = radeon_bo_wait(robj, &cur_placement, true, TTM_USAGE_READWRITE);
switch (cur_placement) {
case TTM_PL_VRAM:
args->domain = RADEON_GEM_DOMAIN_VRAM;
@@ -303,7 +303,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void
*data,
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
- r = radeon_bo_wait(robj, NULL, false);
+ r = radeon_bo_wait(robj, NULL, false, TTM_USAGE_READWRITE);
/* callback hw specific functions if any */
if (robj->rdev->asic->ioctl_wait_idle)
robj->rdev->asic->ioctl_wait_idle(robj->rdev, robj);
@@ -311,6 +311,36 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
void *data,
return r;
}
+int radeon_gem_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp)
+{
+ struct drm_radeon_gem_wait *args = data;
+ struct drm_gem_object *gobj;
+ struct radeon_bo *robj;
+ bool no_wait = (args->flags & RADEON_GEM_NO_WAIT) != 0;
+
[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #55 from Lars G 2011-08-07 13:47:52 PDT --- Did some more testing and it works really great here! Can't trigger any bugs/regressions/crashes. So i would say it's ready for primetime! :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #7 from Alex Deucher 2011-08-07 14:34:19 PDT --- 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #8 from runetmember at gmail.com 2011-08-07 19:30:04 PDT --- Created an attachment (id=50020) --> (https://bugs.freedesktop.org/attachment.cgi?id=50020) BEEP screenshot -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #9 from runetmember at gmail.com 2011-08-07 19:30:54 PDT --- > I don't see any screenshot, did you forget to attach it? Yes, sorry. Attached. > 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver. Ok, I will check. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39877] Games rendered pixelated
https://bugs.freedesktop.org/show_bug.cgi?id=39877 Alex changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Alex 2011-08-07 21:39:22 PDT --- *** This bug has been marked as a duplicate of bug 39897 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 Alex changed: What|Removed |Added CC||cerebro.alexiel at gmail.com --- Comment #10 from Alex 2011-08-07 21:39:22 PDT --- *** Bug 39877 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #11 from Alex 2011-08-07 21:50:01 PDT --- @Alex Deucher I didn't reply before to let you enjoy your week-end. But you were right, to fix this issue create or update a xorg.conf with the following content : Section "Device" Identifier "Configured Video Device" Option "ColorTiling""False" EndSection I have two questions though - "32 bit games require a 32 bit 3D driver" : how do we check that ? LIBGL_DEBUG=verbose glxinfo ? In my case, it opens r600_dri.so from a x86_64 folder. I tried to find a guide or a FAQ (as it seems a fairly common issue) in vain. - Is there a "proper" fix ? Do you want us to test something ? to apply a patch ? We'd be glad to do the "boring" thing (compiling+testing). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39897] Graphical glitches in some games on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #12 from runetmember at gmail.com 2011-08-07 23:03:44 PDT --- > 32 bit games require a 32 bit 3D driver, so make sure you also updated your 32 bit driver. This bug is not reproduced for me on pure x86 setup of Ubuntu Oneiric with and without xorg-edgers PPA updates. So I think it's a packaging problem of Oneiric/xorg-edgers Mesa or drivers packages. But I didn't know what exactly broken to file proper bugreport to Canonical. How can I check what's broken in packages for Oneiric/xorg-edgers? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
