[Bug 71081] kernel: kernel BUG at drivers/gpu/drm/radeon/radeon_sa.c:322!
https://bugzilla.kernel.org/show_bug.cgi?id=71081 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your full dmesg output. Was there a particular app or operation that triggered this? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 --- Comment #4 from Christoph Haag --- Created attachment 94690 --> https://bugs.freedesktop.org/attachment.cgi?id=94690&action=edit GPU fault after it sort of works with patch from #3 Well. At least initially it does not crash anymore. It does start now. Nice! The problems begin very quickly after gameplay with GPU faults in the attached dmesg. Amazingly it keeps running with decent FPS for some time while these GPU faults are dumped into the log. But eventually the system will hard lockup (I got to 160 MB log before the lockup so I arbitrarily trimmed after the first few GPU fault messages). This was with R600_DEBUG=nohyperz, by the way. I have also once seen another segfault in radeonsi, but I didn't have debug symbols at that time and haven't reproduced it with debug symbols now, because the hard lockup after a few seconds of gameplay is a bit annoying when trying to reproduce something. :) Maybe I can give a better backtrace later, but maybe it's unrelated. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/727abe90/attachment-0001.html>
[Bug 71081] kernel: kernel BUG at drivers/gpu/drm/radeon/radeon_sa.c:322!
https://bugzilla.kernel.org/show_bug.cgi?id=71081 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(Other)|Video(DRI - non Intel) Assignee|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
Info: mapping multiple BARs. Your kernel is fine.
Btw, I don't know whether the following observation is related or not, but it so happens that after resume from suspend-to-disk, I see the booting up of the resume kernel on the console but when it is time for the original kernel to take over and switch to graphics, the screen remains black but the machine is responsive over the network. And this doesn't happen on every resume but only sporadically. And yep, -rc3 was fine. On Mon, Feb 24, 2014 at 05:24:00PM +0100, Borislav Petkov wrote: > This started happening this morning after booting -rc4+tip, let's > add *everybody* to CC :-) > > We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and > other goodies on the stack. > > ... > [0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at > [8800cac3-8800cec2] > [0.489975] resource map sanity check conflict: 0xfed1 0xfed15fff > 0xfed1 0xfed13fff pnp 00:01 > [0.490079] [ cut here ] > [0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 > __ioremap_caller+0x372/0x380() > [0.490306] Info: mapping multiple BARs. Your kernel is fine. > [0.490371] Modules linked in: > [0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1 > [0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) > 11/13/2012 > [0.490742] 00ab 880213d01ad8 816112e3 > 0006 > [0.491032] 880213d01b28 880213d01b18 8104e9bc > 880213d01b08 > [0.491343] c9c58000 fed1 fed1 > 6000 > [0.491631] Call Trace: > [0.493337] [] dump_stack+0x4f/0x7c > [0.493420] [] warn_slowpath_common+0x8c/0xc0 > [0.493503] [] warn_slowpath_fmt+0x46/0x50 > [0.493588] [] __ioremap_caller+0x372/0x380 > [0.493674] [] ? snb_uncore_imc_init_box+0x62/0x90 > [0.493761] [] ioremap_nocache+0x17/0x20 > [0.493846] [] snb_uncore_imc_init_box+0x62/0x90 > [0.493933] [] uncore_pci_probe+0xe5/0x1e0 > [0.494020] [] local_pci_probe+0x4e/0xa0 > [0.494104] [] ? get_device+0x19/0x20 > [0.494213] [] pci_device_probe+0xe1/0x130 > [0.494300] [] driver_probe_device+0x7b/0x240 > [0.494385] [] __driver_attach+0xab/0xb0 > [0.494469] [] ? driver_probe_device+0x240/0x240 > [0.494551] [] bus_for_each_dev+0x5e/0x90 > [0.494634] [] driver_attach+0x1e/0x20 > [0.494718] [] bus_add_driver+0x117/0x230 > [0.494802] [] driver_register+0x64/0xf0 > [0.494884] [] __pci_register_driver+0x64/0x70 > [0.494972] [] ? uncore_types_init+0x19c/0x19c > [0.495056] [] intel_uncore_init+0x177/0x41c > [0.495155] [] ? uncore_types_init+0x19c/0x19c > [0.495242] [] do_one_initcall+0x4e/0x170 > [0.495326] [] ? parse_args+0x60/0x360 > [0.495411] [] kernel_init_freeable+0x106/0x19a > [0.495497] [] ? do_early_param+0x86/0x86 > [0.495582] [] ? rest_init+0xd0/0xd0 > [0.495666] [] kernel_init+0xe/0xf0 > [0.495749] [] ret_from_fork+0x7c/0xb0 > [0.495831] [] ? rest_init+0xd0/0xd0 > [0.495921] ---[ end trace 428f365c054d9a01 ]--- > [0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 > Joules, 3 fixed counters 163840 ms ovfl timer > [0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes) > [0.498833] audit: initializing netlink subsys (disabled) > [0.499024] audit: type=2000 audit(1393259866.477:1): initialized -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH v2 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
From: Sagar Kamble
With this patch we allow larger cursor planes of sizes 128x128
and 256x256.
v2: Added more precise check on size while setting cursor plane.
Testcase: igt/kms_cursor_crc
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: G, Pallavi
Signed-off-by: Sagar Kamble
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_display.c | 28 +++-
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2f564ce..2fee3a2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3522,7 +3522,11 @@
/* New style CUR*CNTR flags */
#define CURSOR_MODE 0x27
#define CURSOR_MODE_DISABLE 0x00
+#define CURSOR_MODE_128_32B_AX 0x02
+#define CURSOR_MODE_256_32B_AX 0x03
#define CURSOR_MODE_64_32B_AX 0x07
+#define CURSOR_MODE_128_ARGB_AX ((1 << 5) | CURSOR_MODE_128_32B_AX)
+#define CURSOR_MODE_256_ARGB_AX ((1 << 5) | CURSOR_MODE_256_32B_AX)
#define CURSOR_MODE_64_ARGB_AX ((1 << 5) | CURSOR_MODE_64_32B_AX)
#define MCURSOR_PIPE_SELECT (1 << 28)
#define MCURSOR_PIPE_A 0x00
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f19e6ea..d036b41 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7411,10 +7411,18 @@ static void i9xx_update_cursor(struct drm_crtc *crtc,
u32 base)
bool visible = base != 0;
if (intel_crtc->cursor_visible != visible) {
+ int16_t width = intel_crtc->cursor_width;
uint32_t cntl = I915_READ(CURCNTR(pipe));
if (base) {
cntl &= ~(CURSOR_MODE | MCURSOR_PIPE_SELECT);
- cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
+
+ if (width == 64)
+ cntl |= CURSOR_MODE_64_ARGB_AX |
MCURSOR_GAMMA_ENABLE;
+ else if (width == 128)
+ cntl |= CURSOR_MODE_128_ARGB_AX |
MCURSOR_GAMMA_ENABLE;
+ else if (width == 256)
+ cntl |= CURSOR_MODE_256_ARGB_AX |
MCURSOR_GAMMA_ENABLE;
+
cntl |= pipe << 28; /* Connect to correct pipe */
} else {
cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
@@ -7439,10 +7447,17 @@ static void ivb_update_cursor(struct drm_crtc *crtc,
u32 base)
bool visible = base != 0;
if (intel_crtc->cursor_visible != visible) {
+ int16_t width = intel_crtc->cursor_width;
uint32_t cntl = I915_READ(CURCNTR_IVB(pipe));
if (base) {
cntl &= ~CURSOR_MODE;
- cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
+
+ if (width == 64)
+ cntl |= CURSOR_MODE_64_ARGB_AX |
MCURSOR_GAMMA_ENABLE;
+ else if (width == 128)
+ cntl |= CURSOR_MODE_128_ARGB_AX |
MCURSOR_GAMMA_ENABLE;
+ else if (width == 256)
+ cntl |= CURSOR_MODE_256_ARGB_AX |
MCURSOR_GAMMA_ENABLE;
} else {
cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
cntl |= CURSOR_MODE_DISABLE;
@@ -7538,9 +7553,12 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
goto finish;
}
- /* Currently we only support 64x64 cursors */
- if (width != 64 || height != 64) {
- DRM_ERROR("we currently only support 64x64 cursors\n");
+ /* Check for which cursor types we support */
+ if ((!(width == 64 && height == 64) && IS_GEN2(dev)) ||
+ (!(width == 64 && height == 64)
+&& !(width == 128 && height == 128)
+&& !(width == 256 && height == 256))) {
+ DRM_ERROR("Cursor dimension is not supported\n");
return -EINVAL;
}
--
1.8.5
[PATCH 0/6] Radeon memory management improvements
On Mon, Feb 24, 2014 at 5:40 PM, Christian K?nig wrote: > Am 24.02.2014 16:20, schrieb Marek Ol??k: >> 1) Add virtual memory support for VRAM. Our GPUs support virtual memory, >> which not only solves fragmentation issues, but it also allows each buffer >> to be partially in VRAM and partially in GTT, which becomes more important >> with large buffers like 100 MB. Moving whole buffers back and forth between >> VRAM and GTT is inefficient if you can do it at page granularity. Also, due >> to fragmentation, we can never really use all of VRAM, but only about >> 90-95%. > > > Yeah, I'm also thinking about this for quite some time now. The basic > problem is that while our GPUs support VM they don't support faulting pages > in and continuing (at least nobody got that working reliable so far). E.g. > when you hit a page fault you can't relocate the page and then continue. > > Support for partially resident textures on newer hardware currently works by > splitting the buffer up into smaller buffers in userspace and then actively > checking in the shader if we hit a buffer that's not currently in memory, > but that's not really applicable in the general use case (to much shader > overhead). I was thinking of splitting buffers into smaller chunks and treating them like independent TTM buffers, i.e. one radeon_bo would contain an array of TTM buffers which would be validated independently of each other. The chunks would only be mapped together to make them look like one buffer. This would be hidden from userspace and there would only be one GEM handle for the whole buffer, so that DRI2 sharing works. > > >> 2) Add support for uncached GTT. I think it should improve performance for >> dGPUs under memory pressure, but some testing needs to be done to confirm >> that. Uncached GTT doesn't seem to work for me on Evergreen, but it's said >> to be working on some later chips. > > > Did you try to make the whole GTT uncached or just evicted BOs? Making the > whole GTT uncached probably won't work out of the box, but avoiding setting > the "SNOOPED" flag on those pages might get us better performance while > swapping them into VRAM again. I made the whole GTT uncached. Marek
[Bug 73191] [radeonsi] vdpau playback issues, skipping & looping
https://bugs.freedesktop.org/show_bug.cgi?id=73191 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #42 from Andreas Boll --- Fixed with the following commits: commit 3f98053fc94a964930c73c43154daddfd7824e7c Author: Marek Ol??k Date: Mon Jan 13 14:13:01 2014 +0100 vdpau: flush the context before exporting the surface v2 Bugzilla (bug needs XBMC changes as well): https://bugs.freedesktop.org/show_bug.cgi?id=73191 When VL uploads vertex buffers, it uses PIPE_TRANSFER_DONTBLOCK, which always flushes the context in the winsys if the buffer being mapped is busy. Since I added handling of DISCARD_RANGE, DONTBLOCK has had no effect when combined with DISCARD_RANGE and I think the context isn't flushed anywhere else, so no commands are submitted to the GPU until the IB is full, which takes a lot of frames. Using DISCARD_RANGE is not the only way to trigger this bug. The other way is to reallocate the vertex buffer before every upload. BTW, I'm not sure if this is the right place for flushing, but it does fix the bug. v2 (chk): move the flush to the right place. Signed-off-by: Christian K?nig Tested-by: StrangeNoises (rachel at strangenoises.org) commit db54fca9b86aa124447d11d2bdbe359a2742cfd5 Author: Christian K?nig Date: Tue Jan 28 15:22:05 2014 +0100 st/vdpau: add flush on unmap Flush the context when we unmap a buffer, otherwise VDPAU might start rendering the next frame while we still reference that buffer. Signed-off-by: Christian K?nig Tested-by: StrangeNoises (rachel at strangenoises.org) Additionally cherry-picked to 10.1 branch. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/d78bc06f/attachment-0001.html>
[Bug 75453] i915/DRM Gallium driver apparently not usable without DRM pipe loader
https://bugs.freedesktop.org/show_bug.cgi?id=75453
--- Comment #2 from Emil Velikov ---
* Correction: a white space only, including an empty string ("") is considered
as of both zero and non zero size according test ...
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/dcc1db83/attachment.html>
[Bug 75453] i915/DRM Gallium driver apparently not usable without DRM pipe loader
https://bugs.freedesktop.org/show_bug.cgi?id=75453 --- Comment #1 from Emil Velikov --- Two distinct things happening here - I've assumed that string as "" is considered of length zero, thus an empty dri megadriver is built. - gallium_require_drm_loader is missing for the i915, r300 and possibly svga gallium drivers. Will send patches for both shortly -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/740f6fb5/attachment.html>
[PATCH 5/5] drm/radeon: drop non blocking allocations from sub allocator
From: Christian K?nig
Not needed any more.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.h| 2 +-
drivers/gpu/drm/radeon/radeon_ring.c | 2 +-
drivers/gpu/drm/radeon/radeon_sa.c| 7 ++-
drivers/gpu/drm/radeon/radeon_semaphore.c | 2 +-
4 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 209b111..211d29e 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -181,7 +181,7 @@ extern int radeon_sa_bo_manager_suspend(struct
radeon_device *rdev,
extern int radeon_sa_bo_new(struct radeon_device *rdev,
struct radeon_sa_manager *sa_manager,
struct radeon_sa_bo **sa_bo,
- unsigned size, unsigned align, bool block);
+ unsigned size, unsigned align);
extern void radeon_sa_bo_free(struct radeon_device *rdev,
struct radeon_sa_bo **sa_bo,
struct radeon_fence *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 5321e24..8b0dfdd 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -63,7 +63,7 @@ int radeon_ib_get(struct radeon_device *rdev, int ring,
{
int r;
- r = radeon_sa_bo_new(rdev, &rdev->ring_tmp_bo, &ib->sa_bo, size, 256,
true);
+ r = radeon_sa_bo_new(rdev, &rdev->ring_tmp_bo, &ib->sa_bo, size, 256);
if (r) {
dev_err(rdev->dev, "failed to get a new IB (%d)\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index c062580..adcf3e2 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -312,7 +312,7 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
int radeon_sa_bo_new(struct radeon_device *rdev,
struct radeon_sa_manager *sa_manager,
struct radeon_sa_bo **sa_bo,
-unsigned size, unsigned align, bool block)
+unsigned size, unsigned align)
{
struct radeon_fence *fences[RADEON_NUM_RINGS];
unsigned tries[RADEON_NUM_RINGS];
@@ -353,14 +353,11 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
r = radeon_fence_wait_any(rdev, fences, false);
spin_lock(&sa_manager->wq.lock);
/* if we have nothing to wait for block */
- if (r == -ENOENT && block) {
+ if (r == -ENOENT) {
r = wait_event_interruptible_locked(
sa_manager->wq,
radeon_sa_event(sa_manager, size, align)
);
-
- } else if (r == -ENOENT) {
- r = -ENOMEM;
}
} while (!r);
diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c
b/drivers/gpu/drm/radeon/radeon_semaphore.c
index 6140af6..dbd6bcd 100644
--- a/drivers/gpu/drm/radeon/radeon_semaphore.c
+++ b/drivers/gpu/drm/radeon/radeon_semaphore.c
@@ -42,7 +42,7 @@ int radeon_semaphore_create(struct radeon_device *rdev,
return -ENOMEM;
}
r = radeon_sa_bo_new(rdev, &rdev->ring_tmp_bo, &(*semaphore)->sa_bo,
-8 * RADEON_NUM_SYNCS, 8, true);
+8 * RADEON_NUM_SYNCS, 8);
if (r) {
kfree(*semaphore);
*semaphore = NULL;
--
1.8.3.2
[PATCH 4/5] drm/radeon: remove global lock
From: Christian K?nig
Not needed any more.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h| 1 -
drivers/gpu/drm/radeon/radeon_cs.c | 4
drivers/gpu/drm/radeon/radeon_device.c | 3 +--
drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
drivers/gpu/drm/radeon/radeon_vm.c | 10 +++---
5 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 259cd20..e5fc015 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -881,7 +881,6 @@ struct radeon_vm {
};
struct radeon_vm_manager {
- struct mutexlock;
struct radeon_fence *active[RADEON_NUM_VM];
uint32_tmax_pfn;
/* number of VMIDs */
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index dd3c71d..f9a632a 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -422,7 +422,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
if (parser->ring == R600_RING_TYPE_UVD_INDEX)
radeon_uvd_note_usage(rdev);
- mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
r = radeon_bo_vm_update_pte(parser, vm);
if (r) {
@@ -430,8 +429,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
}
radeon_cs_sync_rings(parser);
radeon_semaphore_sync_to(parser->ib.semaphore, vm->fence);
- radeon_semaphore_sync_to(parser->ib.semaphore,
-radeon_vm_grab_id(rdev, vm, parser->ring));
if ((rdev->family >= CHIP_TAHITI) &&
(parser->chunk_const_ib_idx != -1)) {
@@ -442,7 +439,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
out:
mutex_unlock(&vm->mutex);
- mutex_unlock(&rdev->vm_manager.lock);
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index e58dbab..7db44de 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1191,8 +1191,7 @@ int radeon_device_init(struct radeon_device *rdev,
r = radeon_gem_init(rdev);
if (r)
return r;
- /* initialize vm here */
- mutex_init(&rdev->vm_manager.lock);
+
/* Adjust VM size here.
* Currently set to 4GB ((1 << 20) 4k pages).
* Max GPUVM size for cayman and SI is 40 bits.
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 665591a..5321e24 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -145,6 +145,13 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct
radeon_ib *ib,
return r;
}
+ /* grab a vm id if necessary */
+ if (ib->vm) {
+ struct radeon_fence *vm_id_fence;
+ vm_id_fence = radeon_vm_grab_id(rdev, ib->vm, ib->ring);
+ radeon_semaphore_sync_to(ib->semaphore, vm_id_fence);
+ }
+
/* sync with other rings */
r = radeon_semaphore_sync_rings(rdev, ib->semaphore, ib->ring);
if (r) {
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index 99fc229..22fe985 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -110,12 +110,10 @@ void radeon_vm_manager_fini(struct radeon_device *rdev)
if (!rdev->vm_manager.enabled)
return;
- mutex_lock(&rdev->vm_manager.lock);
for (i = 0; i < RADEON_NUM_VM; ++i)
radeon_fence_unref(&rdev->vm_manager.active[i]);
radeon_asic_vm_fini(rdev);
rdev->vm_manager.enabled = false;
- mutex_unlock(&rdev->vm_manager.lock);
}
/**
@@ -736,7 +734,7 @@ static void radeon_vm_update_ptes(struct radeon_device
*rdev,
* Fill in the page table entries for @bo (cayman+).
* Returns 0 for success, -EINVAL for failure.
*
- * Object have to be reserved & global and local mutex must be locked!
+ * Object have to be reserved and mutex must be locked!
*/
int radeon_vm_bo_update(struct radeon_device *rdev,
struct radeon_vm *vm,
@@ -844,12 +842,10 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
{
int r = 0;
- mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&bo_va->vm->mutex);
- if (bo_va->soffset) {
+ if (bo_va->soffset)
r = radeon_vm_bo_update(rdev, bo_va->vm, bo_va->bo, NULL);
- }
- mutex_unlock(&rdev->vm_manager.lock);
+
list_del(&bo_va->vm_list);
mutex_unlock(&bo_va->vm->mutex);
list_del(&bo_va->bo_list);
--
1.8.3.2
[PATCH 3/5] drm/radeon: use a normal BOs for the page tables v3
From: Christian K?nig
No need to make it more complicated than necessary,
just allocate the page tables as normal BO and
flush whenever the address change.
v2: update comments and function name
v3: squash bug fixes, page directory and tables patch
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 23 +-
drivers/gpu/drm/radeon/radeon_cs.c | 45 +--
drivers/gpu/drm/radeon/radeon_device.c | 1 -
drivers/gpu/drm/radeon/radeon_kms.c| 4 +-
drivers/gpu/drm/radeon/radeon_vm.c | 494 +++--
5 files changed, 272 insertions(+), 295 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 0c03bcb..259cd20 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -854,17 +854,22 @@ struct radeon_mec {
#define R600_PTE_READABLE (1 << 5)
#define R600_PTE_WRITEABLE (1 << 6)
+struct radeon_vm_pt {
+ struct radeon_bo*bo;
+ uint64_taddr;
+};
+
struct radeon_vm {
- struct list_headlist;
struct list_headva;
unsignedid;
/* contains the page directory */
- struct radeon_sa_bo *page_directory;
+ struct radeon_bo*page_directory;
uint64_tpd_gpu_addr;
+ unsignedmax_pde_used;
/* array of page tables, one for each page directory entry */
- struct radeon_sa_bo **page_tables;
+ struct radeon_vm_pt *page_tables;
struct mutexmutex;
/* last fence for cs using this vm */
@@ -877,9 +882,7 @@ struct radeon_vm {
struct radeon_vm_manager {
struct mutexlock;
- struct list_headlru_vm;
struct radeon_fence *active[RADEON_NUM_VM];
- struct radeon_sa_managersa_manager;
uint32_tmax_pfn;
/* number of VMIDs */
unsignednvm;
@@ -1008,6 +1011,7 @@ struct radeon_cs_parser {
unsignednrelocs;
struct radeon_cs_reloc *relocs;
struct radeon_cs_reloc **relocs_ptr;
+ struct radeon_bo_list *vm_bos;
struct list_headvalidated;
unsigneddma_reloc_idx;
/* indices of various chunks */
@@ -2790,10 +2794,11 @@ extern void radeon_program_register_sequence(struct
radeon_device *rdev,
*/
int radeon_vm_manager_init(struct radeon_device *rdev);
void radeon_vm_manager_fini(struct radeon_device *rdev);
-void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
+int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm);
-int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm);
-void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm);
+struct radeon_bo_list *radeon_vm_get_bos(struct radeon_device *rdev,
+struct radeon_vm *vm,
+ struct list_head *head);
struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
struct radeon_vm *vm, int ring);
void radeon_vm_flush(struct radeon_device *rdev,
@@ -2803,6 +2808,8 @@ void radeon_vm_fence(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_fence *fence);
uint64_t radeon_vm_map_gart(struct radeon_device *rdev, uint64_t addr);
+int radeon_vm_update_page_directory(struct radeon_device *rdev,
+ struct radeon_vm *vm);
int radeon_vm_bo_update(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_bo *bo,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0b3ba38..dd3c71d 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -109,6 +109,11 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
radeon_bo_list_add_object(&p->relocs[i].lobj,
&p->validated);
}
+
+ if (p->cs_flags & RADEON_CS_USE_VM)
+ p->vm_bos = radeon_vm_get_bos(p->rdev, p->ib.vm,
+ &p->validated);
+
return radeon_bo_list_validate(&p->ticket, &p->validated, p->ring);
}
@@ -320,6 +325,7 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error, bo
kfree(parser->track);
kfree(parser->relocs);
kfree(parser->relocs_ptr);
+ kfree(parser->vm_bos);
for (i = 0; i < parser->nchunks; i++)
drm_free_large(parser->chunks[i].kdata);
kfree(parser->chunk
[PATCH 2/5] drm/radeon: further cleanup vm flushing & fencing
From: Christian K?nig
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h | 3 +++
drivers/gpu/drm/radeon/radeon_cs.c | 4
drivers/gpu/drm/radeon/radeon_ring.c | 16 +++-
drivers/gpu/drm/radeon/radeon_vm.c | 31 ---
4 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 7337b35..0c03bcb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2796,6 +2796,9 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct
radeon_vm *vm);
void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm);
struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
struct radeon_vm *vm, int ring);
+void radeon_vm_flush(struct radeon_device *rdev,
+ struct radeon_vm *vm,
+ int ring);
void radeon_vm_fence(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_fence *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index f28a8d8..0b3ba38 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -430,10 +430,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device
*rdev,
r = radeon_ib_schedule(rdev, &parser->ib, NULL);
}
- if (!r) {
- radeon_vm_fence(rdev, vm, parser->ib.fence);
- }
-
out:
radeon_vm_add_to_lru(rdev, vm);
mutex_unlock(&vm->mutex);
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index fa14011..665591a 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -153,11 +153,9 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct
radeon_ib *ib,
return r;
}
- /* if we can't remember our last VM flush then flush now! */
- /* XXX figure out why we have to flush for every IB */
- if (ib->vm /*&& !ib->vm->last_flush*/) {
- radeon_ring_vm_flush(rdev, ib->ring, ib->vm);
- }
+ if (ib->vm)
+ radeon_vm_flush(rdev, ib->vm, ib->ring);
+
if (const_ib) {
radeon_ring_ib_execute(rdev, const_ib->ring, const_ib);
radeon_semaphore_free(rdev, &const_ib->semaphore, NULL);
@@ -172,10 +170,10 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct
radeon_ib *ib,
if (const_ib) {
const_ib->fence = radeon_fence_ref(ib->fence);
}
- /* we just flushed the VM, remember that */
- if (ib->vm && !ib->vm->last_flush) {
- ib->vm->last_flush = radeon_fence_ref(ib->fence);
- }
+
+ if (ib->vm)
+ radeon_vm_fence(rdev, ib->vm, ib->fence);
+
radeon_ring_unlock_commit(rdev, ring);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index 433b1eb..5160176 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -379,6 +379,27 @@ struct radeon_fence *radeon_vm_grab_id(struct
radeon_device *rdev,
}
/**
+ * radeon_vm_flush - hardware flush the vm
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm we want to flush
+ * @ring: ring to use for flush
+ *
+ * Flush the vm (cayman+).
+ *
+ * Global and local mutex must be locked!
+ */
+void radeon_vm_flush(struct radeon_device *rdev,
+struct radeon_vm *vm,
+int ring)
+{
+ /* if we can't remember our last VM flush then flush now! */
+ /* XXX figure out why we have to flush all the time */
+ if (!vm->last_flush || true)
+ radeon_ring_vm_flush(rdev, ring, vm);
+}
+
+/**
* radeon_vm_fence - remember fence for vm
*
* @rdev: radeon_device pointer
@@ -394,14 +415,18 @@ void radeon_vm_fence(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_fence *fence)
{
- radeon_fence_unref(&rdev->vm_manager.active[vm->id]);
- rdev->vm_manager.active[vm->id] = radeon_fence_ref(fence);
-
radeon_fence_unref(&vm->fence);
vm->fence = radeon_fence_ref(fence);
+ radeon_fence_unref(&rdev->vm_manager.active[vm->id]);
+ rdev->vm_manager.active[vm->id] = radeon_fence_ref(fence);
+
radeon_fence_unref(&vm->last_id_use);
vm->last_id_use = radeon_fence_ref(fence);
+
+/* we just flushed the VM, remember that */
+if (!vm->last_flush)
+vm->last_flush = radeon_fence_ref(fence);
}
/**
--
1.8.3.2
[PATCH 1/5] drm/radeon: separate gart and vm functions
From: Christian K?nig
Both are complex enough on their own.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/radeon_gart.c | 958 --
drivers/gpu/drm/radeon/radeon_vm.c | 981 +++
3 files changed, 982 insertions(+), 959 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/radeon_vm.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index ed60caa..0943353 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
- ci_dpm.o dce6_afmt.o
+ ci_dpm.o dce6_afmt.o radeon_vm.o
# add async DMA block
radeon-y += \
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index a8f9b46..2e72365 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -28,8 +28,6 @@
#include
#include
#include "radeon.h"
-#include "radeon_reg.h"
-#include "radeon_trace.h"
/*
* GART
@@ -394,959 +392,3 @@ void radeon_gart_fini(struct radeon_device *rdev)
radeon_dummy_page_fini(rdev);
}
-
-/*
- * GPUVM
- * GPUVM is similar to the legacy gart on older asics, however
- * rather than there being a single global gart table
- * for the entire GPU, there are multiple VM page tables active
- * at any given time. The VM page tables can contain a mix
- * vram pages and system memory pages and system memory pages
- * can be mapped as snooped (cached system pages) or unsnooped
- * (uncached system pages).
- * Each VM has an ID associated with it and there is a page table
- * associated with each VMID. When execting a command buffer,
- * the kernel tells the the ring what VMID to use for that command
- * buffer. VMIDs are allocated dynamically as commands are submitted.
- * The userspace drivers maintain their own address space and the kernel
- * sets up their pages tables accordingly when they submit their
- * command buffers and a VMID is assigned.
- * Cayman/Trinity support up to 8 active VMs at any given time;
- * SI supports 16.
- */
-
-/*
- * vm helpers
- *
- * TODO bind a default page at vm initialization for default address
- */
-
-/**
- * radeon_vm_num_pde - return the number of page directory entries
- *
- * @rdev: radeon_device pointer
- *
- * Calculate the number of page directory entries (cayman+).
- */
-static unsigned radeon_vm_num_pdes(struct radeon_device *rdev)
-{
- return rdev->vm_manager.max_pfn >> RADEON_VM_BLOCK_SIZE;
-}
-
-/**
- * radeon_vm_directory_size - returns the size of the page directory in bytes
- *
- * @rdev: radeon_device pointer
- *
- * Calculate the size of the page directory in bytes (cayman+).
- */
-static unsigned radeon_vm_directory_size(struct radeon_device *rdev)
-{
- return RADEON_GPU_PAGE_ALIGN(radeon_vm_num_pdes(rdev) * 8);
-}
-
-/**
- * radeon_vm_manager_init - init the vm manager
- *
- * @rdev: radeon_device pointer
- *
- * Init the vm manager (cayman+).
- * Returns 0 for success, error for failure.
- */
-int radeon_vm_manager_init(struct radeon_device *rdev)
-{
- struct radeon_vm *vm;
- struct radeon_bo_va *bo_va;
- int r;
- unsigned size;
-
- if (!rdev->vm_manager.enabled) {
- /* allocate enough for 2 full VM pts */
- size = radeon_vm_directory_size(rdev);
- size += rdev->vm_manager.max_pfn * 8;
- size *= 2;
- r = radeon_sa_bo_manager_init(rdev,
&rdev->vm_manager.sa_manager,
- RADEON_GPU_PAGE_ALIGN(size),
- RADEON_VM_PTB_ALIGN_SIZE,
- RADEON_GEM_DOMAIN_VRAM);
- if (r) {
- dev_err(rdev->dev, "failed to allocate vm bo (%dKB)\n",
- (rdev->vm_manager.max_pfn * 8) >> 10);
- return r;
- }
-
- r = radeon_asic_vm_init(rdev);
- if (r)
- return r;
-
- rdev->vm_manager.enabled = true;
-
- r = radeon_sa_bo_manager_start(rdev,
&rdev->vm_manager.sa_manager);
- if (r)
- return r;
- }
-
- /* restore page table */
- list_for_each_entry(vm, &rdev->vm_manager.lru_vm, list) {
- if (vm->page_directory == NULL)
- continue;
-
- list_for_each_entry(bo_va, &vm->va, vm_list) {
- bo_va->valid = false;
- }
- }
- return 0;
-}
-
-/**
- * rad
[RFC PATCH v3 1/9] staging: imx-drm-core: don't request probe deferral in imx_drm_encoder_parse_of
Am Montag, den 24.02.2014, 17:06 + schrieb Russell King - ARM Linux: > On Mon, Feb 24, 2014 at 05:56:38PM +0100, Philipp Zabel wrote: > > Am Montag, den 24.02.2014, 15:49 + schrieb Russell King - ARM Linux: > > One issue was that the DT parsing code would try to add the imx-ldb > > component right after the first crtc, and then its bind would fail > > in imx_drm_encoder_parse_of because the three remaining crtcs were > > not yet registered. This is already fixed by adding the crtc > > components first. > > That's what happens anyway - we add /all/ the CRTCs first before we > start adding the connectors. Yes, I know. I accidentally removed that feature when I switched to parsing the OF graph instead of the crtcs and encoder properties, but I've fixed this again in v3 without moving this patch out of the way. regards Philipp
[RFC PATCH v3 2/9] staging: imx-drm: Add temporary copies of v4l2-of parsing functions
Am Montag, den 24.02.2014, 15:52 + schrieb Russell King - ARM Linux: > On Tue, Feb 18, 2014 at 12:36:03PM +0100, Philipp Zabel wrote: > > From: Philipp Zabel > > > > The existing v4l2-of parser functions for the video interface bindings > > described in Documentation/device-tree/bindings/media/video-interfaces.txt > > are useful for DRM drivers, too. They will be moved to drivers/media > > so they can be used by drm drivers, too. Until then, duplicate the > > v4l2-of parser functions temporarily. > > > > Signed-off-by: Philipp Zabel > > Ergh. So, because we can't get agreement on where to put the common > helpers, we have to put up with adding duplicate helpers into the > staging directory, inflating not only the kernel source code size > but also the binary size as well. This part is only for the convenience of prospective reviewers/testers. I hope I don't have exhausted your patience at this patch, because the real changes start at 3/9. This is one reason why I still didn't drop the RFC. Basically, with so many moving parts, I didn't feel like telling people to fetch three different series just to make sense of this one. > Come on people, get agreement on how to deal with this. Staging may > be a dumping ground for drivers which aren't ready to be merged as > proper drivers, but this is no reason to ignore proper process. > > Do we, or do we not want to get imx-drm out of drivers/staging? If > we do, the only way that's going to happen is if we stop throwing in > this kind of stuff. regards Philipp
[PATCH v2 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
On Mon, Feb 24, 2014 at 09:11:43PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> With this patch we allow larger cursor planes of sizes 128x128
> and 256x256.
>
> v2: Added more precise check on size while setting cursor plane.
>
> Testcase: igt/kms_cursor_crc
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: G, Pallavi
> Signed-off-by: Sagar Kamble
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_display.c | 28 +++-
> 2 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2f564ce..2fee3a2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3522,7 +3522,11 @@
> /* New style CUR*CNTR flags */
> #define CURSOR_MODE0x27
> #define CURSOR_MODE_DISABLE 0x00
> +#define CURSOR_MODE_128_32B_AX 0x02
> +#define CURSOR_MODE_256_32B_AX 0x03
> #define CURSOR_MODE_64_32B_AX 0x07
> +#define CURSOR_MODE_128_ARGB_AX ((1 << 5) | CURSOR_MODE_128_32B_AX)
> +#define CURSOR_MODE_256_ARGB_AX ((1 << 5) | CURSOR_MODE_256_32B_AX)
> #define CURSOR_MODE_64_ARGB_AX ((1 << 5) | CURSOR_MODE_64_32B_AX)
> #define MCURSOR_PIPE_SELECT(1 << 28)
> #define MCURSOR_PIPE_A 0x00
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f19e6ea..d036b41 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7411,10 +7411,18 @@ static void i9xx_update_cursor(struct drm_crtc *crtc,
> u32 base)
> bool visible = base != 0;
>
> if (intel_crtc->cursor_visible != visible) {
> + int16_t width = intel_crtc->cursor_width;
> uint32_t cntl = I915_READ(CURCNTR(pipe));
> if (base) {
> cntl &= ~(CURSOR_MODE | MCURSOR_PIPE_SELECT);
> - cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
> +
> + if (width == 64)
> + cntl |= CURSOR_MODE_64_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + else if (width == 128)
> + cntl |= CURSOR_MODE_128_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + else if (width == 256)
> + cntl |= CURSOR_MODE_256_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
A switch statement might be a bit clearer.
> +
> cntl |= pipe << 28; /* Connect to correct pipe */
> } else {
> cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
> @@ -7439,10 +7447,17 @@ static void ivb_update_cursor(struct drm_crtc *crtc,
> u32 base)
> bool visible = base != 0;
>
> if (intel_crtc->cursor_visible != visible) {
> + int16_t width = intel_crtc->cursor_width;
> uint32_t cntl = I915_READ(CURCNTR_IVB(pipe));
> if (base) {
> cntl &= ~CURSOR_MODE;
> - cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
> +
> + if (width == 64)
> + cntl |= CURSOR_MODE_64_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + else if (width == 128)
> + cntl |= CURSOR_MODE_128_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + else if (width == 256)
> + cntl |= CURSOR_MODE_256_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
ditto.
> } else {
> cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
> cntl |= CURSOR_MODE_DISABLE;
> @@ -7538,9 +7553,12 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
> goto finish;
> }
>
> - /* Currently we only support 64x64 cursors */
> - if (width != 64 || height != 64) {
> - DRM_ERROR("we currently only support 64x64 cursors\n");
> + /* Check for which cursor types we support */
> + if ((!(width == 64 && height == 64) && IS_GEN2(dev)) ||
> + (!(width == 64 && height == 64)
> + && !(width == 128 && height == 128)
> + && !(width == 256 && height == 256))) {
I'd make this something like:
if (!((width == 64 && height == 64) ||
(width == 128 && height == 128 && !IS_GEN2(dev)) ||
(width == 256 && height == 256 && !IS_GEN2(dev
> + DRM_ERROR("Cursor dimension is not supported\n");
Should be DRM_DEBUG() or something. Otherwise the user can spam dmesg
by just issuing invalid cursor ioctls.
I see we have a bunch of other DRM_ERROR()s for similar stuff in the
cursor code. Those should be converted to debugs as well. Maybe you
can whip together another patch for that?
> return -EINVAL;
> }
>
> --
> 1.8.5
>
> ___
> d
[RFC PATCH v3 1/9] staging: imx-drm-core: don't request probe deferral in imx_drm_encoder_parse_of
Am Montag, den 24.02.2014, 17:56 +0100 schrieb Philipp Zabel: > Am Montag, den 24.02.2014, 15:49 + schrieb Russell King - ARM Linux: > > On Tue, Feb 18, 2014 at 12:36:02PM +0100, Philipp Zabel wrote: > > > From: Lucas Stach > > > > > > Since imx_drm_encoder_parse_of is called from the encoder bind callbacks, > > > it is too late to request probe deferral. Rather the core should make sure > > > that the crtcs are bound before the encoders, after all needed components > > > are probed. > > > > Why is it too late? -EPROBE_DEFER from this point will cause the driver > > initialisation to correctly unwind and return -EPROBE_DEFER to the > > last-to-be-added component. > > Hmm, you are right. I have conflated two separate issues here. I'll back > that out. > > > > This fixes probe failure when using the LDB on i.MX6. > > > > More details please. > > One issue was that the DT parsing code would try to add the imx-ldb > component right after the first crtc, and then its bind would fail > in imx_drm_encoder_parse_of because the three remaining crtcs were > not yet registered. This is already fixed by adding the crtc > components first. On second thought, now that the crtcs are all bound before the encoders, we'll never even reach this point until all crtcs are available. regards Philipp
[RFC PATCH v3 1/9] staging: imx-drm-core: don't request probe deferral in imx_drm_encoder_parse_of
Am Montag, den 24.02.2014, 15:49 + schrieb Russell King - ARM Linux: > On Tue, Feb 18, 2014 at 12:36:02PM +0100, Philipp Zabel wrote: > > From: Lucas Stach > > > > Since imx_drm_encoder_parse_of is called from the encoder bind callbacks, > > it is too late to request probe deferral. Rather the core should make sure > > that the crtcs are bound before the encoders, after all needed components > > are probed. > > Why is it too late? -EPROBE_DEFER from this point will cause the driver > initialisation to correctly unwind and return -EPROBE_DEFER to the > last-to-be-added component. Hmm, you are right. I have conflated two separate issues here. I'll back that out. > > This fixes probe failure when using the LDB on i.MX6. > > More details please. One issue was that the DT parsing code would try to add the imx-ldb component right after the first crtc, and then its bind would fail in imx_drm_encoder_parse_of because the three remaining crtcs were not yet registered. This is already fixed by adding the crtc components first. The other issue is that once we add bridges that also have output ports, imx_drm_encoder_parse_of needs to skip those. thanks Philipp
[Bug 75211] radeonsi/llvm SIGABRT in Antichamber (UDK)
https://bugs.freedesktop.org/show_bug.cgi?id=75211 --- Comment #5 from Tom Stellard --- Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=94675 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/a5ce5223/attachment.html>
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 --- Comment #3 from Tom Stellard --- Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=94675 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/1c83ae46/attachment.html>
[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation
https://bugs.freedesktop.org/show_bug.cgi?id=73320 --- Comment #11 from Tom Stellard --- Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=94675 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/7dcd8cc4/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #1 from Tom Stellard --- Created attachment 94675 --> https://bugs.freedesktop.org/attachment.cgi?id=94675&action=edit SGPR spilling fix Some of these crashed may be caused by a bug in SGPR spilling rather than lack of VGPR spilling. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/288cbb11/attachment.html>
[PATCH 0/6] Radeon memory management improvements
Hi Marek, Some minor comments on patch 1, 2 and 5, but nothing serious. Patch 3, 4 and 6 are Reviewed-by: christian K?nig See below for a few in line comments. Am 24.02.2014 16:20, schrieb Marek Ol??k: > This series improves performance for the cases when there is not enough VRAM > for all buffers. > > First of all, I'd like to mention that if you set both VRAM and GTT domains > for a buffer, you pretty much say you don't care where the buffer ends up. It > usually makes the performance even worse. > > This work was largely benchmark-driven and I tried a lot of ideas before I > found out which ones work. The patches describe what they do and they're > quite simple, so I'll just share the results here. > > > Card: Evergreen Redwood (HD 5670), 512 MB of VRAM > Test: Unigine Heaven 4.0, High settings > > 1) 1280x720, 4x MSAA, need 525 MB of VRAM > > Without patches: 16.6 FPS > With patches: 16.6 FPS > Improvement: 0 % > > 2) 1600x900, 4x MSAA, need 642 MB of VRAM > > Without patches: 7.1 FPS > With patches: 9.7 FPS > Improvement: 36 % > > 3) 1920x1080, 4x MSAA, need 743 MB of VRAM > > Without patches: 3.7 FPS > With patches: 5.6 FPS > Improvement: 51 % > > 4) 1600x900, 8x MSAA, need 838 MB of VRAM > Without patches: 2.9 FPS > With patches: 4.6 FPS > Improvement: 58 % > > These results don't change if you run the benchmark several times, which > proves the improvement is stable. > > > To conclude this, here are ideas for future work: > > 1) Add virtual memory support for VRAM. Our GPUs support virtual memory, > which not only solves fragmentation issues, but it also allows each buffer to > be partially in VRAM and partially in GTT, which becomes more important with > large buffers like 100 MB. Moving whole buffers back and forth between VRAM > and GTT is inefficient if you can do it at page granularity. Also, due to > fragmentation, we can never really use all of VRAM, but only about 90-95%. Yeah, I'm also thinking about this for quite some time now. The basic problem is that while our GPUs support VM they don't support faulting pages in and continuing (at least nobody got that working reliable so far). E.g. when you hit a page fault you can't relocate the page and then continue. Support for partially resident textures on newer hardware currently works by splitting the buffer up into smaller buffers in userspace and then actively checking in the shader if we hit a buffer that's not currently in memory, but that's not really applicable in the general use case (to much shader overhead). > 2) Add support for uncached GTT. I think it should improve performance for > dGPUs under memory pressure, but some testing needs to be done to confirm > that. Uncached GTT doesn't seem to work for me on Evergreen, but it's said to > be working on some later chips. Did you try to make the whole GTT uncached or just evicted BOs? Making the whole GTT uncached probably won't work out of the box, but avoiding setting the "SNOOPED" flag on those pages might get us better performance while swapping them into VRAM again. Christian. > > The patches for Mesa will follow later today. Please review. > > Marek > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] dma-buf: add poll support, v3
Thanks to Fengguang Wu for spotting a missing static cast.
v2:
- Kill unused variable need_shared.
v3:
- Clarify the BUG() in dma_buf_release some more. (Rob Clark)
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-buf.c | 108 +++
include/linux/dma-buf.h | 12 +
2 files changed, 120 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 65d0f6201db4..84a9d0b66c99 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
static inline int is_dma_buf_file(struct file *);
@@ -52,6 +53,16 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
BUG_ON(dmabuf->vmapping_counter);
+ /*
+* Any fences that a dma-buf poll can wait on should be signaled
+* before releasing dma-buf. This is the responsibility of each
+* driver that uses the reservation objects.
+*
+* If you hit this BUG() it means someone dropped their ref to the
+* dma-buf while still having pending operation to the buffer.
+*/
+ BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
+
dmabuf->ops->release(dmabuf);
mutex_lock(&db_list.lock);
@@ -108,10 +119,103 @@ static loff_t dma_buf_llseek(struct file *file, loff_t
offset, int whence)
return base + offset;
}
+static void dma_buf_poll_cb(struct fence *fence, struct fence_cb *cb)
+{
+ struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dcb->poll->lock, flags);
+ wake_up_locked_poll(dcb->poll, dcb->active);
+ dcb->active = 0;
+ spin_unlock_irqrestore(&dcb->poll->lock, flags);
+}
+
+static unsigned int dma_buf_poll(struct file *file, poll_table *poll)
+{
+ struct dma_buf *dmabuf;
+ struct reservation_object *resv;
+ unsigned long events;
+
+ dmabuf = file->private_data;
+ if (!dmabuf || !dmabuf->resv)
+ return POLLERR;
+
+ resv = dmabuf->resv;
+
+ poll_wait(file, &dmabuf->poll, poll);
+
+ events = poll_requested_events(poll) & (POLLIN | POLLOUT);
+ if (!events)
+ return 0;
+
+ ww_mutex_lock(&resv->lock, NULL);
+
+ if (resv->fence_excl && (!(events & POLLOUT) ||
+resv->fence_shared_count == 0)) {
+ struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl;
+ unsigned long pevents = POLLIN;
+
+ if (resv->fence_shared_count == 0)
+ pevents |= POLLOUT;
+
+ spin_lock_irq(&dmabuf->poll.lock);
+ if (dcb->active) {
+ dcb->active |= pevents;
+ events &= ~pevents;
+ } else
+ dcb->active = pevents;
+ spin_unlock_irq(&dmabuf->poll.lock);
+
+ if (events & pevents) {
+ if (!fence_add_callback(resv->fence_excl,
+ &dcb->cb, dma_buf_poll_cb))
+ events &= ~pevents;
+ else
+ /*
+* No callback queued, wake up any additional
+* waiters.
+*/
+ dma_buf_poll_cb(NULL, &dcb->cb);
+ }
+ }
+
+ if ((events & POLLOUT) && resv->fence_shared_count > 0) {
+ struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_shared;
+ int i;
+
+ /* Only queue a new callback if no event has fired yet */
+ spin_lock_irq(&dmabuf->poll.lock);
+ if (dcb->active)
+ events &= ~POLLOUT;
+ else
+ dcb->active = POLLOUT;
+ spin_unlock_irq(&dmabuf->poll.lock);
+
+ if (!(events & POLLOUT))
+ goto out;
+
+ for (i = 0; i < resv->fence_shared_count; ++i)
+ if (!fence_add_callback(resv->fence_shared[i],
+ &dcb->cb, dma_buf_poll_cb)) {
+ events &= ~POLLOUT;
+ break;
+ }
+
+ /* No callback queued, wake up any additional waiters. */
+ if (i == resv->fence_shared_count)
+ dma_buf_poll_cb(NULL, &dcb->cb);
+ }
+
+out:
+ ww_mutex_unlock(&resv->lock);
+ return events;
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
+ .poll = dma_buf_poll,
};
/*
@@ -171,6 +275,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_
[PATCH 5/6] reservation: add support for fences to enable cross-device synchronisation
Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark
---
include/linux/reservation.h | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..f3f57460a205 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -6,7 +6,7 @@
* Copyright (C) 2012 Texas Instruments
*
* Authors:
- * Rob Clark
+ * Rob Clark
* Maarten Lankhorst
* Thomas Hellstrom
*
@@ -40,22 +40,40 @@
#define _LINUX_RESERVATION_H
#include
+#include
+#include
extern struct ww_class reservation_ww_class;
struct reservation_object {
struct ww_mutex lock;
+
+ struct fence *fence_excl;
+ struct fence **fence_shared;
+ u32 fence_shared_count, fence_shared_max;
};
static inline void
reservation_object_init(struct reservation_object *obj)
{
ww_mutex_init(&obj->lock, &reservation_ww_class);
+
+ obj->fence_shared_count = obj->fence_shared_max = 0;
+ obj->fence_shared = NULL;
+ obj->fence_excl = NULL;
}
static inline void
reservation_object_fini(struct reservation_object *obj)
{
+ int i;
+
+ if (obj->fence_excl)
+ fence_put(obj->fence_excl);
+ for (i = 0; i < obj->fence_shared_count; ++i)
+ fence_put(obj->fence_shared[i]);
+ kfree(obj->fence_shared);
+
ww_mutex_destroy(&obj->lock);
}
[PATCH 4/6] android: convert sync to fence api, v5
Just to show it's easy.
Android syncpoints can be mapped to a timeline. This removes the need
to maintain a separate api for synchronization. I've left the android
trace events in place, but the core fence events should already be
sufficient for debugging.
v2:
- Call fence_remove_callback in sync_fence_free if not all fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.
v5:
- Fix small style issues pointed out by Thomas Hellstrom.
Signed-off-by: Maarten Lankhorst
---
drivers/staging/android/Kconfig |1
drivers/staging/android/Makefile |2
drivers/staging/android/sw_sync.c|4
drivers/staging/android/sync.c | 903 --
drivers/staging/android/sync.h | 82 ++-
drivers/staging/android/sync_debug.c | 247 +
drivers/staging/android/trace/sync.h | 12
7 files changed, 611 insertions(+), 640 deletions(-)
create mode 100644 drivers/staging/android/sync_debug.c
diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index b91c758883bf..ecc8194242b5 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -77,6 +77,7 @@ config SYNC
bool "Synchronization framework"
default n
select ANON_INODES
+ select DMA_SHARED_BUFFER
---help---
This option enables the framework for synchronization between multiple
drivers. Sync implementations can take advantage of hardware
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 0a01e1914905..517ad5ffa429 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -9,5 +9,5 @@ obj-$(CONFIG_ANDROID_TIMED_OUTPUT) += timed_output.o
obj-$(CONFIG_ANDROID_TIMED_GPIO) += timed_gpio.o
obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
obj-$(CONFIG_ANDROID_INTF_ALARM_DEV) += alarm-dev.o
-obj-$(CONFIG_SYNC) += sync.o
+obj-$(CONFIG_SYNC) += sync.o sync_debug.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index f24493ac65e3..a76db3ff87cb 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -50,7 +50,7 @@ static struct sync_pt *sw_sync_pt_dup(struct sync_pt *sync_pt)
{
struct sw_sync_pt *pt = (struct sw_sync_pt *) sync_pt;
struct sw_sync_timeline *obj =
- (struct sw_sync_timeline *)sync_pt->parent;
+ (struct sw_sync_timeline *)sync_pt_parent(sync_pt);
return (struct sync_pt *) sw_sync_pt_create(obj, pt->value);
}
@@ -59,7 +59,7 @@ static int sw_sync_pt_has_signaled(struct sync_pt *sync_pt)
{
struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
struct sw_sync_timeline *obj =
- (struct sw_sync_timeline *)sync_pt->parent;
+ (struct sw_sync_timeline *)sync_pt_parent(sync_pt);
return sw_sync_cmp(obj->value, pt->value) >= 0;
}
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3d05f662110b..b2254e5a8b70 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -31,22 +31,13 @@
#define CREATE_TRACE_POINTS
#include "trace/sync.h"
-static void sync_fence_signal_pt(struct sync_pt *pt);
-static int _sync_pt_has_signaled(struct sync_pt *pt);
-static void sync_fence_free(struct kref *kref);
-static void sync_dump(void);
-
-static LIST_HEAD(sync_timeline_list_head);
-static DEFINE_SPINLOCK(sync_timeline_list_lock);
-
-static LIST_HEAD(sync_fence_list_head);
-static DEFINE_SPINLOCK(sync_fence_list_lock);
+static const struct fence_ops android_fence_ops;
+static const struct file_operations sync_fence_fops;
struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
int size, const char *name)
{
struct sync_timeline *obj;
- unsigned long flags;
if (size < sizeof(struct sync_timeline))
return NULL;
@@ -57,17 +48,14 @@ struct sync_timeline *sync_timeline_create(const struct
sync_timeline_ops *ops,
kref_init(&obj->kref);
obj->ops = ops;
+ obj->context = fence_context_alloc(1);
strlcpy(obj->name, name, sizeof(obj->name));
INIT_LIST_HEAD(&obj->child_list_head);
- spin_lock_init(&obj->child_list_lock);
-
INIT_LIST_HEAD(&obj->active_list_head);
- spin_lock_init(&obj->active_list_lock);
+ spin_lock_init(&obj->child_list_lock);
- spin_lock_irqsave(&sync_timeline_list_lock, flags);
- list_add_tail(&obj->sync_timeline_list, &sync_timeline_list_head);
- spin_unlock_irqrestore(&sync_timeline_list_lock, flags);
+ sync_timeline_debug_add(obj);
return obj;
}
@@ -77,11 +65,8 @@ static void sync_timeline_free(struct kref *
[PATCH 3/6] dma-buf: use reservation objects
This allows reservation objects to be used in dma-buf. it's required
for implementing polling support on the fences that belong to a dma-buf.
Signed-off-by: Maarten Lankhorst
Acked-by: Mauro Carvalho Chehab
#drivers/media/v4l2-core/
Acked-by: Thomas Hellstrom #drivers/gpu/drm/ttm
---
drivers/base/dma-buf.c | 22 --
drivers/gpu/drm/drm_prime.c|8 +++-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c |1 +
drivers/gpu/drm/nouveau/nouveau_gem.h |1 +
drivers/gpu/drm/nouveau/nouveau_prime.c|7 +++
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |2 +-
drivers/gpu/drm/radeon/radeon_drv.c|2 ++
drivers/gpu/drm/radeon/radeon_prime.c |8
drivers/gpu/drm/ttm/ttm_object.c |2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
drivers/staging/android/ion/ion.c |2 +-
include/drm/drmP.h |2 ++
include/linux/dma-buf.h|9 ++---
15 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1e16cbd61da2..65d0f6201db4 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -25,10 +25,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
static inline int is_dma_buf_file(struct file *);
@@ -56,6 +58,9 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
list_del(&dmabuf->list_node);
mutex_unlock(&db_list.lock);
+ if (dmabuf->resv == (struct reservation_object *)&dmabuf[1])
+ reservation_object_fini(dmabuf->resv);
+
kfree(dmabuf);
return 0;
}
@@ -128,6 +133,7 @@ static inline int is_dma_buf_file(struct file *file)
* @size: [in]Size of the buffer
* @flags: [in]mode flags for the file.
* @exp_name: [in]name of the exporting module - useful for debugging.
+ * @resv: [in]reservation-object, NULL to allocate default one.
*
* Returns, on success, a newly created dma_buf object, which wraps the
* supplied private data and operations for dma_buf_ops. On either missing
@@ -135,10 +141,17 @@ static inline int is_dma_buf_file(struct file *file)
*
*/
struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
- size_t size, int flags, const char *exp_name)
+ size_t size, int flags, const char *exp_name,
+ struct reservation_object *resv)
{
struct dma_buf *dmabuf;
struct file *file;
+ size_t alloc_size = sizeof(struct dma_buf);
+ if (!resv)
+ alloc_size += sizeof(struct reservation_object);
+ else
+ /* prevent &dma_buf[1] == dma_buf->resv */
+ alloc_size += 1;
if (WARN_ON(!priv || !ops
|| !ops->map_dma_buf
@@ -150,7 +163,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
return ERR_PTR(-EINVAL);
}
- dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
+ dmabuf = kzalloc(alloc_size, GFP_KERNEL);
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
@@ -158,6 +171,11 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;
dmabuf->exp_name = exp_name;
+ if (!resv) {
+ resv = (struct reservation_object *)&dmabuf[1];
+ reservation_object_init(resv);
+ }
+ dmabuf->resv = resv;
file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
if (IS_ERR(file)) {
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 56805c39c906..a13e90245adf 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -318,7 +318,13 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *obj, int flags)
{
- return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, flags);
+ struct reservation_object *robj = NULL;
+
+ if (dev->driver->gem_prime_res_obj)
+ robj = dev->driver->gem_prime_res_obj(obj);
+
+ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
+ flags, robj);
}
EXPORT_SYMBOL(drm_gem_prime_export);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 59827cc5e770..b5e89f46326e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmab
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v5)
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met when WAIT_GEQUAL is used,
or (dma_buf[offset] != 0) has been met when WAIT_NONZERO is set.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
v5: Add condition member to allow wait for != 0.
Fix small style errors pointed out by checkpatch.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Rob Clark #v4
---
Documentation/DocBook/device-drivers.tmpl |1
drivers/base/fence.c | 52 +
include/linux/seqno-fence.h | 119 +
3 files changed, 172 insertions(+)
create mode 100644 include/linux/seqno-fence.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 7a0c9ddb4818..8c85c20942c2 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -131,6 +131,7 @@ X!Edrivers/base/interface.c
!Edrivers/base/dma-buf.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
!Edrivers/base/reservation.c
!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index 12df2bf62034..be33981ba2a2 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -413,3 +414,54 @@ __fence_init(struct fence *fence, const struct fence_ops
*ops,
trace_fence_init(fence);
}
EXPORT_SYMBOL(__fence_init);
+
+static const char *seqno_fence_get_driver_name(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->get_driver_name(fence);
+}
+
+static const char *seqno_fence_get_timeline_name(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->get_timeline_name(fence);
+}
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->signaled && seqno_fence->ops->signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+
+ dma_buf_put(f->sync_buf);
+ if (f->ops->release)
+ f->ops->release(fence);
+ else
+ kfree(f);
+}
+
+static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+ return f->ops->wait(fence, intr, timeout);
+}
+
+const struct fence_ops seqno_fence_ops = {
+ .get_driver_name = seqno_fence_get_driver_name,
+ .get_timeline_name = seqno_fence_get_timeline_name,
+ .enable_signaling = seqno_enable_signaling,
+ .signaled = seqno_signaled,
+ .wait = seqno_wait,
+ .release = seqno_release,
+};
+EXPORT_SYMBOL(seqno_fence_ops);
diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
new file mode 100644
index ..b4d4aad3cadc
--- /dev/null
+++ b/include/linux/seqno-fence.h
@@ -0,0 +1,119 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012 Canonical Ltd
+ * Authors:
+ * Rob Clark
+ * Maarten Lankhorst
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see
[PATCH 1/6] fence: dma-buf cross-device synchronization (v17)
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
+ fence_context_alloc()
A fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence:
+ fence_signal()
To have a rough approximation whether a fence is fired, call:
+ fence_is_signaled()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
The one pending on the fence can add an async callback:
+ fence_add_callback()
The callback can optionally be cancelled with:
+ fence_remove_callback()
To wait synchronously, optionally with a timeout:
+ fence_wait()
+ fence_wait_timeout()
When emitting a fence, call:
+ trace_fence_emit()
To annotate that a fence is blocking on another fence, call:
+ trace_fence_annotate_wait_on(fence, on_fence)
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = custom_get_fence(...);
if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = seqno_fence->sync_buf;
get_dma_buf(fence_buf);
... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
} else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override
[PATCH 0/6] dma-buf synchronization patches (updated)
The following series implements fence and converts dma-buf and android sync to use it. Patch 5 and 6 add support for polling to dma-buf, blocking until all fences are signaled. Patches that received some minor updates: - seqno fence (wait condition member added) - android (whitespace changes and a comment removed) - add poll support to dma-buf (added comment) --- Maarten Lankhorst (6): fence: dma-buf cross-device synchronization (v17) seqno-fence: Hardware dma-buf implementation of fencing (v5) dma-buf: use reservation objects android: convert sync to fence api, v5 reservation: add support for fences to enable cross-device synchronisation dma-buf: add poll support, v3 Documentation/DocBook/device-drivers.tmpl |3 drivers/base/Kconfig |9 drivers/base/Makefile |2 drivers/base/dma-buf.c | 130 +++ drivers/base/fence.c | 467 drivers/gpu/drm/drm_prime.c|8 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 drivers/gpu/drm/nouveau/nouveau_drm.c |1 drivers/gpu/drm/nouveau/nouveau_gem.h |1 drivers/gpu/drm/nouveau/nouveau_prime.c|7 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |2 drivers/gpu/drm/radeon/radeon_drv.c|2 drivers/gpu/drm/radeon/radeon_prime.c |8 drivers/gpu/drm/ttm/ttm_object.c |2 drivers/media/v4l2-core/videobuf2-dma-contig.c |2 drivers/staging/android/Kconfig|1 drivers/staging/android/Makefile |2 drivers/staging/android/ion/ion.c |2 drivers/staging/android/sw_sync.c |4 drivers/staging/android/sync.c | 903 drivers/staging/android/sync.h | 82 +- drivers/staging/android/sync_debug.c | 247 +++ drivers/staging/android/trace/sync.h | 12 include/drm/drmP.h |2 include/linux/dma-buf.h| 21 - include/linux/fence.h | 329 + include/linux/reservation.h| 20 + include/linux/seqno-fence.h| 119 +++ include/trace/events/fence.h | 125 +++ 30 files changed, 1863 insertions(+), 654 deletions(-) create mode 100644 drivers/base/fence.c create mode 100644 drivers/staging/android/sync_debug.c create mode 100644 include/linux/fence.h create mode 100644 include/linux/seqno-fence.h create mode 100644 include/trace/events/fence.h -- Signature
[PATCH 5/6] drm/radeon: validate relocations in the order determined by userspace
Am 24.02.2014 16:20, schrieb Marek Ol??k:
> From: Marek Ol??k
>
> Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to
> a number from 0 to 15. The higher the number, the higher the priority,
> which means a buffer with a higher number will be validated sooner.
Assuming that we only have 32 different priorities it would probably be
better to add the buffers to 32 different lists while evaluating the
priorities in radeon_cs_parser_relocs and then concatenate all 32 lists
at the end instead of sorting them.
>
> The old behavior is preserved: Buffers used for write are prioritized over
> read-only buffers if the userspace doesn't set the number.
>
> Signed-off-by: Marek Ol??k
> ---
> drivers/gpu/drm/radeon/radeon.h| 2 +-
> drivers/gpu/drm/radeon/radeon_cs.c | 53
> --
> drivers/gpu/drm/radeon/radeon_object.c | 10 ---
> drivers/gpu/drm/radeon/radeon_object.h | 2 --
> 4 files changed, 51 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index d37a57a..f7a3174 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -481,7 +481,7 @@ struct radeon_bo_list {
> struct ttm_validate_buffer tv;
> struct radeon_bo*bo;
> uint64_tgpu_offset;
> - boolwritten;
> + unsignedpriority;
> unsigneddomain;
> unsignedalt_domain;
> u32 tiling_flags;
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index d49a3f7..1ba1a48 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -31,6 +31,41 @@
> #include "radeon.h"
> #include "radeon_trace.h"
>
> +/* This is a variation of the bucket sort with O(n) time complexity.
> + * The relocations are sorted from the highest to the lowest priority. */
> +static void sort_relocs_for_validation(struct list_head *list)
> +{
> + struct list_head bucket[17], *it, *tmp;
> + unsigned i, priority;
> +
> + for (i = 0; i < 17; i++)
> + INIT_LIST_HEAD(&bucket[i]);
> +
> + /* Move the elements into buckets. An i-th bucket only contains
> + * elements with priorities i*2 and i*2+1. Odd numbers are added
> + * at the head of a bucket and even numbers are added at the tail,
> + * therefore all buckets are always sorted. */
> + list_for_each_safe(it, tmp, list) {
> + priority = list_entry(it, struct radeon_bo_list,
> + tv.head)->priority;
> + i = priority / 2;
> + i = min(i, 16u) ;
> +
> + if (priority % 2 == 1) {
> + list_move(it, &bucket[i]);
> + } else {
> + list_move_tail(it, &bucket[i]);
> + }
> + }
> +
> + INIT_LIST_HEAD(list);
> +
> + /* connect the sorted buckets */
> + for (i = 0; i < 17; i++) {
> + list_splice(&bucket[i], list);
> + }
> +}
> +
> static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
> {
> struct drm_device *ddev = p->rdev->ddev;
> @@ -80,7 +115,15 @@ static int radeon_cs_parser_relocs(struct
> radeon_cs_parser *p)
> p->relocs_ptr[i] = &p->relocs[i];
> p->relocs[i].robj = gem_to_radeon_bo(p->relocs[i].gobj);
> p->relocs[i].lobj.bo = p->relocs[i].robj;
> - p->relocs[i].lobj.written = !!r->write_domain;
> +
> + /* The userspace buffer priorities are from 0 to 15. A higher
> + * number means the buffer is more important.
> + * Also, the buffers used for write have a higher priority than
> + * the buffers used for read only, which doubles the range
> + * to 0 to 31. Numbers 32 and 33 are reserved for the kernel
> + * driver.
> + */
> + p->relocs[i].lobj.priority = (r->flags & 0xf) * 2 +
> !!r->write_domain;
>
> /* the first reloc of an UVD job is the msg and that must be in
> VRAM, also but everything into VRAM on AGP cards to avoid
> @@ -94,6 +137,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
> *p)
> p->relocs[i].lobj.alt_domain =
> RADEON_GEM_DOMAIN_VRAM;
>
> + /* prioritize this over any other relocation */
> + p->relocs[i].lobj.priority = 32;
> } else {
> uint32_t domain = r->write_domain ?
> r->write_domain : r->read_domains;
> @@ -107,9 +152,11 @@ static int radeon_cs_parser_relocs(struct
> radeon_cs_parser *p)
> p->relocs[i].lobj.tv.bo = &p->relocs[i].robj->tbo;
> p->relocs[i].handle = r->handle;
>
> - radeon_b
Info: mapping multiple BARs. Your kernel is fine.
This started happening this morning after booting -rc4+tip, let's add *everybody* to CC :-) We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and other goodies on the stack. ... [0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at [8800cac3-8800cec2] [0.489975] resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1 0xfed13fff pnp 00:01 [0.490079] [ cut here ] [0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() [0.490306] Info: mapping multiple BARs. Your kernel is fine. [0.490371] Modules linked in: [0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1 [0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012 [0.490742] 00ab 880213d01ad8 816112e3 0006 [0.491032] 880213d01b28 880213d01b18 8104e9bc 880213d01b08 [0.491343] c9c58000 fed1 fed1 6000 [0.491631] Call Trace: [0.493337] [] dump_stack+0x4f/0x7c [0.493420] [] warn_slowpath_common+0x8c/0xc0 [0.493503] [] warn_slowpath_fmt+0x46/0x50 [0.493588] [] __ioremap_caller+0x372/0x380 [0.493674] [] ? snb_uncore_imc_init_box+0x62/0x90 [0.493761] [] ioremap_nocache+0x17/0x20 [0.493846] [] snb_uncore_imc_init_box+0x62/0x90 [0.493933] [] uncore_pci_probe+0xe5/0x1e0 [0.494020] [] local_pci_probe+0x4e/0xa0 [0.494104] [] ? get_device+0x19/0x20 [0.494213] [] pci_device_probe+0xe1/0x130 [0.494300] [] driver_probe_device+0x7b/0x240 [0.494385] [] __driver_attach+0xab/0xb0 [0.494469] [] ? driver_probe_device+0x240/0x240 [0.494551] [] bus_for_each_dev+0x5e/0x90 [0.494634] [] driver_attach+0x1e/0x20 [0.494718] [] bus_add_driver+0x117/0x230 [0.494802] [] driver_register+0x64/0xf0 [0.494884] [] __pci_register_driver+0x64/0x70 [0.494972] [] ? uncore_types_init+0x19c/0x19c [0.495056] [] intel_uncore_init+0x177/0x41c [0.495155] [] ? uncore_types_init+0x19c/0x19c [0.495242] [] do_one_initcall+0x4e/0x170 [0.495326] [] ? parse_args+0x60/0x360 [0.495411] [] kernel_init_freeable+0x106/0x19a [0.495497] [] ? do_early_param+0x86/0x86 [0.495582] [] ? rest_init+0xd0/0xd0 [0.495666] [] kernel_init+0xe/0xf0 [0.495749] [] ret_from_fork+0x7c/0xb0 [0.495831] [] ? rest_init+0xd0/0xd0 [0.495921] ---[ end trace 428f365c054d9a01 ]--- [0.496196] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [0.498598] futex hash table entries: 1024 (order: 5, 131072 bytes) [0.498833] audit: initializing netlink subsys (disabled) [0.499024] audit: type=2000 audit(1393259866.477:1): initialized ... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves
Am 24.02.2014 16:20, schrieb Marek Ol??k:
> From: Marek Ol??k
>
> The statistics are:
> - VRAM usage in bytes
> - GTT usage in bytes
> - number of bytes moved by TTM
>
> The last one is actually a counter, so you need to sample it before and after
> command submission and take the difference.
>
> This is useful for finding performance bottlenecks. Userspace queries are
> also added.
>
> Signed-off-by: Marek Ol??k
> ---
> drivers/gpu/drm/radeon/radeon.h| 5 +
> drivers/gpu/drm/radeon/radeon_device.c | 1 +
> drivers/gpu/drm/radeon/radeon_kms.c| 15 ++
> drivers/gpu/drm/radeon/radeon_object.c | 38
> +-
> drivers/gpu/drm/radeon/radeon_object.h | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 10 -
> include/uapi/drm/radeon_drm.h | 3 +++
> 7 files changed, 71 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 3f10782..d37a57a 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2307,6 +2307,11 @@ struct radeon_device {
> /* virtual memory */
> struct radeon_vm_managervm_manager;
> struct mutexgpu_clock_mutex;
> + /* memory stats */
> + struct mutexmemory_stats_mutex;
> + uint64_tvram_usage;
> + uint64_tgtt_usage;
> + uint64_tnum_bytes_moved;
As far as I can see you could make those tree values atomic64_t instead
and avoid the mutex.
> /* ACPI interface */
> struct radeon_atif atif;
> struct radeon_atcs atcs;
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index b012cbb..6564af7 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1184,6 +1184,7 @@ int radeon_device_init(struct radeon_device *rdev,
> mutex_init(&rdev->gem.mutex);
> mutex_init(&rdev->pm.mutex);
> mutex_init(&rdev->gpu_clock_mutex);
> + mutex_init(&rdev->memory_stats_mutex);
> mutex_init(&rdev->srbm_mutex);
> init_rwsem(&rdev->pm.mclk_lock);
> init_rwsem(&rdev->exclusive_lock);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 0b631eb..ddc8c74 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -486,6 +486,21 @@ static int radeon_info_ioctl(struct drm_device *dev,
> void *data, struct drm_file
> case RADEON_INFO_VCE_FB_VERSION:
> *value = rdev->vce.fb_version;
> break;
> + case RADEON_INFO_NUM_BYTES_MOVED:
> + value = (uint32_t*)&value64;
> + value_size = sizeof(uint64_t);
> + value64 = rdev->num_bytes_moved;
> + break;
> + case RADEON_INFO_VRAM_USAGE:
> + value = (uint32_t*)&value64;
> + value_size = sizeof(uint64_t);
> + value64 = rdev->vram_usage;
> + break;
> + case RADEON_INFO_GTT_USAGE:
> + value = (uint32_t*)&value64;
> + value_size = sizeof(uint64_t);
> + value64 = rdev->gtt_usage;
> + break;
> default:
> DRM_DEBUG_KMS("Invalid request %d\n", info->request);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index dd12bb4..d676ee2 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -56,11 +56,38 @@ static void radeon_bo_clear_va(struct radeon_bo *bo)
> }
> }
>
> +static void radeon_update_memory_usage(struct radeon_bo *bo,
> +unsigned mem_type, int sign)
> +{
> + struct radeon_device *rdev = bo->rdev;
> + u64 size = (u64)bo->tbo.num_pages << PAGE_SHIFT;
> +
> + mutex_lock(&rdev->memory_stats_mutex);
> + switch (mem_type) {
> + case TTM_PL_TT:
> + if (sign > 0)
> + rdev->gtt_usage += size;
> + else
> + rdev->gtt_usage -= size;
> + break;
> + case TTM_PL_VRAM:
> + if (sign > 0)
> + rdev->vram_usage += size;
> + else
> + rdev->vram_usage -= size;
> + break;
> + }
> + mutex_unlock(&rdev->memory_stats_mutex);
> +}
> +
> static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo)
> {
> struct radeon_bo *bo;
>
> bo = container_of(tbo, struct radeon_bo, tbo);
> +
> + radeon_update_memory_usage(bo, bo->tbo.mem.mem_type, -1);
> +
> mutex_lock(&bo->rdev->gem.mutex);
> list_del_init(&bo->list);
> mutex_unlock(&bo->rdev->gem.mutex);
> @@ -567,14 +594,23 @@ int radeon_bo_check_tiling(struct radeon_
[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains
Am 24.02.2014 16:20, schrieb Marek Ol??k:
> From: Marek Ol??k
>
> When passing buffers between processes, the receiving process needs to know
> the original buffer domain, so that it doesn't accidentally move the buffer.
>
> Signed-off-by: Marek Ol??k
> ---
> drivers/gpu/drm/radeon/radeon.h| 3 +++
> drivers/gpu/drm/radeon/radeon_drv.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_gem.c| 30 ++
> drivers/gpu/drm/radeon/radeon_kms.c| 1 +
> drivers/gpu/drm/radeon/radeon_object.c | 3 +++
> include/uapi/drm/radeon_drm.h | 12
> 6 files changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index a415f8e..3f10782 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -454,6 +454,7 @@ struct radeon_bo {
> /* Protected by gem.mutex */
> struct list_headlist;
> /* Protected by tbo.reserved */
> + u32 initial_domain;
> u32 placements[3];
> struct ttm_placementplacement;
> struct ttm_buffer_objecttbo;
> @@ -2114,6 +2115,8 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
> void *data,
> struct drm_file *filp);
> int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
> struct drm_file *filp);
> +int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *filp);
> int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file
> *filp);
> int radeon_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
> struct drm_file *filp);
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 84a1bbb7..4392b7c 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -79,9 +79,10 @@
>* 2.35.0 - Add CIK macrotile mode array query
>* 2.36.0 - Fix CIK DCE tiling setup
>* 2.37.0 - allow GS ring setup on r6xx/r7xx
> + * 2.38.0 - RADEON_GEM_OP (GET_INITIAL_DOMAIN, SET_INITIAL_DOMAIN)
>*/
> #define KMS_DRIVER_MAJOR2
> -#define KMS_DRIVER_MINOR 37
> +#define KMS_DRIVER_MINOR 38
> #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 b96c819..d7890f2 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -533,6 +533,36 @@ out:
> return r;
> }
>
> +int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *filp)
> +{
> + struct drm_radeon_gem_op *args = data;
> + struct drm_gem_object *gobj;
> + struct radeon_bo *robj;
> +
> + gobj = drm_gem_object_lookup(dev, filp, args->handle);
> + if (gobj == NULL) {
> + return -ENOENT;
> + }
> + robj = gem_to_radeon_bo(gobj);
> +
When the comment is correct and initial_domain is protected by reserving
the BO you should actually reserve/unreserve it here. On the other hand
locking might not be necessary.
> + switch (args->op) {
> + case RADEON_GEM_OP_GET_INITIAL_DOMAIN:
> + args->value = robj->initial_domain;
> + break;
> + case RADEON_GEM_OP_SET_INITIAL_DOMAIN:
> + robj->initial_domain = args->value & (RADEON_GEM_DOMAIN_VRAM |
> + RADEON_GEM_DOMAIN_GTT |
> + RADEON_GEM_DOMAIN_CPU);
> + break;
> + default:
> + ; /* do nothing */
Should probably return -EINVAL here.
> + }
> +
> + drm_gem_object_unreference_unlocked(gobj);
> + return 0;
> +}
> +
> int radeon_mode_dumb_create(struct drm_file *file_priv,
> struct drm_device *dev,
> struct drm_mode_create_dumb *args)
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index baff98b..0b631eb 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -814,5 +814,6 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
> DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl,
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl,
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl,
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(RADEON_GEM_OP, radeon_gem_op_ioctl,
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> };
> int radeon_max_kms_ioctl = DR
[RFC PATCH v3 1/9] staging: imx-drm-core: don't request probe deferral in imx_drm_encoder_parse_of
On Mon, Feb 24, 2014 at 05:56:38PM +0100, Philipp Zabel wrote: > Am Montag, den 24.02.2014, 15:49 + schrieb Russell King - ARM Linux: > One issue was that the DT parsing code would try to add the imx-ldb > component right after the first crtc, and then its bind would fail > in imx_drm_encoder_parse_of because the three remaining crtcs were > not yet registered. This is already fixed by adding the crtc > components first. That's what happens anyway - we add /all/ the CRTCs first before we start adding the connectors. That means the CRTCs will be bound before the connectors (ldb). What you're probably missing is that with what's in my branch, if you want both CRTCs or the second CRTC in the IPU pair, you must specify both in the "crtcs" property - iow "crtcs = <&ipuX 0>, <&ipuX 1>". The reason is there's no way to differentiate the individual platform devices there without delving into the platform data. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
GBM surface sharing
Hi... We are trying for a client/ server graphic application without using X11/ Wayland. Whether it's possible to create gbm surface in client and render using drm in server? (share the buffer between processes) We had tried to do so, server is getting crashed when accessing the gbm surface created by client. Regards, Binoy. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/eadf4ba6/attachment-0001.html>
[RFC PATCH v3 0/9] imx-drm dt bindings
Am Dienstag, den 18.02.2014, 12:36 +0100 schrieb Philipp Zabel: > Hi, > > here is an updated and more complete version of the imx-drm DT binding > series. These patches apply on top of Russell's second preview of the > imx-drm cleanup series on v3.14-rc2. I have added device tree bindings > between IPU and the encoders as documented in > Documentation/devicetree/bindings/media/video-interfaces.txt > and used those to determine the possible_crtcs and mux_id. > > The crtc cookie is replaced with a the port device tree node, > which is unique and therefore allows to get rid of the di_id > comparison. Storing the multiplexer input numbers in the device > tree removes the need to know the ipu_id. This should also allow > to replace IPU2 with LCDIF on i.MX6 Solo more easily. > > In v3 also connections between display interface ports and encoders are > used to find all necessary components, so that only the display interfaces > have to be configured in the imx-drm node. This allows to move the imx-drm > node into the SoC level dtsi. I've also updated the existing i.MX51 and > i.MX53 device trees this time and updated/added the devicetree binding > documentation. > > Patch 2/9 adds a temporary copy of the v4l2_of parser functions. Those > are going to be moved to some place where they can be used by drm drivers, > eventually, so those local copies can be dropped again. Russell has sent a pull request for the imx-drm component support series now, and we're at v3.13-rc4 already. This patch series still applies on top of git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging I'd appreciate some feedback on this. Or shall I resend without the RFC? regards Philipp > regards > Philipp > > Lucas Stach (1): > staging: imx-drm-core: don't request probe deferral in > imx_drm_encoder_parse_of > > Philipp Zabel (8): > staging: imx-drm: Add temporary copies of v4l2-of parsing functions > staging: imx-drm-core: Use OF graph to find components and connections > between encoder and crtcs > staging: imx-drm: Document updated imx-drm device tree bindings > staging: imx-drm: Document imx-hdmi device tree bindings > ARM: dts: imx51: Add IPU ports and endpoints, move imx-drm node to > dtsi > ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to > dtsi > ARM: dts: imx6qdl: Add IPU DI ports and endpoints, move imx-drm node > to dtsi > staging: imx-drm: Update TODO > > .../bindings/staging/imx-drm/fsl-imx-drm.txt | 48 - > .../devicetree/bindings/staging/imx-drm/hdmi.txt | 53 + > .../devicetree/bindings/staging/imx-drm/ldb.txt| 20 +- > arch/arm/boot/dts/imx51-apf51dev.dts | 11 +- > arch/arm/boot/dts/imx51-babbage.dts| 28 ++- > arch/arm/boot/dts/imx51.dtsi | 22 ++- > arch/arm/boot/dts/imx53-m53evk.dts | 17 +- > arch/arm/boot/dts/imx53-mba53.dts | 15 +- > arch/arm/boot/dts/imx53-qsb.dts| 17 +- > arch/arm/boot/dts/imx53.dtsi | 64 +- > arch/arm/boot/dts/imx6dl.dtsi | 22 +-- > arch/arm/boot/dts/imx6q-sabresd.dts| 4 - > arch/arm/boot/dts/imx6q.dtsi | 124 +++- > arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 6 - > arch/arm/boot/dts/imx6qdl.dtsi | 138 - > drivers/staging/imx-drm/Makefile | 2 +- > drivers/staging/imx-drm/TODO | 5 - > drivers/staging/imx-drm/imx-drm-core.c | 217 > ++--- > drivers/staging/imx-drm/imx-drm-of.c | 132 + > drivers/staging/imx-drm/imx-drm.h | 11 +- > drivers/staging/imx-drm/imx-hdmi.c | 2 +- > drivers/staging/imx-drm/imx-ldb.c | 4 +- > drivers/staging/imx-drm/ipuv3-crtc.c | 47 - > 23 files changed, 842 insertions(+), 167 deletions(-) > create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt > create mode 100644 drivers/staging/imx-drm/imx-drm-of.c >
[Bug 75361] freeze in Mass Effect 3 (wine)
https://bugs.freedesktop.org/show_bug.cgi?id=75361 --- Comment #7 from wdr --- apitrace dump (600Mb in tar.bz2 archive) https://bft.usu.edu/xkb8y -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/8e2128b1/attachment.html>
[Bug 75453] New: i915/DRM Gallium driver apparently not usable without DRM pipe loader
https://bugs.freedesktop.org/show_bug.cgi?id=75453 Priority: medium Bug ID: 75453 Assignee: dri-devel at lists.freedesktop.org Summary: i915/DRM Gallium driver apparently not usable without DRM pipe loader Severity: normal Classification: Unclassified OS: All Reporter: christian.prochaska at genode-labs.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/i915g Product: Mesa (git master 73b46136b0ba20f7f84abdadad895111a4c37166) I've built Mesa with the following configuration: ./autogen.sh --enable-gles2 --disable-glx --with-dri-drivers= --enable-gallium-egl --with-egl-platforms=drm --with-gallium-drivers=i915 With this configuration, both a DRI driver and a Gallium driver get built, despite the --with-dri-drivers= configure option (bug or intended?). Then I've built the 'es2gears' demo as follows: gcc -g -O0 -DMESA_EGL_NO_X11_HEADERS -o es2gears es2gears.c ../eglut/eglut_screen.c ../eglut/eglut.c -I../eglut -lGLESv2 -lEGL -lm When I tried to run it on an IBM T60 notebook (Debian testing), at first bug 75335 triggered. Now that this bug has been resolved, the following error occured: - EGL_VERSION = 1.4 (DRI2) EGLUT: failed to choose a config - When I deleted the DRI driver, the following error occured: - gbm: failed to open any driver (search paths /usr/local/lib/dri)failed to load driver: i915 gbm: failed to open any driver (search paths /usr/local/lib/dri)failed to load driver: i915 gbm: failed to open any driver (search paths /usr/local/lib/dri)failed to load driver: i915 EGLUT: failed to initialize EGL display - Apparently, the Gallium driver was not usable, too. Since bug 75335 got triggered by the missing DRM pipe loader, I tried to enable it with the following modification of configure.ac: - index ba158e8..feb025f 100644 --- a/configure.ac +++ b/configure.ac @@ -1748,6 +1748,7 @@ if test "x$with_gallium_drivers" != x; then xi915) HAVE_GALLIUM_I915=yes PKG_CHECK_MODULES([INTEL], [libdrm_intel >= $LIBDRM_INTEL_REQUIRED]) +gallium_require_drm_loader GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS i915 softpipe" if test "x$MESA_LLVM" = x1; then GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS llvmpipe" - With that, the demo finally worked: - EGL_VERSION = 1.4 (Gallium) Found 6 modes: 0: 1400 x 1050 1: 1400 x 1050 2: 1280 x 1024 3: 1024 x 768 4: 800 x 600 5: 640 x 480 Will use screen size: 1400 x 1050 vertex shader info: fragment shader info: info: 724 frames in 5.0 seconds = 144.713 FPS - So it seems that the DRM pipe loader should get enabled by default for the i915/DRM Gallium configuration, but I'm not sure if the modification I made would break some other configuration. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/ea0c703a/attachment-0001.html>
[PATCH 6/6] drm/radeon: limit how much memory TTM can move per IB according to VRAM usage
From: Marek Ol??k
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 87 +++---
drivers/gpu/drm/radeon/radeon_object.h | 3 +-
3 files changed, 84 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 1ba1a48..2338eef 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -157,7 +157,7 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
sort_relocs_for_validation(&p->validated);
- return radeon_bo_list_validate(&p->ticket, &p->validated, p->ring);
+ return radeon_bo_list_validate(p->rdev, &p->ticket, &p->validated,
p->ring);
}
static int radeon_cs_get_ring(struct radeon_cs_parser *p, u32 ring, s32
priority)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 19042ae..e1a5af7 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -368,29 +368,104 @@ void radeon_bo_fini(struct radeon_device *rdev)
arch_phys_wc_del(rdev->mc.vram_mtrr);
}
-int radeon_bo_list_validate(struct ww_acquire_ctx *ticket,
+/* Returns how many bytes TTM can move per IB.
+ */
+static u64 radeon_bo_get_threshold_for_moves(struct radeon_device *rdev)
+{
+ u64 real_vram_size = rdev->mc.real_vram_size;
+ u64 vram_usage = rdev->vram_usage;
+
+ /* This function is based on the current VRAM usage.
+*
+* - If all of VRAM is free, allow relocating the number of bytes that
+* is equal to 1/4 of the size of VRAM for this IB.
+
+* - If more than one half of VRAM is occupied, only allow relocating
+* 1 MB of data for this IB.
+*
+* - From 0 to one half of used VRAM, the threshold decreases
+* linearly.
+* __
+* 1/4 of -|\ |
+* VRAM| \ |
+* | \ |
+* | \|
+* |\ |
+* | \ |
+* | \ |
+* | \|1 MB
+* ||
+*VRAM 0 % 100 %
+* usedused
+*
+* Note: It's a threshold, not a limit. The threshold must be crossed
+* for buffer relocations to stop, so any buffer of an arbitrary size
+* can be moved as long as the threshold isn't crossed before
+* the relocation takes place. We don't want to disable buffer
+* relocations completely.
+*
+* The idea is that buffers should be placed in VRAM at creation time
+* and TTM should only do a minimum number of relocations during
+* command submission. In practice, you need to submit at least
+* a dozen IBs to move all buffers to VRAM if they are in GTT.
+*
+* Also, things can get pretty crazy under memory pressure and actual
+* VRAM usage can change a lot, so playing safe even at 50% does
+* consistently increase performance.
+*/
+
+ u64 half_vram = real_vram_size >> 1;
+ u64 half_free_vram = vram_usage >= half_vram ? 0 : half_vram -
vram_usage;
+ u64 bytes_moved_threshold = half_free_vram >> 1;
+ return max(bytes_moved_threshold, 1024*1024ull);
+}
+
+int radeon_bo_list_validate(struct radeon_device *rdev,
+ struct ww_acquire_ctx *ticket,
struct list_head *head, int ring)
{
struct radeon_bo_list *lobj;
struct radeon_bo *bo;
- u32 domain;
int r;
+ u64 bytes_moved = 0, initial_bytes_moved;
+ u64 bytes_moved_threshold = radeon_bo_get_threshold_for_moves(rdev);
r = ttm_eu_reserve_buffers(ticket, head);
if (unlikely(r != 0)) {
return r;
}
+
list_for_each_entry(lobj, head, tv.head) {
bo = lobj->bo;
if (!bo->pin_count) {
- domain = lobj->domain;
-
+ u32 domain = lobj->domain;
+ u32 current_domain =
+ radeon_mem_type_to_domain(bo->tbo.mem.mem_type);
+
+ /* Check if this buffer will be moved and don't move it
+* if we have moved too many buffers for this IB
already.
+*
+* Note that this allows moving at least one buffer of
+* any size, because it doesn't take the current "bo"
+* into account. We don't want to disallow buffer moves
+* completely.
+*/
+ if (current_domain != RADEON_GEM_DOMAIN_CPU &&
+
[PATCH 5/6] drm/radeon: validate relocations in the order determined by userspace
From: Marek Ol??k
Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to
a number from 0 to 15. The higher the number, the higher the priority,
which means a buffer with a higher number will be validated sooner.
The old behavior is preserved: Buffers used for write are prioritized over
read-only buffers if the userspace doesn't set the number.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon.h| 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 53 --
drivers/gpu/drm/radeon/radeon_object.c | 10 ---
drivers/gpu/drm/radeon/radeon_object.h | 2 --
4 files changed, 51 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d37a57a..f7a3174 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -481,7 +481,7 @@ struct radeon_bo_list {
struct ttm_validate_buffer tv;
struct radeon_bo*bo;
uint64_tgpu_offset;
- boolwritten;
+ unsignedpriority;
unsigneddomain;
unsignedalt_domain;
u32 tiling_flags;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index d49a3f7..1ba1a48 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -31,6 +31,41 @@
#include "radeon.h"
#include "radeon_trace.h"
+/* This is a variation of the bucket sort with O(n) time complexity.
+ * The relocations are sorted from the highest to the lowest priority. */
+static void sort_relocs_for_validation(struct list_head *list)
+{
+ struct list_head bucket[17], *it, *tmp;
+ unsigned i, priority;
+
+ for (i = 0; i < 17; i++)
+ INIT_LIST_HEAD(&bucket[i]);
+
+ /* Move the elements into buckets. An i-th bucket only contains
+* elements with priorities i*2 and i*2+1. Odd numbers are added
+* at the head of a bucket and even numbers are added at the tail,
+* therefore all buckets are always sorted. */
+ list_for_each_safe(it, tmp, list) {
+ priority = list_entry(it, struct radeon_bo_list,
+ tv.head)->priority;
+ i = priority / 2;
+ i = min(i, 16u) ;
+
+ if (priority % 2 == 1) {
+ list_move(it, &bucket[i]);
+ } else {
+ list_move_tail(it, &bucket[i]);
+ }
+ }
+
+ INIT_LIST_HEAD(list);
+
+ /* connect the sorted buckets */
+ for (i = 0; i < 17; i++) {
+ list_splice(&bucket[i], list);
+ }
+}
+
static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
{
struct drm_device *ddev = p->rdev->ddev;
@@ -80,7 +115,15 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
p->relocs_ptr[i] = &p->relocs[i];
p->relocs[i].robj = gem_to_radeon_bo(p->relocs[i].gobj);
p->relocs[i].lobj.bo = p->relocs[i].robj;
- p->relocs[i].lobj.written = !!r->write_domain;
+
+ /* The userspace buffer priorities are from 0 to 15. A higher
+* number means the buffer is more important.
+* Also, the buffers used for write have a higher priority than
+* the buffers used for read only, which doubles the range
+* to 0 to 31. Numbers 32 and 33 are reserved for the kernel
+* driver.
+*/
+ p->relocs[i].lobj.priority = (r->flags & 0xf) * 2 +
!!r->write_domain;
/* the first reloc of an UVD job is the msg and that must be in
VRAM, also but everything into VRAM on AGP cards to avoid
@@ -94,6 +137,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
p->relocs[i].lobj.alt_domain =
RADEON_GEM_DOMAIN_VRAM;
+ /* prioritize this over any other relocation */
+ p->relocs[i].lobj.priority = 32;
} else {
uint32_t domain = r->write_domain ?
r->write_domain : r->read_domains;
@@ -107,9 +152,11 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
p->relocs[i].lobj.tv.bo = &p->relocs[i].robj->tbo;
p->relocs[i].handle = r->handle;
- radeon_bo_list_add_object(&p->relocs[i].lobj,
- &p->validated);
+ list_add(&p->relocs[i].lobj.tv.head, &p->validated);
}
+
+ sort_relocs_for_validation(&p->validated);
+
return radeon_bo_list_validate(&p->ticket, &p->validated, p->ring);
}
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d676ee2..190
[PATCH 4/6] drm/radeon: add buffers to the LRU list from smallest to largest
From: Marek Ol??k
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon_cs.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index f28a8d8..d49a3f7 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -24,6 +24,7 @@
* Authors:
*Jerome Glisse
*/
+#include
#include
#include
#include "radeon_reg.h"
@@ -290,6 +291,16 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
+static int cmp_size_smaller_first(void *priv, struct list_head *a,
+ struct list_head *b)
+{
+ struct radeon_bo_list *la = list_entry(a, struct radeon_bo_list,
tv.head);
+ struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list,
tv.head);
+
+ /* Sort A before B if A is smaller. */
+ return (int)la->bo->tbo.num_pages - (int)lb->bo->tbo.num_pages;
+}
+
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -303,6 +314,18 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error, bo
unsigned i;
if (!error) {
+ /* Sort the buffer list from the smallest to largest buffer,
+* which affects the order of buffers in the LRU list.
+* This assures that the smallest buffers are added first
+* to the LRU list, so they are likely to be later evicted
+* first, instead of large buffers whose eviction is more
+* expensive.
+*
+* This slightly lowers the number of bytes moved by TTM
+* per frame under memory pressure.
+*/
+ list_sort(NULL, &parser->validated, cmp_size_smaller_first);
+
ttm_eu_fence_buffer_objects(&parser->ticket,
&parser->validated,
parser->ib.fence);
--
1.8.3.2
[PATCH 3/6] drm/radeon: deduplicate code in radeon_gem_busy_ioctl
From: Marek Ol??k
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon_gem.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d7890f2..ccb7d0f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -344,18 +344,7 @@ int radeon_gem_busy_ioctl(struct drm_device *dev, void
*data,
}
robj = gem_to_radeon_bo(gobj);
r = radeon_bo_wait(robj, &cur_placement, true);
- switch (cur_placement) {
- case TTM_PL_VRAM:
- args->domain = RADEON_GEM_DOMAIN_VRAM;
- break;
- case TTM_PL_TT:
- args->domain = RADEON_GEM_DOMAIN_GTT;
- break;
- case TTM_PL_SYSTEM:
- args->domain = RADEON_GEM_DOMAIN_CPU;
- default:
- break;
- }
+ args->domain = radeon_mem_type_to_domain(cur_placement);
drm_gem_object_unreference_unlocked(gobj);
r = radeon_gem_handle_lockup(rdev, r);
return r;
--
1.8.3.2
[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves
From: Marek Ol??k
The statistics are:
- VRAM usage in bytes
- GTT usage in bytes
- number of bytes moved by TTM
The last one is actually a counter, so you need to sample it before and after
command submission and take the difference.
This is useful for finding performance bottlenecks. Userspace queries are
also added.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon.h| 5 +
drivers/gpu/drm/radeon/radeon_device.c | 1 +
drivers/gpu/drm/radeon/radeon_kms.c| 15 ++
drivers/gpu/drm/radeon/radeon_object.c | 38 +-
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 10 -
include/uapi/drm/radeon_drm.h | 3 +++
7 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3f10782..d37a57a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2307,6 +2307,11 @@ struct radeon_device {
/* virtual memory */
struct radeon_vm_managervm_manager;
struct mutexgpu_clock_mutex;
+ /* memory stats */
+ struct mutexmemory_stats_mutex;
+ uint64_tvram_usage;
+ uint64_tgtt_usage;
+ uint64_tnum_bytes_moved;
/* ACPI interface */
struct radeon_atif atif;
struct radeon_atcs atcs;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index b012cbb..6564af7 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1184,6 +1184,7 @@ int radeon_device_init(struct radeon_device *rdev,
mutex_init(&rdev->gem.mutex);
mutex_init(&rdev->pm.mutex);
mutex_init(&rdev->gpu_clock_mutex);
+ mutex_init(&rdev->memory_stats_mutex);
mutex_init(&rdev->srbm_mutex);
init_rwsem(&rdev->pm.mclk_lock);
init_rwsem(&rdev->exclusive_lock);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 0b631eb..ddc8c74 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -486,6 +486,21 @@ static int radeon_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
case RADEON_INFO_VCE_FB_VERSION:
*value = rdev->vce.fb_version;
break;
+ case RADEON_INFO_NUM_BYTES_MOVED:
+ value = (uint32_t*)&value64;
+ value_size = sizeof(uint64_t);
+ value64 = rdev->num_bytes_moved;
+ break;
+ case RADEON_INFO_VRAM_USAGE:
+ value = (uint32_t*)&value64;
+ value_size = sizeof(uint64_t);
+ value64 = rdev->vram_usage;
+ break;
+ case RADEON_INFO_GTT_USAGE:
+ value = (uint32_t*)&value64;
+ value_size = sizeof(uint64_t);
+ value64 = rdev->gtt_usage;
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index dd12bb4..d676ee2 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -56,11 +56,38 @@ static void radeon_bo_clear_va(struct radeon_bo *bo)
}
}
+static void radeon_update_memory_usage(struct radeon_bo *bo,
+ unsigned mem_type, int sign)
+{
+ struct radeon_device *rdev = bo->rdev;
+ u64 size = (u64)bo->tbo.num_pages << PAGE_SHIFT;
+
+ mutex_lock(&rdev->memory_stats_mutex);
+ switch (mem_type) {
+ case TTM_PL_TT:
+ if (sign > 0)
+ rdev->gtt_usage += size;
+ else
+ rdev->gtt_usage -= size;
+ break;
+ case TTM_PL_VRAM:
+ if (sign > 0)
+ rdev->vram_usage += size;
+ else
+ rdev->vram_usage -= size;
+ break;
+ }
+ mutex_unlock(&rdev->memory_stats_mutex);
+}
+
static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo)
{
struct radeon_bo *bo;
bo = container_of(tbo, struct radeon_bo, tbo);
+
+ radeon_update_memory_usage(bo, bo->tbo.mem.mem_type, -1);
+
mutex_lock(&bo->rdev->gem.mutex);
list_del_init(&bo->list);
mutex_unlock(&bo->rdev->gem.mutex);
@@ -567,14 +594,23 @@ int radeon_bo_check_tiling(struct radeon_bo *bo, bool
has_moved,
}
void radeon_bo_move_notify(struct ttm_buffer_object *bo,
- struct ttm_mem_reg *mem)
+ struct ttm_mem_reg *new_mem)
{
struct radeon_bo *rbo;
+
if (!radeon_ttm_bo_is_radeon_bo(bo
[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains
From: Marek Ol??k
When passing buffers between processes, the receiving process needs to know
the original buffer domain, so that it doesn't accidentally move the buffer.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon.h| 3 +++
drivers/gpu/drm/radeon/radeon_drv.c| 3 ++-
drivers/gpu/drm/radeon/radeon_gem.c| 30 ++
drivers/gpu/drm/radeon/radeon_kms.c| 1 +
drivers/gpu/drm/radeon/radeon_object.c | 3 +++
include/uapi/drm/radeon_drm.h | 12
6 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index a415f8e..3f10782 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -454,6 +454,7 @@ struct radeon_bo {
/* Protected by gem.mutex */
struct list_headlist;
/* Protected by tbo.reserved */
+ u32 initial_domain;
u32 placements[3];
struct ttm_placementplacement;
struct ttm_buffer_objecttbo;
@@ -2114,6 +2115,8 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
void *data,
struct drm_file *filp);
int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp);
int radeon_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 84a1bbb7..4392b7c 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -79,9 +79,10 @@
* 2.35.0 - Add CIK macrotile mode array query
* 2.36.0 - Fix CIK DCE tiling setup
* 2.37.0 - allow GS ring setup on r6xx/r7xx
+ * 2.38.0 - RADEON_GEM_OP (GET_INITIAL_DOMAIN, SET_INITIAL_DOMAIN)
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 37
+#define KMS_DRIVER_MINOR 38
#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 b96c819..d7890f2 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -533,6 +533,36 @@ out:
return r;
}
+int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp)
+{
+ struct drm_radeon_gem_op *args = data;
+ struct drm_gem_object *gobj;
+ struct radeon_bo *robj;
+
+ gobj = drm_gem_object_lookup(dev, filp, args->handle);
+ if (gobj == NULL) {
+ return -ENOENT;
+ }
+ robj = gem_to_radeon_bo(gobj);
+
+ switch (args->op) {
+ case RADEON_GEM_OP_GET_INITIAL_DOMAIN:
+ args->value = robj->initial_domain;
+ break;
+ case RADEON_GEM_OP_SET_INITIAL_DOMAIN:
+ robj->initial_domain = args->value & (RADEON_GEM_DOMAIN_VRAM |
+ RADEON_GEM_DOMAIN_GTT |
+ RADEON_GEM_DOMAIN_CPU);
+ break;
+ default:
+ ; /* do nothing */
+ }
+
+ drm_gem_object_unreference_unlocked(gobj);
+ return 0;
+}
+
int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index baff98b..0b631eb 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -814,5 +814,6 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_BUSY, radeon_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(RADEON_GEM_OP, radeon_gem_op_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
int radeon_max_kms_ioctl = DRM_ARRAY_SIZE(radeon_ioctls_kms);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 08595cf..dd12bb4 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -145,6 +145,9 @@ int radeon_bo_create(struct radeon_device *rdev,
bo->surface_reg = -1;
INIT_LIST_HEAD(&bo->list);
INIT_LIST_HEAD(&bo->va);
+ bo->
[PATCH 0/6] Radeon memory management improvements
This series improves performance for the cases when there is not enough VRAM for all buffers. First of all, I'd like to mention that if you set both VRAM and GTT domains for a buffer, you pretty much say you don't care where the buffer ends up. It usually makes the performance even worse. This work was largely benchmark-driven and I tried a lot of ideas before I found out which ones work. The patches describe what they do and they're quite simple, so I'll just share the results here. Card: Evergreen Redwood (HD 5670), 512 MB of VRAM Test: Unigine Heaven 4.0, High settings 1) 1280x720, 4x MSAA, need 525 MB of VRAM Without patches: 16.6 FPS With patches: 16.6 FPS Improvement: 0 % 2) 1600x900, 4x MSAA, need 642 MB of VRAM Without patches: 7.1 FPS With patches: 9.7 FPS Improvement: 36 % 3) 1920x1080, 4x MSAA, need 743 MB of VRAM Without patches: 3.7 FPS With patches: 5.6 FPS Improvement: 51 % 4) 1600x900, 8x MSAA, need 838 MB of VRAM Without patches: 2.9 FPS With patches: 4.6 FPS Improvement: 58 % These results don't change if you run the benchmark several times, which proves the improvement is stable. To conclude this, here are ideas for future work: 1) Add virtual memory support for VRAM. Our GPUs support virtual memory, which not only solves fragmentation issues, but it also allows each buffer to be partially in VRAM and partially in GTT, which becomes more important with large buffers like 100 MB. Moving whole buffers back and forth between VRAM and GTT is inefficient if you can do it at page granularity. Also, due to fragmentation, we can never really use all of VRAM, but only about 90-95%. 2) Add support for uncached GTT. I think it should improve performance for dGPUs under memory pressure, but some testing needs to be done to confirm that. Uncached GTT doesn't seem to work for me on Evergreen, but it's said to be working on some later chips. The patches for Mesa will follow later today. Please review. Marek
[PATCH] video: hdmi: request underscan by default
Working with HDMI TVs is a real pain as they tend to overscan by
default, meaning that the pixels around the edge of the framebuffer
are not displayed. This is well explained here:
http://mjg59.dreamwidth.org/8705.html
There is a bit in the HDMI info frame that can request that the
remote display shows the full pixel data ("underscan"). For the
remote display, the HDMI spec states that this is optional - it
doesn't have to listen. That means that most TVs will probably ignore
this.
But, maybe there are a handful of TVs for which this would help
the situation. As we live in a digital world, ask the remote
display not to overscan by default.
Signed-off-by: Daniel Drake
---
drivers/video/hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 9e758a8..6c2d924 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -54,6 +54,7 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame)
frame->type = HDMI_INFOFRAME_TYPE_AVI;
frame->version = 2;
frame->length = HDMI_AVI_INFOFRAME_SIZE;
+ frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
return 0;
}
--
1.8.3.2
[Bug 75400] regression in OpenCL since commit cc3aeac
https://bugs.freedesktop.org/show_bug.cgi?id=75400 Bruno Jim?nez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Bruno Jim?nez --- Hi, The latest master branch works perfectly. Thanks a lot! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/15e3f32d/attachment.html>
[PATCH 1/2] drm/mgag200: Added the hwcursor parameter to turn hardware cursor on/off.
The hwcursor parameter is a boolean variable. When set to true, the
hardware cursor is enabled. When set to false, it is disabled.
Signed-off-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 9f9780b..c9a94a6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -10,9 +10,17 @@
#include
#include "mgag200_drv.h"
+#include
+
+static bool hwcursor = true;
static bool warn_transparent = true;
static bool warn_palette = true;
+static bool warn_user_input = true;
+
+module_param(hwcursor, bool, 0644);
+MODULE_PARM_DESC(hwcursor, "When true, the hardware cursor is enabled. When
false, it is disabled.");
+
/*
Hide the cursor off screen. We can't disable the cursor hardware because it
@@ -90,6 +98,16 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
goto out1;
}
+ if (!hwcursor) {
+ if (warn_user_input) {
+ dev_info(&dev->pdev->dev, "User disabled hardware
cursor.\n");
+ warn_user_input = false;
+ }
+ mga_hide_cursor(mdev);
+ ret = -EINVAL;
+ goto out1;
+ }
+
/* Move cursor buffers into VRAM if they aren't already */
if (!pixels_1->pin_count) {
ret = mgag200_bo_pin(pixels_1, TTM_PL_FLAG_VRAM,
--
1.7.10.4
[PATCH 0/2] drm/mgag200: hardware cursor bug fixes & new parameter
Here are a few bug fixes and a new control parameter for the mgag200 hardware cursor. Julia Lemire (2): drm/mgag200: Added the hwcursor parameter to turn hardware cursor on/off. drm/mgag200: Fix hardware cursor colour inversion and inaccurate register index. drivers/gpu/drm/mgag200/mgag200_cursor.c | 36 +- 1 file changed, 31 insertions(+), 5 deletions(-) -- 1.7.10.4
[PATCH v2 2/2] drm/mgag200: Fix hardware cursor colour inversion and inaccurate register index.
The hardware cursor colous are stored in the DAC indexed registers.
The algorithm for setting these colours via their corresponding index
was off by a value of 0x03.
It was also noted that the R and B bytes were being misread from the
cursor bugger. Assuming the transparency is the MSB or bits 31-24,
then R should be bits 23-16, G should be bits 15-8 and B should be
the LSB or bits 7-0.
Signed-off-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index c9a94a6..0fd4ba0 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -55,12 +55,12 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
uint32_t colour_set[16];
uint32_t *next_space = &colour_set[0];
uint32_t *palette_iter;
- uint32_t this_colour;
+ uint32_t this_colour; /* 32-bit colour encoded pixel */
bool found = false;
int colour_count = 0;
u64 gpu_addr;
u8 reg_index;
- u8 this_row[48];
+ u8 this_row[48]; /* cursor bitmap row array */
if (!pixels_1 || !pixels_2) {
WREG8(MGA_CURPOSXL, 0);
@@ -191,14 +191,20 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
}
/* Program colours from cursor icon into palette */
+ /* Colour is receieved as RGB, where is R are the MSB and B are the
LSB. */
+ /* The first three colours are located between indexes 0x08-0x12. */
+ /* The remaining colours are located between indexes 0x60-0x86. */
for (i = 0; i < colour_count; i++) {
if (i <= 2)
reg_index = 0x8 + i*0x4;
else
- reg_index = 0x60 + i*0x3;
- WREG_DAC(reg_index, colour_set[i] & 0xff);
+ reg_index = 0x60 + (i-3)*0x3;
+ /* Write the Red bits. */
+ WREG_DAC(reg_index, colour_set[i]>>16 & 0xff);
+ /* Write the Green bits. */
WREG_DAC(reg_index+1, colour_set[i]>>8 & 0xff);
- WREG_DAC(reg_index+2, colour_set[i]>>16 & 0xff);
+ /* Write the Blue bits. */
+ WREG_DAC(reg_index+2, colour_set[i] & 0xff);
BUG_ON((colour_set[i]>>24 & 0xff) != 0xff);
}
--
1.7.10.4
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 --- Comment #5 from funkydude --- Is that something us users can help with? :p -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/b6370a18/attachment.html>
[RFC PATCH v3 2/9] staging: imx-drm: Add temporary copies of v4l2-of parsing functions
On Tue, Feb 18, 2014 at 12:36:03PM +0100, Philipp Zabel wrote: > From: Philipp Zabel > > The existing v4l2-of parser functions for the video interface bindings > described in Documentation/device-tree/bindings/media/video-interfaces.txt > are useful for DRM drivers, too. They will be moved to drivers/media > so they can be used by drm drivers, too. Until then, duplicate the > v4l2-of parser functions temporarily. > > Signed-off-by: Philipp Zabel Ergh. So, because we can't get agreement on where to put the common helpers, we have to put up with adding duplicate helpers into the staging directory, inflating not only the kernel source code size but also the binary size as well. Come on people, get agreement on how to deal with this. Staging may be a dumping ground for drivers which aren't ready to be merged as proper drivers, but this is no reason to ignore proper process. Do we, or do we not want to get imx-drm out of drivers/staging? If we do, the only way that's going to happen is if we stop throwing in this kind of stuff. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[RFC PATCH v3 1/9] staging: imx-drm-core: don't request probe deferral in imx_drm_encoder_parse_of
On Tue, Feb 18, 2014 at 12:36:02PM +0100, Philipp Zabel wrote: > From: Lucas Stach > > Since imx_drm_encoder_parse_of is called from the encoder bind callbacks, > it is too late to request probe deferral. Rather the core should make sure > that the crtcs are bound before the encoders, after all needed components > are probed. Why is it too late? -EPROBE_DEFER from this point will cause the driver initialisation to correctly unwind and return -EPROBE_DEFER to the last-to-be-added component. > This fixes probe failure when using the LDB on i.MX6. More details please. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 ?lvaro Castillo changed: What|Removed |Added Attachment #127311|pm-utils-bugreport-info.sh |pm-utils-bugreport-info.sh. filename||txt -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 --- Comment #5 from ?lvaro Castillo --- systemctl suspend does not work too. systemd-python-208-9.fc20.x86_64 systemd-208-9.fc20.x86_64 systemd-libs-208-9.fc20.x86_64 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 --- Comment #4 from ?lvaro Castillo --- Created attachment 127311 --> https://bugzilla.kernel.org/attachment.cgi?id=127311&action=edit Contains some information get of pm-utils-bugreport.sh script. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 --- Comment #3 from ?lvaro Castillo --- Add information: I've tried some options to going into suspend system with pm-suspend --* All options tried was not turn on laptop screen after resume: --quirk-dpms-on --quirk-dpms-suspend --quirk-radeon-off --quirk-s3-bios --quirk-s3-mode --quirk-vbe-post --quirk-vbemode-restore --quirk-vbestate-restore --quirk-vga-mode-3 --quirk-save-pci --store-quirks-as-lkw --quirk-none -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75432] fedora rawhide, since linux 3.14, dota2 main menu runs at 2 fps
https://bugs.freedesktop.org/show_bug.cgi?id=75432 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. If the kernel is the only component you changed, can you bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/28482a1f/attachment.html>
[Bug 70651] cannot write to power_dpm_force_performance_level: invalid argument (radeon 7730m)
https://bugzilla.kernel.org/show_bug.cgi?id=70651 --- Comment #8 from Fabio Sangiovanni --- Hi, thanks for the update. In comment 5 I reported results with the patch applied to 3.13.3. Long story short: it behaves the same as with plain stock 3.13.3. I'll try to apply the patch to the latest 3.14rc and report the results again. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 70651] cannot write to power_dpm_force_performance_level: invalid argument (radeon 7730m)
https://bugzilla.kernel.org/show_bug.cgi?id=70651 --- Comment #7 from Alex Deucher --- That patch is against 3.14rc; it should apply there. The issue is that on hybrid laptops, the dGPU is powered down when not in use so you can't make adjustments to the dGPU when it's powered down. It doesn't make sense to power it up to make the adjustments since it will just be powered down again right after. As such the values you are reading back are garbage since the hw is powered down. The patch just attempts to do something sensible when you try and access the hw via sysfs or debugfs and the dGPU is powered down. You can disable the automatic dGPU power down by setting radeon.runpm=0 on the kernel command line in grub. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #18 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 66963 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/5eb4a2f5/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 Alex Deucher changed: What|Removed |Added CC||qwrules at gmail.com --- Comment #200 from Alex Deucher --- *** Bug 74420 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/fd09faf6/attachment.html>
[Bug 75400] regression in OpenCL since commit cc3aeac
https://bugs.freedesktop.org/show_bug.cgi?id=75400 --- Comment #9 from Emil Velikov --- (In reply to comment #8) > Hi, > > I'm afraid that that patch doesn't help. I have also tried the patch you > have sent to the Mailing List ( > http://lists.freedesktop.org/archives/mesa-dev/2014-February/054780.html ) > but also nothing. > Interesting that patch you've linked should have caused build breakage as there is yet another missing symbol/reference :\ Just pushed a few patches that should resolve the missing symbols within pipe-loader, used by opencl. Checkout latest master and give it a try. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/5e1f25c8/attachment.html>
[PATCH 09/13] drm: rename drm_unplug/get_minor() to drm_minor_register/unregister()
Hi On Fri, Feb 21, 2014 at 8:21 AM, Thierry Reding wrote: > On Wed, Jan 29, 2014 at 03:01:56PM +0100, David Herrmann wrote: >> drm_get_minor() no longer allocates objects, and drm_unplug_minor() is now >> the exact reverse of it. Rename it to _register/unregister() so their >> name actually says what they do. >> >> Furthermore, remove the direct minor-ptr and instead pass the minor-type. >> This way we know the actualy slot of the minor and can reset it if > > Nit: "actualy" -> "actual". Fixed. Thanks David
[PATCH 05/13] drm: provide device-refcount
Hi On Fri, Feb 21, 2014 at 8:01 AM, Thierry Reding wrote: > On Wed, Jan 29, 2014 at 03:01:52PM +0100, David Herrmann wrote: > [...] >> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c > [...] >> @@ -486,12 +490,10 @@ EXPORT_SYMBOL(drm_dev_alloc); >> * @dev: DRM device to free >> * >> * Free a DRM device that has previously been allocated via drm_dev_alloc(). >> - * You must not use kfree() instead or you will leak memory. >> - * >> - * This must not be called once the device got registered. Use drm_put_dev() >> - * instead, which then calls drm_dev_free(). >> + * This may not be called directly, you must use drm_dev_ref() and >> + * drm_dev_unref() to gain and drop references to the object. >> */ >> -void drm_dev_free(struct drm_device *dev) >> +static void drm_dev_free(struct drm_device *dev) > > With the function turning static it can't be called from anywhere else > but this file, so perhaps the last sentence of the comment can now go > away as well? Yepp, fixed. Thanks David
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 --- Comment #4 from Alex Deucher --- (In reply to comment #1) > Is there some form of attack plan for fixing these issues? We need to figure out what combination(s) of GL state cause a problem with hyperZ, then either disable hyperZ in those cases, or adjust the hyperZ-specific state to avoid the hang in those specific cases. Ideally we'd be able to find a small test case where we can reproduce the issue(s). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/9fcf39ca/attachment.html>
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 --- Comment #2 from ?lvaro Castillo --- I tried to listen to music with VLC player. So I was surprised... system works 100% after resume but Screen is off LOL. I can swtich into different ttys and X11 desktop without Screen turned on LOL. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 0/6] Radeon memory management improvements
On Mon, Feb 24, 2014 at 11:40 AM, Christian K?nig wrote: > Hi Marek, > > Some minor comments on patch 1, 2 and 5, but nothing serious. Patch 3, 4 and > 6 are Reviewed-by: christian K?nig > > See below for a few in line comments. > > Am 24.02.2014 16:20, schrieb Marek Ol??k: > >> This series improves performance for the cases when there is not enough >> VRAM for all buffers. >> >> First of all, I'd like to mention that if you set both VRAM and GTT >> domains for a buffer, you pretty much say you don't care where the buffer >> ends up. It usually makes the performance even worse. >> >> This work was largely benchmark-driven and I tried a lot of ideas before I >> found out which ones work. The patches describe what they do and they're >> quite simple, so I'll just share the results here. >> >> >> Card: Evergreen Redwood (HD 5670), 512 MB of VRAM >> Test: Unigine Heaven 4.0, High settings >> >> 1) 1280x720, 4x MSAA, need 525 MB of VRAM >> >> Without patches: 16.6 FPS >> With patches: 16.6 FPS >> Improvement: 0 % >> >> 2) 1600x900, 4x MSAA, need 642 MB of VRAM >> >> Without patches: 7.1 FPS >> With patches: 9.7 FPS >> Improvement: 36 % >> >> 3) 1920x1080, 4x MSAA, need 743 MB of VRAM >> >> Without patches: 3.7 FPS >> With patches: 5.6 FPS >> Improvement: 51 % >> >> 4) 1600x900, 8x MSAA, need 838 MB of VRAM >> Without patches: 2.9 FPS >> With patches: 4.6 FPS >> Improvement: 58 % >> >> These results don't change if you run the benchmark several times, which >> proves the improvement is stable. >> >> >> To conclude this, here are ideas for future work: >> >> 1) Add virtual memory support for VRAM. Our GPUs support virtual memory, >> which not only solves fragmentation issues, but it also allows each buffer >> to be partially in VRAM and partially in GTT, which becomes more important >> with large buffers like 100 MB. Moving whole buffers back and forth between >> VRAM and GTT is inefficient if you can do it at page granularity. Also, due >> to fragmentation, we can never really use all of VRAM, but only about >> 90-95%. > > > Yeah, I'm also thinking about this for quite some time now. The basic > problem is that while our GPUs support VM they don't support faulting pages > in and continuing (at least nobody got that working reliable so far). E.g. > when you hit a page fault you can't relocate the page and then continue. > Well, for non-scanout buffers we can do scatter gather for vram pages rather than using contiguous buffers. That would at least avoid low memory situations where there is enough vram, just not contiguous. Another option would be to write a ttm defragmentor, but I think we'd have to fix the synchronization issues with bo moves first. Alex > Support for partially resident textures on newer hardware currently works by > splitting the buffer up into smaller buffers in userspace and then actively > checking in the shader if we hit a buffer that's not currently in memory, > but that's not really applicable in the general use case (to much shader > overhead). > > >> 2) Add support for uncached GTT. I think it should improve performance for >> dGPUs under memory pressure, but some testing needs to be done to confirm >> that. Uncached GTT doesn't seem to work for me on Evergreen, but it's said >> to be working on some later chips. > > > Did you try to make the whole GTT uncached or just evicted BOs? Making the > whole GTT uncached probably won't work out of the box, but avoiding setting > the "SNOOPED" flag on those pages might get us better performance while > swapping them into VRAM again. > > Christian. > > >> >> The patches for Mesa will follow later today. Please review. >> >> Marek >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 75357] Barts (HD6850): Failure in evergreen_surface_check_2d
https://bugs.freedesktop.org/show_bug.cgi?id=75357 --- Comment #6 from oogway.droid at gmail.com --- I've disabled ColorTiling2D now. Will report back soon. One observation is that when I disable monitor power saving in Gnome Settings (Power->Blank Screen->Never), I did not hit the issue. Although I tested only for about 12 hours. Without this I usually get the black screen on resuming the monitor from power saving mode in about 1 or 2 hours. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/c3029af0/attachment-0001.html>
[PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races
On Mon, Feb 24, 2014 at 12:48:55PM +0900, Michel D?nzer wrote:
> On Fre, 2014-02-21 at 21:03 +0200, ville.syrjala at linux.intel.com wrote:
> >
> > We can kill of the drm_vblank_{pre,post}_modeset() calls since those are
> > there simply to make drm_vblank_get() fail during a modeset.
>
> Actually, their original purpose was to keep the DRM vblank counter
> consistent across modesets, assuming the modeset resets the hardware
> vblank counter.
I see. Well, actually I really don't. The code is too funky for me to
tell what it actually ends up doing. The obvious way would be to
resample the hardware counter at drm_vblank_post_modeset(), which the
code certainly doesn't do. But maybe it did something sensible in the
past.
--
Ville Syrj?l?
Intel OTC
[PATCH] drm: armada: Use devm_ioremap_resource()
On Mon, Feb 24, 2014 at 10:56:31AM -0300, Fabio Estevam wrote: > David, > > On Mon, Feb 10, 2014 at 7:57 PM, Fabio Estevam wrote: > > From: Fabio Estevam > > > > devm_request_and_ioremap() is deprecated, so use devm_ioremap_resource() > > instead. > > > > Signed-off-by: Fabio Estevam > > --- > > Any comments about this one? Given the amount of patches I'm presently dealing with, I really don't want to bother with such trivial patches at the moment. What I do want to do is to get stuff like imx-drm and the conversion of armada to the component helpers out the door and queued up for 3.15 as a higher priority than to bother with trivial stuff like this which has the possibility to break those patches. Let's see about dealing with this post 3.14. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[PATCH 4/6] android: convert sync to fence api, v4
op 19-02-14 14:56, Thomas Hellstrom schreef:
>> >+static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
>> >+{
>> >+ struct sync_fence_cb *check = container_of(cb, struct sync_fence_cb,
>> >cb);
>> >+ struct sync_fence *fence = check->fence;
>> >+
>> >+ // TODO: Add a fence->status member and check it
> Hmm, C++ / C99 style comments makes checkpatch.pl complain. Did you run
> this series through checkpatch?
>
> /Thomas
>
Actually I used c99 here because it shouldn't have been in the sent patch. ;-)
Right below that comment I use fence->status, so the right thing to do was to
zap the comment.
Thanks for catching it!
~Maarten\
[Bug 70651] cannot write to power_dpm_force_performance_level: invalid argument (radeon 7730m)
https://bugzilla.kernel.org/show_bug.cgi?id=70651 --- Comment #6 from Fabio Sangiovanni --- Should I maybe apply the patch to a more recent version of the kernel, considering the offset of hunk #7? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races
On Fre, 2014-02-21 at 21:03 +0200, ville.syrjala at linux.intel.com wrote:
>
> We can kill of the drm_vblank_{pre,post}_modeset() calls since those are
> there simply to make drm_vblank_get() fail during a modeset.
Actually, their original purpose was to keep the DRM vblank counter
consistent across modesets, assuming the modeset resets the hardware
vblank counter.
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
[Bug 75361] freeze in Mass Effect 3 (wine)
https://bugs.freedesktop.org/show_bug.cgi?id=75361 --- Comment #6 from wdr --- In game menu work. Freeze on load after menu. Ctrl+Alt+F1 and kill MassEffect - work. '?' - 'Finished' - this output ok command kill MassEffect proccess (kill -9 "pid") -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/91695edd/attachment.html>
[Bug 75361] freeze in Mass Effect 3 (wine)
https://bugs.freedesktop.org/show_bug.cgi?id=75361 --- Comment #5 from wdr --- Created attachment 94652 --> https://bugs.freedesktop.org/attachment.cgi?id=94652&action=edit glxinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/11212449/attachment-0001.html>
[Bug 75361] freeze in Mass Effect 3 (wine)
https://bugs.freedesktop.org/show_bug.cgi?id=75361 --- Comment #4 from wdr --- Created attachment 94651 --> https://bugs.freedesktop.org/attachment.cgi?id=94651&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/c51fac14/attachment.html>
[Bug 75361] freeze in Mass Effect 3 (wine)
https://bugs.freedesktop.org/show_bug.cgi?id=75361 --- Comment #3 from wdr --- Created attachment 94650 --> https://bugs.freedesktop.org/attachment.cgi?id=94650&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/9ab38f75/attachment.html>
[Bug 75061] bug in clearing color buffer
https://bugs.freedesktop.org/show_bug.cgi?id=75061 --- Comment #13 from Marek Ol??k --- If the program called MapBufferRange(MAP_INVALIDATE_BUFFER_BIT) instead of BufferData, I think it would be okay to crash: >From GL 4.4 spec: "MAP_INVALIDATE_BUFFER_BIT indicates that the previous contents of the entire buffer may be discarded. Data within the entire buffer are undefined with the exception of subsequently written data. No GL error is generated if subsequent GL operations access unwritten data, but the result is undefined and system errors (possibly including program termination) may occur." In other words, no context should access the buffer until UnmapBuffer() is complete, because there may be unwritten data. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/e199d6b9/attachment.html>
[Bug 71051] Cannot suspend with radeon drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=71051 Lan Tianyu changed: What|Removed |Added CC||tianyu.lan at intel.com Component|Power-Video |Video(DRI - non Intel) Assignee|acpi_power-video at kernel-bug |drivers_video-dri at kernel-bu |s.osdl.org |gs.osdl.org Product|ACPI|Drivers -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75061] bug in clearing color buffer
https://bugs.freedesktop.org/show_bug.cgi?id=75061 --- Comment #12 from Marek Ol??k --- All writes to valid_buffer_range are protected by a mutex. Only the reads are not. I've got no idea what to do with invalidate_buffer. If we added mutexes everywhere, it would slow down the driver. I think that calling BufferData in one thread and using the buffer for rendering in some other thread is a race condition in the application and should be fixed in the app. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/da9e8263/attachment.html>
[PATCH] Delete reference to nonexistant git tree in linux/MAINTAINERS for AGPGART and DRM
Hi, Dave. The git tree git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git apparently does not existing anyomre at that location, and I have not seen a response to my messsage of February 17th about this providing a new location, so I am submitting this patch to you to remove the inaccurate lines from linux/MAINTAINERS.? If there is some other git URL that should be used rather than just deleting those lines, I would be happy to change the patch or be happy to see you make the change rather than deleting these lines.? However, I hope you will agree that the references to the nonexistent git tree needs to be changed. If I should be following some other process to get this pushed upstream, I would appreciate a pointer on it. Thanks for your contributions, and thanks in advance for your attention to this. Adam Richter --- linux-3.14-rc4/MAINTAINERS? 2014-02-23 17:40:03.0 -0800 +++ linux-3.14-rc4.modified/MAINTAINERS 2014-02-24 11:38:47.346032131 -0800 @@ -473,7 +473,6 @@ F:? net/rxrpc/af_rxrpc.c ? ?AGPGART DRIVER ?M: David Airlie -T: git git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git ?S: Maintained ?F: drivers/char/agp/ ?F: include/linux/agp* @@ -2848,7 +2847,6 @@ F:??? lib/kobj* ?DRM DRIVERS ?M: David Airlie ?L: dri-devel at lists.freedesktop.org -T: git git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git ?S: Maintained ?F: drivers/gpu/drm/ ?F: include/drm/
[RFC 00/12] Support render-node only drivers
Hi On Fri, Feb 21, 2014 at 8:55 AM, Thierry Reding wrote: > From: Thierry Reding > > This series builds on top of David's reliable DRM minor series: > > [PATCH 00/13] DRM Reliable Minor-IDs > > Tegra K1 has a Kepler-type GPU without any display engine. Instead it > reuses the Tegra display engine. That means that effectively the GPU > becomes a render-node only device. In order to reflect that, it would > be preferable for the associated /dev/dri/cardX node not to show up. > > To achieve that, the DRIVER_MODESET feature needs to be removed from > the GPU driver, but that unfortunately implies activating a bunch of > legacy behaviour for pre-KMS drivers. To allow for drivers that don't > support modesetting IOCTLs (because they drive no output) but which > aren't legacy either, the meaning of the DRIVER_MODESET needs to be > redefined. > > This series attempts to do so by first renaming DRM_MINOR_LEGACY to > DRM_MINOR_PRIMARY to more accurately reflect its purpose. Legacy and > modesetting are then decoupled by introducing a DRIVER_LEGACY driver > feature that can be set by truly legacy drivers. This allows the old > DRIVER_MODESET feature to advertise support only for modesetting > functionality, without implying that it is a non-legacy driver. > > After all the drivers have been updated, the core can be modified to > create the primary minor only when DRIVER_MODESET is available. > > The remainder of the series cleans up some drm_core_check_feature() > usage and drop some unused code related to that. The series looks fine to me. Apart from "drm: Separate DRIVER_MODESET and DRIVER_LEGACY" (and with Ilja's comment on 04/12): Reviewed-by: David Herrmann Regarding the DRIVER_ flag splitting, I haven't really checked whether you caught all places. The patch looks correct, though. I might have some time this week for a closer look. Thanks David > Thierry > > Thierry Reding (12): > drm: Rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY > drm: Introduce DRIVER_LEGACY feature > drm/i915: Mark as legacy if KMS is disabled > drm: Separate DRIVER_MODESET and DRIVER_LEGACY > drm: Create primary minor only if mode-setting is supported > drm: Remove gratuituous blank line > drm: Use drm_core_check_feature() where possible > drm/exynos: Remove dead code > drm/gma500: Remove dead code > drm/i810: Remove dead code > drm/i915: Remove dead code > drm/qxl: Remove dead code > > drivers/gpu/drm/drm_bufs.c | 12 +-- > drivers/gpu/drm/drm_crtc.c | 1 - > drivers/gpu/drm/drm_dma.c | 4 ++-- > drivers/gpu/drm/drm_fops.c | 14 ++-- > drivers/gpu/drm/drm_gem.c | 6 +++--- > drivers/gpu/drm/drm_irq.c | 12 +-- > drivers/gpu/drm/drm_pci.c | 12 +-- > drivers/gpu/drm/drm_scatter.c | 6 +++--- > drivers/gpu/drm/drm_stub.c | 24 +++-- > drivers/gpu/drm/drm_sysfs.c | 8 +++ > drivers/gpu/drm/exynos/exynos_drm_gem.c | 10 - > drivers/gpu/drm/gma500/gem.c| 3 --- > drivers/gpu/drm/i810/i810_dma.c | 7 -- > drivers/gpu/drm/i810/i810_drv.c | 3 ++- > drivers/gpu/drm/i915/i915_dma.c | 38 > - > drivers/gpu/drm/i915/i915_drv.c | 18 ++-- > drivers/gpu/drm/i915/i915_gem.c | 17 +++ > drivers/gpu/drm/i915/i915_gem_context.c | 6 -- > drivers/gpu/drm/i915/i915_irq.c | 6 +++--- > drivers/gpu/drm/i915/i915_suspend.c | 15 ++--- > drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- > drivers/gpu/drm/mga/mga_drv.c | 3 ++- > drivers/gpu/drm/qxl/qxl_kms.c | 4 > drivers/gpu/drm/radeon/radeon_drv.c | 3 ++- > drivers/gpu/drm/savage/savage_drv.c | 2 +- > drivers/gpu/drm/sis/sis_drv.c | 2 +- > drivers/gpu/drm/tdfx/tdfx_drv.c | 1 + > drivers/gpu/drm/via/via_drv.c | 2 +- > include/drm/drmP.h | 3 ++- > 29 files changed, 112 insertions(+), 132 deletions(-) > > -- > 1.8.4.2 >
[RFC 05/12] drm: Create primary minor only if mode-setting is supported
Hi
On Fri, Feb 21, 2014 at 8:55 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Non-legacy devices may not always support mode-setting functionality, so
> create the primary minor conditionally.
>
> One setup where this happens is the Tegra K1, where the Tegra DRM driver
> exposes the display engine via standard KMS IOCTLs, and nouveau drives
> the Kepler-type GPU that has no display capabilities.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_stub.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index fd2f1758366d..839460b774c5 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -564,9 +564,11 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> *driver,
> goto err_minors;
> }
>
> - ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> - if (ret)
> - goto err_minors;
> + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> + ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> + if (ret)
> + goto err_minors;
> + }
There's a lot of code accessing dev->primary for debug messages (to
print stuff like "error on card0: bla"). I just want to make sure you
checked for all that. I tried renaming "->primary" to "->primary2"
locally just to find these and I doubt this is safe for most drivers.
I haven't looked for nouveau in particular, though.
Anyhow, the patch is the right thing to do.
Thanks
David
>
> if (drm_ht_create(&dev->map_hash, 12))
> goto err_minors;
> --
> 1.8.4.2
>
[PATCH] drm: armada: Use devm_ioremap_resource()
On Mon, Feb 24, 2014 at 11:05 AM, Russell King - ARM Linux wrote: > Given the amount of patches I'm presently dealing with, I really don't > want to bother with such trivial patches at the moment. What I do want > to do is to get stuff like imx-drm and the conversion of armada to the > component helpers out the door and queued up for 3.15 as a higher > priority than to bother with trivial stuff like this which has the > possibility to break those patches. > > Let's see about dealing with this post 3.14. Understood, thanks.
[Bug 75432] New: fedora rawhide, since linux 3.14, dota2 main menu runs at 2 fps
https://bugs.freedesktop.org/show_bug.cgi?id=75432 Priority: medium Bug ID: 75432 Assignee: dri-devel at lists.freedesktop.org Summary: fedora rawhide, since linux 3.14, dota2 main menu runs at 2 fps Severity: minor Classification: Unclassified OS: Linux (All) Reporter: sylvain.bertrand at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI If I use any of the current 3.14 kernels in fedora rawhide, the main menu of dota2 will run at 2 fps. If I use the last 3.13 kernel, everything is fine. Radeon hd 5750. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/fc19a8f0/attachment.html>
Build error: MSM DRM
Automated build testing of allmodconfig discovered this error in the MSM DRM driver: drivers/gpu/drm/msm/hdmi/hdmi.o:(.rodata+0x10): multiple definition of `__mod_of_device_table' drivers/gpu/drm/msm/adreno/a3xx_gpu.o:(.rodata+0x4dc): first defined here It appears that this will happen whenever the MSM DRM driver is built as a module. It's unclear what the correct fix is - since making it a "bool" will make it unusable if the rest of DRM is configured modular, and it's not trivial to split these files. Since this is yet another multiple-device monstrosity pretending to look like a single device (though slightly saner than other stuff, but still ultimately unsafe - nothing guarantees for instance that hdmi_pdev remains valid) the right solution to this would be to convert the thing to use the component infrastructure included in v3.14-rc, which then allows the MSM driver to be multiple stand alone modules. This is clearly what the driver needs if it's actually made up from multiple drivers. While there's no examples of how to do this in mainline yet, two examples of such converted drivers have been posted on LAKML and elsewhere - which are the imx-drm and armada-drm drivers. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[Bug 73014] tahiti ways slower than juniper in dota2
https://bugs.freedesktop.org/show_bug.cgi?id=73014 Sylvain BERTRAND changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/8ae26267/attachment.html>
[PATCH] drm: armada: Use devm_ioremap_resource()
David,
On Mon, Feb 10, 2014 at 7:57 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> devm_request_and_ioremap() is deprecated, so use devm_ioremap_resource()
> instead.
>
> Signed-off-by: Fabio Estevam
> ---
Any comments about this one?
> drivers/gpu/drm/armada/armada_crtc.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> b/drivers/gpu/drm/armada/armada_crtc.c
> index d8e3982..2b6e7b7 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -1037,11 +1037,9 @@ int armada_drm_crtc_create(struct drm_device *dev,
> unsigned num,
> if (ret)
> return ret;
>
> - base = devm_request_and_ioremap(dev->dev, res);
> - if (!base) {
> - DRM_ERROR("failed to ioremap register\n");
> - return -ENOMEM;
> - }
> + base = devm_ioremap_resource(dev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
>
> dcrtc = kzalloc(sizeof(*dcrtc), GFP_KERNEL);
> if (!dcrtc) {
> --
> 1.8.1.2
>
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 --- Comment #17 from lockheed --- Update: 1. radeon.dpm=1, compton backed: both "xrender" and "glx" Crash occurs. 2. radeon.dpm=0, "glx" compton backend (did not feel the need to test xrender) I have been working with a VNC session over few hours quite heavily (which usually causes the crash very quickly) and crash has not occurred. So it looks like it is DPM-related, and my guess is it occurs when the frequency stepping is changed. However, with radeon.dpm=0 the GPU temp is about 15-20 C higher, even with dynpm on. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/1638cf26/attachment.html>
[Bug 74190] scrypt doesn't do anything with bfgminer on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=74190 Thomas Rohloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Thomas Rohloff --- (In reply to comment #1) > This may be the same issue I reported in > https://bugs.freedesktop.org/show_bug.cgi?id=74140 > > If you check CPU usage, you should see a thread stuck at 100% - this is > apparently it trying to compile the opencl program. I have not tried > waiting a long time to see if it does eventually fire up. Yes, that seems to be it. But there seems to be a memory leak, too. The thread eats up more and more RAM. Also after each [2014-02-24 10:00:47] OCL 0: Idle for more than 60 seconds, declaring SICK! [2014-02-24 10:00:47] OCL 0: Attempting to restart [2014-02-24 10:00:47] Thread 0 still exists, killing it off [2014-02-24 10:00:48] Thread 0 restarted it eats +1 core (so first 100%, then after that 200%, after the next 300% and so on). This repeats till it's killed cause of no more free RAM. Should I add this information to your bug report? *** This bug has been marked as a duplicate of bug 74140 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/77898503/attachment-0001.html>
[Bug 74140] scrypt mining via bfgminer generates a too large opencl kernel
https://bugs.freedesktop.org/show_bug.cgi?id=74140 Thomas Rohloff changed: What|Removed |Added CC||v10lator at myway.de --- Comment #1 from Thomas Rohloff --- *** Bug 74190 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/294f8f41/attachment-0001.html>
3.13 i915 brightness settings broken when going from docked -> undocked
On Sun, 23 Feb 2014 10:50:59 -0500
Josh Boyer wrote:
> On Thu, Feb 20, 2014 at 07:31:41PM -0500, Josh Boyer wrote:
> >On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer
> >wrote:
> >> Hi All,
> >>
> >> We've had a rather weird report[1] of the brightness adjustments being
> >> broken in a specific case with Thinkpad x220 hardware (SandyBridge
> >> based). If you boot the machine with it in a dock and then undock,
> >> the brightness adjustments do not work. That is with either the FN
> >> keys or the GNOME brightness slider.
> >>
> >> I can see that the value of
> >> /sys/class/backlight/acpi_video0/brightness increases/decreases but
> >> /sys/class/backlight/intel_backlight/brightness doesn't reflect any
> >> changes. With 3.12 this works, and oddly with 3.14-rc1 it works
> >> (specifically, it starts working around v3.13-10231-g53d8ab2 which is
> >> right after the first DRM merge for 3.14). With 3.13, if I undock and
> >> echo a higher value in the intel_backlight_brightness sysfs entry, the
> >> brightness will actually increase so it can be done manually, but it
> >> does not work as you'd expect.
> >>
> >> I'm in the middle of trying to do a reverse bisect for which patch
> >> fixes it in the 3.14-rcX series, but that's taking a while. I thought
> >> I'd email and see if anyone already knows about this situation, what
> >> patch in 3.13 broke this, and which one then fixed it again. Thus far
> >> all I've gathered is that backlight handling is confusing.
> >
> >The reverse bisect between 3.13 and 3.14-rc1 didn't prove fruitful,
> >either because I messed it up or there's a combination of things that
> >fix the issue. So instead I did a regular git bisect between 3.12 and
> >3.13 to see which commit _broke_ things and caused the above behavior.
> > That landed me at:
> >
> >Author: Jesse Barnes
> >Date: Thu Oct 31 18:55:49 2013 +0200
> >
> >drm/i915: make backlight functions take a connector
> >
> >I have no idea if that makes sense or not, but it's at least something
> >that seems to be in a relevant area of code. Does anyone involved in
> >that know why it would cause the above symptoms on 3.13, and which
> >commit(s) fix it in 3.14-rc1?
>
> Since nobody is replying I poked around a bit myself. The one commit
> that looks somewhat relevant in 3.14-rc1 seems to be:
>
> commit c91c9f32843a1b433de5a1ead4789a6bc8d3d914
> Author: Jani Nikula
> Date: Fri Nov 8 16:48:55 2013 +0200
>
> drm/i915: make asle notifications update backlight on all connectors
>
> That doesn't apply cleanly on 3.13 because of the other reworks that
> went in first, so I came up with the patch below. It seems to fix it
> for my machine, but I'm waiting for confirmation from the original bug
> reporter still. Maybe this will elicit some comments?
>
> josh
>
> Backport of upstream commit c91c9f328
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_opregion.c | 31 ++-
> drivers/gpu/drm/i915/intel_panel.c| 4
> 3 files changed, 11 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 221ac62..d6d4349 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1371,6 +1371,7 @@ typedef struct drm_i915_private {
>
> /* backlight */
> struct {
> + bool present;
> int level;
> bool enabled;
> spinlock_t lock; /* bl registers and the above bl fields */
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 6d69a9b..b2a51ae 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -414,38 +414,19 @@ static u32 asle_set_backlight(struct drm_device *dev,
> u32 bclp)
> return ASLC_BACKLIGHT_FAILED;
>
> mutex_lock(&dev->mode_config.mutex);
> - /*
> - * Could match the OpRegion connector here instead, but we'd also need
> - * to verify the connector could handle a backlight call.
> - */
> - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head)
> - if (encoder->crtc == crtc) {
> - found = true;
> - break;
> - }
> -
> - if (!found) {
> - ret = ASLC_BACKLIGHT_FAILED;
> - goto out;
> - }
>
> - list_for_each_entry(connector, &dev->mode_config.connector_list, head)
> - if (connector->encoder == encoder)
> - intel_connector = to_intel_connector(connector);
> -
> - if (!intel_connector) {
> - ret = ASLC_BACKLIGHT_FAILED;
> - goto out;
> + DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> + intel_connector = to_intel_connector(connector);
> + if (dev_priv->b
Build error: MSM DRM
On Mon, Feb 24, 2014 at 6:15 AM, Russell King - ARM Linux wrote: > Automated build testing of allmodconfig discovered this error in the > MSM DRM driver: > > drivers/gpu/drm/msm/hdmi/hdmi.o:(.rodata+0x10): multiple definition of > `__mod_of_device_table' > drivers/gpu/drm/msm/adreno/a3xx_gpu.o:(.rodata+0x4dc): first defined here > > It appears that this will happen whenever the MSM DRM driver is built > as a module. It's unclear what the correct fix is - since making it a > "bool" will make it unusable if the rest of DRM is configured modular, > and it's not trivial to split these files. fwiw, I was hoping https://lkml.org/lkml/2014/1/27/340 would get merged, as that should also fix this build error (same in tilcdc).. but making it a bool instead of tristate is probably ok for a short term solution. > Since this is yet another multiple-device monstrosity pretending to look > like a single device (though slightly saner than other stuff, but still > ultimately unsafe - nothing guarantees for instance that hdmi_pdev > remains valid) the right solution to this would be to convert the thing > to use the component infrastructure included in v3.14-rc, which then > allows the MSM driver to be multiple stand alone modules. haven't had a chance to look at the component infrastructure stuff yet, but this was my plan. It is the better long term solution. BR, -R > This is clearly what the driver needs if it's actually made up from > multiple drivers. > > While there's no examples of how to do this in mainline yet, two examples > of such converted drivers have been posted on LAKML and elsewhere - which > are the imx-drm and armada-drm drivers. > > -- > FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly > improving, and getting towards what was expected from it. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 75061] bug in clearing color buffer
https://bugs.freedesktop.org/show_bug.cgi?id=75061 Michel D?nzer changed: What|Removed |Added Assignee|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org Component|Other |Drivers/Gallium/r600 --- Comment #11 from Michel D?nzer --- AFAICT the problem is that both threads access the same struct r600_resource concurrently. It might be relatively easy to avoid the crashes by updating the buf member atomically in r600_init_resource() instead of setting it to NULL first in r600_invalidate_buffer(), but I suspect there could be more subtle issues with other members, in particular valid_buffer_range. Marek, any thoughts on how to solve this? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/544d7383/attachment.html>
[Bug 75371] System hang with kernel 3.13 while playing Left 4 Dead 2
https://bugs.freedesktop.org/show_bug.cgi?id=75371 --- Comment #3 from Michel D?nzer --- (In reply to comment #0) > dpm was also manually enabled with 3.12 and before, so it's likely not > related to that. I think it's still worth testing if the problem occurs with DPM explicitly disabled via radeon.dpm=0. (In reply to comment #2) > No, that would take forever and I have don't that much time ;) Please reconsider. For every gaming session, you should be able to declare at least one commit good or bad. It shouldn't take more than a dozen or so tests to isolate the problem with git bisect. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/c487a360/attachment.html>
[Bug 75357] Barts (HD6850): Failure in evergreen_surface_check_2d
https://bugs.freedesktop.org/show_bug.cgi?id=75357 --- Comment #5 from Michel D?nzer --- Does Option "ColorTiling2D" "off" in xorg.conf work around the problem, or at least the error messages in dmesg? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/8319750d/attachment.html>
[Bug 75361] freeze in Mass Effect 3 (wine)
https://bugs.freedesktop.org/show_bug.cgi?id=75361 --- Comment #2 from Michel D?nzer --- Please attach /var/log/Xorg.0.log and the output of glxinfo and dmesg. What exactly are the symptoms? What does '?' mean at the end of the attachment? (In reply to comment #2) > Need dump apitrace? That might be useful. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140224/3a547421/attachment.html>
