[PULL] drm-intel-next
Hi Dave, drm-intel-next-2014-08-22: - basic code for execlist, which is the fancy new cmd submission on gen8. Still disabled by default (Ben, Oscar Mateo, Thomas Daniel et al) - remove the useless usage of console_lock for I915_FBDEV=n (Chris) - clean up relations between ctx and ppgtt - clean up ppgtt lifetime handling (Michel Thierry) - various cursor code improvements from Ville - execbuffer code cleanups and secure batch fixes (Chris) - prep work for dev -> dev_priv transition (Chris) - some of the prep patches for the seqno -> request object transition (Chris) - various small improvements all over Plus a fix from Imre to make sure this pull doesn't break suspend/resume badly on a bunch of machines on top. Cheers, Daniel The following changes since commit 2c0827cffca8ac0c654b888c58a1989a5172f007: drm/i915: Update DRIVER_DATE to 20140808 (2014-08-08 20:44:59 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-09-01 for you to fetch changes up to 604effb782a8a4d9a20c8af16bcbf86d742db119: drm/i915: fix suspend/resume for GENs w/o runtime PM support (2014-08-26 13:13:03 +0200) Ben Widawsky (2): drm/i915/bdw: Implement context switching (somewhat) drm/i915/bdw: Print context state in debugfs Chris Wilson (12): drm/i915: Only perform set-to-gtt domain for objects bound to the global gtt drm/i915: Force CPU relocations if not GTT mapped drm/i915: Remove fenced_gpu_access and pending_fenced_gpu_access drm/i915: Copy PCI device id into the device info block drm/i915: Double check ring is idle before declaring the GPU wedged drm/i915: Agnostic INTEL_INFO drm/i915: Pre-validate the NEED_GTTS flag for execbuffer drm/i915: Remove redundant list_empty(eb->vmas) tests in execbuffer drm/i915: Simplify relocate_entry_gtt() and make 64-bit safe drm/i915: Replace __I915__ with typesafe variant drm/i915: Localise the fbdev console lock frobbing drm/i915: Print captured bo for all VM in error state Damien Lespiau (5): drm/i915: Fix erroneous conversion to u8 drm/i915: Fix wrong number of HDMI translation entries drm/i915: Make intel_disable_shared_dpll() static drm/i915: Remove set but unused 'gt_perf_status' drm/i915/bdw: Disable execlists by default Daniel Vetter (18): drm/i915: Fix secure dispatch with full ppgtt drm/i915: WARN if module opt sanitization goes out of order drm/i915/bdw: Add a context and an engine pointers to the ringbuffer drm/i915: Some cleanups for the ppgtt lifetime handling drm/i915: Track file_priv, not ctx in the ppgtt structure drm/i915: Only refcount ppgtt if it actually is one drm/i915: Add proper prefix to obj_to_ggtt drm/i915: Allow i915_gem_setup_global_gtt to fail drm/i915: Fix up checks for aliasing ppgtt drm/i915: Rework ppgtt init to no require an aliasing ppgtt drm/i915: Initialize the aliasing ppgtt as part of global gtt drm/i915: Only track real ppgtt for a context drm/i915: Drop create_vm argument to i915_gem_create_context drm/i915: Extract common cleanup into i915_ppgtt_release drm/i915: Extract commmon global gtt cleanup code drm/i915: Cleanup aliasging ppgtt alongside the global gtt drm/i915: Track cursor changes as frontbuffer tracking flushes drm/i915: Update DRIVER_DATE to 20140822 Imre Deak (1): drm/i915: fix suspend/resume for GENs w/o runtime PM support Michel Thierry (2): drm/i915: vma/ppgtt lifetime rules drm/i915/bdw: Two-stage execlist submit process Oscar Mateo (33): drm/i915/bdw: New source and header file for LRs, LRCs and Execlists drm/i915/bdw: Macro for LRCs and module option for Execlists drm/i915/bdw: Initialization for Logical Ring Contexts drm/i915/bdw: Introduce one context backing object per engine drm/i915/bdw: A bit more advanced LR context alloc/free drm/i915/bdw: Allocate ringbuffers for Logical Ring Contexts drm/i915/bdw: Populate LR contexts (somewhat) drm/i915/bdw: Deferred creation of user-created LRCs drm/i915: Abstract the legacy workload submission mechanism away drm/i915/bdw: Skeleton for the new logical rings submission path drm/i915/bdw: Generic logical ring init and cleanup drm/i915/bdw: GEN-specific logical ring init drm/i915/bdw: GEN-specific logical ring set/get seqno drm/i915/bdw: New logical ring submission mechanism drm/i915/bdw: GEN-specific logical ring emit request drm/i915/bdw: GEN-specific logical ring emit flush drm/i915/bdw: Ring idle and stop with logical rings drm/i915/bdw: Interrupts with logical rings drm/i915/bdw: GEN-specific logical ring emit batchbuffer start drm/i915/bdw: Workload submission mechanism for Execlists
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #34 from Andy Furniss --- (In reply to comment #29) > I also reported on irc Valley stutter on Kabini, but now i am somhow > against reverting because performance suffer with reverting in other games. > > One other reason simply because i tested it first time on Windows today and > there i have stutter even worse then then any case we have here :D. And i > did't know that :D DX11/DX9/OpenGL any mode all stutter a lot. Our worst > combination is a lot smoother than with Catalyst on Windows :). I tried on Windows with the same settings and you are right that there are stutters. For me they are about 10x shorter than my best Linux case, which means that some effectively don't exist and the ones that do are more like a frame or two. It does I guess illustrate that Valley may be doing something stupid - some are in the same places I see on Linux. > So question is, is there other stuter examples than Unigine Valley? Will have to test more - there are some with Initially with Unreal Reflections. I am using a pure 64bit setup, which means I don't get to test steam or etqw - you may have a point that if only Valley is really bad and other things gain Valley may be an exception that could be sacrificed. -- 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/20140901/7f2d9463/attachment.html>
[Bug 83651] New: radeon: kernel returns invalid information about video connectors' status
https://bugzilla.kernel.org/show_bug.cgi?id=83651 Bug ID: 83651 Summary: radeon: kernel returns invalid information about video connectors' status Product: Drivers Version: 2.5 Kernel Version: 3.16.1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: newgarry at mail.ru Regression: No Information obtained from kernel sys subsystem about ATI HD 5650 card's connectors status doesn't reflects real existing situation. That prevents higher level systems using the obtained information from working correctly. For example, systemd uses that information to decide what to do on lid close event (related bug report, https://bugs.freedesktop.org/show_bug.cgi?id=76267#c13). My laptop have hybrid video configuration (Intel + discrete ATI). The discrete ATI card is always powered off by init script via vgaswitcheroo interface on system boot. There aren't external connected monitors. Following is the valid report from kernel about the Intel card after system boot: # cat /sys/class/drm/card0-LVDS-1/status connected # cat /sys/class/drm/card0-VGA-1/status disconnected Following is the invalid report from kernel about the ATI card after system boot: # cat /sys/class/drm/card1-LVDS-2/status connected # cat /sys/class/drm/card1-VGA-2/status connected # cat /sys/class/drm/card1-HDMI-A-1/status disconnected Report from vgaswitcheroo interface: # cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Off::01:00.0 2:DIS-Audio: :Off::01:00.1 lspci: # lspci | grep -i vga 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M] (rev ff) # lspci -n | grep 0300 00:02.0 0300: 8086:0046 (rev 18) 01:00.0 0300: 1002:68c1 (rev ff) Kernel: 3.16.1 Thank you in advance! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #35 from Andy Furniss --- (In reply to comment #33) > (In reply to comment #28) > > > I submitted the change reverting the behaviour of PIPE_USAGE_STREAM for > > > review, but it's strange: I couldn't notice any significant difference in > > > stutter in Valley regardless of any of these changes. > > Also, according to > GALLIUM_HUD=requested-VRAM+VRAM-usage,requested-GTT+GTT-usage, Valley only > seems to allocate about 10-20 MB for streaming BOs, so I'm not sure why > putting them in VRAM or not makes such a big difference for you. > > > > > BTW, what CPU are you using? > > > > It's an AMD Phenom II x4 965be. > > I assume the chipset for that doesn't support PCIe 3.0, does it? I wonder if > maybe streaming BOs should be in VRAM with PCIe 3.0 but not with PCIe 2.0. Yea I am PCIE 2.0. Other settings which may or may not be relavent - vblank_mode=0, swapbufferswait off, 1920x1080 fullscreen, quality high, antialiasing off. I tried with hud and see 10-20MB requested with the stream change reverted and 8kb with it. The fps counter on hud does show the pauses - though even the good case looks bad on that - but the biggest pauses it shows are between scenes when the screen has faded to black, I guess you kind of expect something to be loading then. I'll upload a couple of screens. -- 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/20140901/4c6dec48/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #36 from Andy Furniss --- Created attachment 105543 --> https://bugs.freedesktop.org/attachment.cgi?id=105543&action=edit valley worse pausing with stream buffer change -- 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/20140901/0900a883/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #37 from Andy Furniss --- Created attachment 105544 --> https://bugs.freedesktop.org/attachment.cgi?id=105544&action=edit valley better with stream buffer change reverted -- 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/20140901/7e2b27db/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #38 from Andy Furniss --- (In reply to comment #36) > Created attachment 105543 [details] > valley worse pausing with stream buffer change I notice that I seem to be pegged more to a single core on this one. -- 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/20140901/1b4bac34/attachment.html>
[Mesa-dev] [PATCH] r600g, radeonsi: Inform the kernel if a BO will likely be accessed by the CPU
Reviewed-by: Marek Ol??k
Marek
On Thu, Aug 28, 2014 at 8:56 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> This allows the kernel to prevent such BOs from ever being stored in the
> CPU inaccessible part of VRAM.
>
> Signed-off-by: Michel D?nzer
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 23 ++-
> src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 8 +++-
> src/gallium/winsys/radeon/drm/radeon_winsys.h | 3 ++-
> 3 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index acdabc0..1a6e97d 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
> @@ -126,6 +126,7 @@ bool r600_init_resource(struct r600_common_screen
> *rscreen,
> flags = RADEON_FLAG_GTT_WC;
> break;
> }
> + flags = RADEON_FLAG_CPU_ACCESS;
> /* fall through */
> case PIPE_USAGE_DEFAULT:
> case PIPE_USAGE_IMMUTABLE:
> @@ -136,23 +137,27 @@ bool r600_init_resource(struct r600_common_screen
> *rscreen,
> break;
> }
>
> - /* Use GTT for all persistent mappings with older kernels, because
> they
> -* didn't always flush the HDP cache before CS execution.
> -*
> -* Write-combined CPU mappings are fine, the kernel ensures all CPU
> -* writes finish before the GPU executes a command stream.
> -*/
> - if (rscreen->info.drm_minor < 40 &&
> - res->b.b.target == PIPE_BUFFER &&
> + if (res->b.b.target == PIPE_BUFFER &&
> res->b.b.flags & (PIPE_RESOURCE_FLAG_MAP_PERSISTENT |
> PIPE_RESOURCE_FLAG_MAP_COHERENT)) {
> - res->domains = RADEON_DOMAIN_GTT;
> + /* Use GTT for all persistent mappings with older kernels,
> +* because they didn't always flush the HDP cache before CS
> +* execution.
> +*
> +* Write-combined CPU mappings are fine, the kernel ensures
> all CPU
> +* writes finish before the GPU executes a command stream.
> +*/
> + if (rscreen->info.drm_minor < 40)
> + res->domains = RADEON_DOMAIN_GTT;
> + else if (res->domains & RADEON_DOMAIN_VRAM)
> + flags |= RADEON_FLAG_CPU_ACCESS;
> }
>
> /* Tiled textures are unmappable. Always put them in VRAM. */
> if (res->b.b.target != PIPE_BUFFER &&
> rtex->surface.level[0].mode >= RADEON_SURF_MODE_1D) {
> res->domains = RADEON_DOMAIN_VRAM;
> + flags &= ~RADEON_FLAG_CPU_ACCESS;
> }
>
> /* Allocate a new resource. */
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> index 73f8d38..03b9b1d 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> @@ -478,7 +478,11 @@ const struct pb_vtbl radeon_bo_vtbl = {
> };
>
> #ifndef RADEON_GEM_GTT_WC
> -#define RADEON_GEM_GTT_WC (1 << 2)
> +#define RADEON_GEM_GTT_WC (1 << 2)
> +#endif
> +#ifndef RADEON_GTM_CPU_ACCESS
> +/* BO is expected to be accessed by the CPU */
> +#define RADEON_GEM_CPU_ACCESS (1 << 3)
> #endif
>
> static struct pb_buffer *radeon_bomgr_create_bo(struct pb_manager *_mgr,
> @@ -505,6 +509,8 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct
> pb_manager *_mgr,
>
> if (rdesc->flags & RADEON_FLAG_GTT_WC)
> args.flags |= RADEON_GEM_GTT_WC;
> +if (rdesc->flags & RADEON_FLAG_CPU_ACCESS)
> +args.flags |= RADEON_GEM_CPU_ACCESS;
>
> if (drmCommandWriteRead(rws->fd, DRM_RADEON_GEM_CREATE,
> &args, sizeof(args))) {
> diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h
> b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> index dbd58f1..69bf6ed 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
> +++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> @@ -66,7 +66,8 @@ enum radeon_bo_domain { /* bitfield */
> };
>
> enum radeon_bo_flag { /* bitfield */
> - RADEON_FLAG_GTT_WC = (1 << 0)
> +RADEON_FLAG_GTT_WC = (1 << 0),
> +RADEON_FLAG_CPU_ACCESS = (1 << 1),
> };
>
> enum radeon_bo_usage { /* bitfield */
> --
> 2.1.0
>
> ___
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #123 from langkamp at tomblog.de --- > Yes, me. We just spoke at github. Never had x crashes or lockups. My specs (was in a hurry yesterday): HD7950 Core2Quad Kernel 3.16 (openSUSE Factory, x64, KDE+desktopeffects) Rest from git (mesa, llvm, ati, xserver) did not test chrome, but firefox and its old flash (11.2) or steam games never gave me x-crashes or lockups on radeonSI. Also earlier kernel versions (openSUSE Tumbleweed) made no problem. cheers tomtomme -- 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/20140901/300bd30b/attachment.html>
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828
--- Comment #8 from Pavel Ondra?ka ---
Ok, so indeed I got NO_REG for g->nodes[n2].reg
print g->nodes[n2].reg
$1 = 4294967295
than I set breakpoint at end of ra_simplify (it gets called just once before
the crash)
Breakpoint 1, ra_simplify (g=0x80c2058)
at ../../src/mesa/program/register_allocate.c:491
491}
(gdb) print g->count
$2 = 3
print g->nodes[0]
$3 = {adjacency = 0x81b8968, adjacency_list = 0x80c1658,
adjacency_list_size = 4, adjacency_count = 3, class = 0, reg = 4294967295,
in_stack = false, q_total = 4294967295, spill_cost = 0}
print g->nodes[1]
$4 = {adjacency = 0x81b3d18, adjacency_list = 0x80c1b58,
adjacency_list_size = 4, adjacency_count = 3, class = 2, reg = 4294967295,
in_stack = true, q_total = 2, spill_cost = 0}
print g->nodes[2]
$5 = {adjacency = 0x81c0328, adjacency_list = 0x80c18d8,
adjacency_list_size = 4, adjacency_count = 3, class = 3, reg = 4294967295,
in_stack = true, q_total = 4, spill_cost = 0}
--
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/20140901/1f185a5a/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #64 from Christian K?nig --- (In reply to comment #58) > I would also like to add, if this happens three times in quick succession > (Have chrome running with an OpenGL game starting/Level loading in a game) > it'll sometimes have 3 quick fail and recovers. If it does happen 3 times in > a row, X dies and it throws up a few "Couldn't schedule IB" with possibly a > previous "Still active IB in BO." or two to the kernel log. This is pretty > rare, but about one out of every 5 crashes when I'm starting a game and > Chromium/Mesa fail to start the OpenGL app will fail in such a manner, > although it has also happened with just Chromium, but that is much more rare. Regarding this you could try Alex drm-next-3.18 branch, it contains some reset work from Maarten Lankhorst and me and should address this issue. But nerveless bisecting what causes the crash to appear between mesa 10.1.4 and 10.2 sound like a good idea to me. -- 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/20140901/4df90ae8/attachment.html>
[PATCH 1/2] drm/vmwgfx: Fix an incorrect OOM return value
At the same time, make error paths return early for clarity.
Signed-off-by: Thomas Hellstrom
Reported-by: Dan Carpenter
Reviewed-by: jakob Bornecrantz
Cc:
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 7bfdaa1..36b8716 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -450,11 +450,11 @@ static int vmw_cmd_res_reloc_add(struct vmw_private
*dev_priv,
res,
id_loc - sw_context->buf_start);
if (unlikely(ret != 0))
- goto out_err;
+ return ret;
ret = vmw_resource_val_add(sw_context, res, &node);
if (unlikely(ret != 0))
- goto out_err;
+ return ret;
if (res_type == vmw_res_context && dev_priv->has_mob &&
node->first_usage) {
@@ -468,13 +468,13 @@ static int vmw_cmd_res_reloc_add(struct vmw_private
*dev_priv,
ret = vmw_resource_context_res_add(dev_priv, sw_context, res);
if (unlikely(ret != 0))
- goto out_err;
+ return ret;
node->staged_bindings =
kzalloc(sizeof(*node->staged_bindings), GFP_KERNEL);
if (node->staged_bindings == NULL) {
DRM_ERROR("Failed to allocate context binding "
"information.\n");
- goto out_err;
+ return -ENOMEM;
}
INIT_LIST_HEAD(&node->staged_bindings->list);
}
@@ -482,8 +482,7 @@ static int vmw_cmd_res_reloc_add(struct vmw_private
*dev_priv,
if (p_val)
*p_val = node;
-out_err:
- return ret;
+ return 0;
}
--
1.8.3.2
[PATCH 2/2] drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle
The code waiting for fifo idle was incorrect and could possibly spin forever under certain circumstances. Signed-off-by: Thomas Hellstrom Reported-by: Mark Sheldon Reviewed-by: Jakob Bornecrantz Reivewed-by: Mark Sheldon Cc: --- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c index 6ccd993..6eae14d 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c @@ -180,8 +180,9 @@ void vmw_fifo_release(struct vmw_private *dev_priv, struct vmw_fifo_state *fifo) mutex_lock(&dev_priv->hw_mutex); + vmw_write(dev_priv, SVGA_REG_SYNC, SVGA_SYNC_GENERIC); while (vmw_read(dev_priv, SVGA_REG_BUSY) != 0) - vmw_write(dev_priv, SVGA_REG_SYNC, SVGA_SYNC_GENERIC); + ; dev_priv->last_read_seqno = ioread32(fifo_mem + SVGA_FIFO_FENCE); -- 1.8.3.2
[Bug 83012] Unigine Tropics horrible performance with vblank_mode=2 (which is the default) or =3
https://bugs.freedesktop.org/show_bug.cgi?id=83012 --- Comment #3 from Marek Ol??k --- Why don't we disable vsync by default? I think that's what proprietary drivers do. -- 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/20140901/f2c6ab81/attachment.html>
[PULL] vmwgfx-fixes-3.17
Dave, Two fixes for vmwgfx. Both with CC stable. The following changes since commit a284e9d14e35b776807c3a40dd1ff1e05429d4a4: MAINTAINERS: Add entry for Renesas DRM drivers (2014-08-24 16:37:47 +1000) are available in the git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-3.17 for you to fetch changes up to f01ea0c3d9db536c64d47922716d8b3b8f21d850: drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle (2014-09-01 12:31:24 +0200) Thomas Hellstrom (2): drm/vmwgfx: Fix an incorrect OOM return value drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 11 +-- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 3 ++- 2 files changed, 7 insertions(+), 7 deletions(-)
[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319 --- Comment #2 from Marek Ol??k --- Yeah, texturing in geometry shaders hangs. The problem might be that the GS RING constant buffer is bound to slot 16, which isn't a valid constant buffer slot (the last one is 15). -- 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/20140901/c74368a4/attachment-0001.html>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #20 from Kamil P?ral --- Oleg, thanks a lot! Alex (or anyone else, particularly if you're from AMD): would it be possible to point Oleg to the relevant documentation if it exists, or at least find out whether it can be published in the near future (if it doesn't exist publicly yet), so that it doesn't have to reverse-engineered from scratch? Many thanks for any helpful info. -- 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/20140901/4c98213e/attachment.html>
[PULL REQUEST] ttm fence conversion
The following changes since commit 04cd214516d8a6f0f8c0116185d6e360df0860d2: Merge branch 'drm-next-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-next (2014-08-28 13:45:45 +1000) are available in the git repository at: ssh://people.freedesktop.org/~mlankhorst/linux for-airlied-next for you to fetch changes up to d591829ffd785ee27c82becc67673ce70b21cb83: drm/nouveau: use shared fences for readable objects (2014-09-01 11:09:39 +0200) \o/ radeon gpu reset rework is in -next, time for fences! Maarten Lankhorst (18): drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence drm/ttm: call ttm_bo_wait while inside a reservation drm/ttm: kill fence_lock drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers drm/ttm: kill off some members to ttm_validate_buffer drm/radeon: use common fence implementation for fences, v3 drm/vmwgfx: get rid of different types of fence_flags entirely drm/vmwgfx: rework to new fence interface, v2 drm/nouveau: rework to new fence interface drm/qxl: rework to new fence interface drm/ttm: flip the switch, and convert to dma_fence drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep drm/radeon: use rcu waits in some ioctls drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab drm/ttm: use rcu in core ttm drm/nouveau: Keep only a single list for validation. drm/nouveau: use shared fences for readable objects drivers/gpu/drm/nouveau/nouveau_bo.c | 64 +--- drivers/gpu/drm/nouveau/nouveau_bo.h | 2 +- drivers/gpu/drm/nouveau/nouveau_display.c | 27 +- drivers/gpu/drm/nouveau/nouveau_fence.c | 518 -- drivers/gpu/drm/nouveau/nouveau_fence.h | 26 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 178 +- drivers/gpu/drm/nouveau/nv04_fence.c | 6 +- drivers/gpu/drm/nouveau/nv10_fence.c | 6 +- drivers/gpu/drm/nouveau/nv17_fence.c | 4 +- drivers/gpu/drm/nouveau/nv50_fence.c | 4 +- drivers/gpu/drm/nouveau/nv84_fence.c | 22 +- drivers/gpu/drm/qxl/Makefile | 2 +- drivers/gpu/drm/qxl/qxl_cmd.c | 7 - drivers/gpu/drm/qxl/qxl_debugfs.c | 16 +- drivers/gpu/drm/qxl/qxl_drv.h | 20 +- drivers/gpu/drm/qxl/qxl_fence.c | 91 -- drivers/gpu/drm/qxl/qxl_kms.c | 1 + drivers/gpu/drm/qxl/qxl_object.c | 2 - drivers/gpu/drm/qxl/qxl_object.h | 6 +- drivers/gpu/drm/qxl/qxl_release.c | 172 -- drivers/gpu/drm/qxl/qxl_ttm.c | 93 -- drivers/gpu/drm/radeon/radeon.h | 15 +- drivers/gpu/drm/radeon/radeon_cs.c| 10 +- drivers/gpu/drm/radeon/radeon_device.c| 6 +- drivers/gpu/drm/radeon/radeon_display.c | 7 +- drivers/gpu/drm/radeon/radeon_fence.c | 256 +-- drivers/gpu/drm/radeon/radeon_gem.c | 20 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 43 +++ drivers/gpu/drm/radeon/radeon_mn.c| 6 +- drivers/gpu/drm/radeon/radeon_object.c| 8 +- drivers/gpu/drm/radeon/radeon_ttm.c | 34 +- drivers/gpu/drm/radeon/radeon_uvd.c | 6 +- drivers/gpu/drm/radeon/radeon_vm.c| 17 +- drivers/gpu/drm/ttm/ttm_bo.c | 187 +-- drivers/gpu/drm/ttm/ttm_bo_util.c | 28 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 3 - drivers/gpu/drm/ttm/ttm_execbuf_util.c| 146 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c| 47 --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 24 +- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 346 +++- drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 35 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 11 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 43 ++- include/drm/ttm/ttm_bo_api.h | 7 +- include/drm/ttm/ttm_bo_driver.h | 29 +- include/drm/ttm/ttm_execbuf_util.h| 22 +- 47 files changed, 1396 insertions(+), 1229 deletions(-) delete mode 100644 drivers/gpu/drm/qxl/qxl_fence.c
[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319 --- Comment #3 from Dieter N?tzel --- (In reply to comment #2) > Yeah, texturing in geometry shaders hangs. The problem might be that the GS > RING constant buffer is bound to slot 16, which isn't a valid constant > buffer slot (the last one is 15). Hello Marek! We're back from vacation, so...;-) Read about it (R600_MAX_CONST_BUFFERS) in Glenn Kennard patch: [Mesa-dev] [PATCH] r600g: Implement GL_ARB_sample_shading Is it that what you mean? Either way, following the shader dumps. BTW I have a broken screen shot for geom-outlining-150.png, too if you need. -- 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/20140901/bfcdf3ef/attachment.html>
[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319 --- Comment #4 from Dieter N?tzel --- Created attachment 105548 --> https://bugs.freedesktop.org/attachment.cgi?id=105548&action=edit gsraytrace-R600_DEBUG-ps-vs.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/20140901/596a684f/attachment.html>
[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319 --- Comment #5 from Dieter N?tzel --- Created attachment 105549 --> https://bugs.freedesktop.org/attachment.cgi?id=105549&action=edit gsraytrace-MESA_GLSL-dump.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/20140901/09a6ede1/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #39 from smoki --- (In reply to comment #34) > I tried on Windows with the same settings and you are right that there are > stutters. For me they are about 10x shorter than my best Linux case, which > means that some effectively don't exist and the ones that do are more like a > frame or two. It does I guess illustrate that Valley may be doing something > stupid - some are in the same places I see on Linux. Actually there is workaround on Windows by not using Aero, but some Basic theme So driver has problems with Aero or Aero with the driver and this app i don't know much about Windows i don't use it much of the time. If you let it run with Basic theme and few rounds you will spot i guess that only first round there is unusual maybe 2-3 times 1-2 sec sttuters, then second time and later it is stutter free. All in all people must not use Aero when play Valley, so app even on Windows is not 100% trouble free :) -- 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/20140901/aad99d02/attachment.html>
[PATCH] drm/exynos: update to use component match support
Update Exynos's DRM driver to use component match support rater than
add_components.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 40 ++-
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index feee991..dae62c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -503,16 +503,15 @@ static int compare_of(struct device *dev, void *data)
return dev == (struct device *)data;
}
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+ struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(&drm_component_lock);
list_for_each_entry(cdev, &drm_component_list, list) {
- int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -527,16 +526,10 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
-*
-* TODO. if dpi module follows driver-model driver then
-* below codes can be removed.
*/
if (cdev->crtc_dev == cdev->conn_dev) {
- ret = component_master_add_child(m, compare_of,
- cdev->crtc_dev);
- if (ret < 0)
- return ret;
-
+ component_match_add(dev, &match, compare_of,
+ cdev->crtc_dev);
goto out_lock;
}
@@ -546,11 +539,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
- ret = component_master_add_child(m, compare_of, cdev->crtc_dev);
- ret |= component_master_add_child(m, compare_of,
- cdev->conn_dev);
- if (ret < 0)
- return ret;
+ component_match_add(dev, &match, compare_of, cdev->crtc_dev);
+ component_match_add(dev, &match, compare_of, cdev->conn_dev);
out_lock:
mutex_lock(&drm_component_lock);
@@ -558,7 +548,7 @@ out_lock:
mutex_unlock(&drm_component_lock);
- return attach_cnt ? 0 : -ENODEV;
+ return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -572,13 +562,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
- .add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+ struct component_match *match;
int ret;
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -645,13 +635,19 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- ret = component_master_add(&pdev->dev, &exynos_drm_ops);
- if (ret < 0)
- DRM_DEBUG_KMS("re-tried by last sub driver probed later.\n");
+ match = exynos_drm_match_add(&pdev->dev);
+ if (IS_ERR(match)) {
+ ret = PTR_ERR(match);
+ goto err_unregister_ipp_dev;
+ }
- return 0;
+ return component_master_add_with_match(&pdev->dev, &exynos_drm_ops,
+ match);
+
+err_unregister_ipp_dev:
#ifdef CONFIG_DRM_EXYNOS_IPP
+ exynos_platform_device_ipp_unregister();
err_unregister_ipp_drv:
platform_driver_unregister(&ipp_driver);
err_unregister_gsc_drv:
--
1.7.9.5
[PULL REQUEST] ttm fence conversion
Please wait a second with that. I didn't had a chance to test this yet and nobody has yet given it's rb on at least the radeon changes in this branch. Christian. Am 01.09.2014 um 13:34 schrieb Maarten Lankhorst: > The following changes since commit 04cd214516d8a6f0f8c0116185d6e360df0860d2: > >Merge branch 'drm-next-3.18' of git://people.freedesktop.org/~agd5f/linux > into drm-next (2014-08-28 13:45:45 +1000) > > are available in the git repository at: > >ssh://people.freedesktop.org/~mlankhorst/linux for-airlied-next > > for you to fetch changes up to d591829ffd785ee27c82becc67673ce70b21cb83: > >drm/nouveau: use shared fences for readable objects (2014-09-01 11:09:39 > +0200) > > \o/ radeon gpu reset rework is in -next, time for fences! > > > Maarten Lankhorst (18): >drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep >drm/nouveau: require reservations for nouveau_fence_sync and > nouveau_bo_fence >drm/ttm: call ttm_bo_wait while inside a reservation >drm/ttm: kill fence_lock >drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers >drm/ttm: kill off some members to ttm_validate_buffer >drm/radeon: use common fence implementation for fences, v3 >drm/vmwgfx: get rid of different types of fence_flags entirely >drm/vmwgfx: rework to new fence interface, v2 >drm/nouveau: rework to new fence interface >drm/qxl: rework to new fence interface >drm/ttm: flip the switch, and convert to dma_fence >drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep >drm/radeon: use rcu waits in some ioctls >drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab >drm/ttm: use rcu in core ttm >drm/nouveau: Keep only a single list for validation. >drm/nouveau: use shared fences for readable objects > > drivers/gpu/drm/nouveau/nouveau_bo.c | 64 +--- > drivers/gpu/drm/nouveau/nouveau_bo.h | 2 +- > drivers/gpu/drm/nouveau/nouveau_display.c | 27 +- > drivers/gpu/drm/nouveau/nouveau_fence.c | 518 > -- > drivers/gpu/drm/nouveau/nouveau_fence.h | 26 +- > drivers/gpu/drm/nouveau/nouveau_gem.c | 178 +- > drivers/gpu/drm/nouveau/nv04_fence.c | 6 +- > drivers/gpu/drm/nouveau/nv10_fence.c | 6 +- > drivers/gpu/drm/nouveau/nv17_fence.c | 4 +- > drivers/gpu/drm/nouveau/nv50_fence.c | 4 +- > drivers/gpu/drm/nouveau/nv84_fence.c | 22 +- > drivers/gpu/drm/qxl/Makefile | 2 +- > drivers/gpu/drm/qxl/qxl_cmd.c | 7 - > drivers/gpu/drm/qxl/qxl_debugfs.c | 16 +- > drivers/gpu/drm/qxl/qxl_drv.h | 20 +- > drivers/gpu/drm/qxl/qxl_fence.c | 91 -- > drivers/gpu/drm/qxl/qxl_kms.c | 1 + > drivers/gpu/drm/qxl/qxl_object.c | 2 - > drivers/gpu/drm/qxl/qxl_object.h | 6 +- > drivers/gpu/drm/qxl/qxl_release.c | 172 -- > drivers/gpu/drm/qxl/qxl_ttm.c | 93 -- > drivers/gpu/drm/radeon/radeon.h | 15 +- > drivers/gpu/drm/radeon/radeon_cs.c| 10 +- > drivers/gpu/drm/radeon/radeon_device.c| 6 +- > drivers/gpu/drm/radeon/radeon_display.c | 7 +- > drivers/gpu/drm/radeon/radeon_fence.c | 256 +-- > drivers/gpu/drm/radeon/radeon_gem.c | 20 +- > drivers/gpu/drm/radeon/radeon_irq_kms.c | 43 +++ > drivers/gpu/drm/radeon/radeon_mn.c| 6 +- > drivers/gpu/drm/radeon/radeon_object.c| 8 +- > drivers/gpu/drm/radeon/radeon_ttm.c | 34 +- > drivers/gpu/drm/radeon/radeon_uvd.c | 6 +- > drivers/gpu/drm/radeon/radeon_vm.c| 17 +- > drivers/gpu/drm/ttm/ttm_bo.c | 187 +-- > drivers/gpu/drm/ttm/ttm_bo_util.c | 28 +- > drivers/gpu/drm/ttm/ttm_bo_vm.c | 3 - > drivers/gpu/drm/ttm/ttm_execbuf_util.c| 146 +++-- > drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c| 47 --- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 24 +- > drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 346 +++- > drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 35 +- > drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 11 +- > drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 43 ++- > include/drm/ttm/ttm_bo_api.h | 7 +- > include/drm/ttm/ttm_bo_driver.h | 29 +- > include/drm/ttm/ttm_execbuf_util.h| 22 +- > 47 files changed, 1396 insertions(+), 1229 deletions(-) > delete mode 100644 drivers/gpu/drm/qxl/qxl_fence.c > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319 --- Comment #6 from Marek Ol??k --- (In reply to comment #3) > (In reply to comment #2) > > Yeah, texturing in geometry shaders hangs. The problem might be that the GS > > RING constant buffer is bound to slot 16, which isn't a valid constant > > buffer slot (the last one is 15). > > Hello Marek! > > We're back from vacation, so...;-) > > Read about it (R600_MAX_CONST_BUFFERS) in Glenn Kennard > patch: > [Mesa-dev] [PATCH] r600g: Implement GL_ARB_sample_shading > > Is it that what you mean? Yes, but it's just a guess. It may or may not have anything to do with 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/20140901/c46b279d/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #40 from smoki --- (In reply to comment #39) > If you let it run with Basic theme and few rounds you will spot i guess > that only first round there is unusual maybe 2-3 times 1-2 sec stutters, > then second time and later it is stutter free. Andy, you have behavior like that (more or less those seconds for stuter) if PIPE_USAGE_STREAM is reverted, right? Then maybe that is the right way to go, global performance will suffer a little but if nothing better can't be done then revert of PIPE_USAGE_STREAM is OK :) -- 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/20140901/d70efecb/attachment.html>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #21 from Chernovsky Oleg --- (In reply to comment #20) > Oleg, thanks a lot! > > Alex (or anyone else, particularly if you're from AMD): would it be possible > to point Oleg to the relevant documentation if it exists, or at least find > out whether it can be published in the near future (if it doesn't exist > publicly yet), so that it doesn't have to reverse-engineered from scratch? > Many thanks for any helpful info. Actually I already come to some conclusions. First SMC writes and reads (before SMC_MESSAGE) is just the "ci_check_smc_running" function (seems its analogue presents in proprietary driver as well). 0x5c value should be some sort of command, so it can be defined with already known ones in headers. About other values things are not so clear. I suppose to get real fan speed we need to somehow mask and shift data at smc index 0xc0300064. I'll try to make other traces with different parameters to compare percentages and values to the register reads and writes. P.S. yep, some docs would be helpful, thanks -- 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/20140901/2ecdcf76/attachment.html>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #22 from Chernovsky Oleg --- Among other querstions - is this legal? I mean, taking traces from proprietary driver and trying to reverse-engineer it. I live in Russia if that's important -- 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/20140901/a10a7bc9/attachment.html>
[Intel-gfx] [PATCH] drm/edid: Reduce horizontal timings for pixel replicated modes
On Tue, Aug 19, 2014 at 02:21:21PM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor
>
> Pixel replicated modes should be 720 horizontal pixel and pixel
> replicated by the HW across the HDMI cable at 2X pixel clock. Current
> horizontal resolution of 1440 does not allow pixel duplication to
> occur and scaling artifacts occur on the TV. HDMI certification
> 7-26 currently fails for all pixel replicated modes. This change fizes
> the HDMI certification issues with 480i/576i.
>
> V2: Removed interlace flag from VICs 44 and 45. Will be submitted in
> another patch. Various other formatting fixes.
>
> V3: 576i at 200 htotal fixed. Check min and max pixel clocks.
>
> Signed-off-by: Clint Taylor
Assuming you split it up like Daniel wanted you can slap
Reviewed-by: Ville Syrj?l?
onto both parts.
> ---
> drivers/gpu/drm/drm_edid.c| 96
> ++---
> drivers/gpu/drm/i915/intel_hdmi.c | 15 --
> 2 files changed, 60 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index f905c63..dc25999 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -632,27 +632,27 @@ static const struct drm_display_mode edid_cea_modes[] =
> {
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
> DRM_MODE_FLAG_INTERLACE),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> - /* 6 - 1440x480i at 60Hz */
> - { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> -1602, 1716, 0, 480, 488, 494, 525, 0,
> + /* 6 - 720(1440)x480i at 60Hz */
> + { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> +801, 858, 0, 480, 488, 494, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> - /* 7 - 1440x480i at 60Hz */
> - { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> -1602, 1716, 0, 480, 488, 494, 525, 0,
> + /* 7 - 720(1440)x480i at 60Hz */
> + { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> +801, 858, 0, 480, 488, 494, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> - /* 8 - 1440x240 at 60Hz */
> - { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> -1602, 1716, 0, 240, 244, 247, 262, 0,
> + /* 8 - 720(1440)x240 at 60Hz */
> + { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> +801, 858, 0, 240, 244, 247, 262, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> - /* 9 - 1440x240 at 60Hz */
> - { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> -1602, 1716, 0, 240, 244, 247, 262, 0,
> + /* 9 - 720(1440)x240 at 60Hz */
> + { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> +801, 858, 0, 240, 244, 247, 262, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> @@ -714,27 +714,27 @@ static const struct drm_display_mode edid_cea_modes[] =
> {
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
> DRM_MODE_FLAG_INTERLACE),
> .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> - /* 21 - 1440x576i at 50Hz */
> - { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
> -1590, 1728, 0, 576, 580, 586, 625, 0,
> + /* 21 - 720(1440)x576i at 50Hz */
> + { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
> +795, 864, 0, 576, 580, 586, 625, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> - /* 22 - 1440x576i at 50Hz */
> - { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
> -1590, 1728, 0, 576, 580, 586, 625, 0,
> + /* 22 - 720(1440)x576i at 50Hz */
> + { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
> +795, 864, 0, 576, 580, 586, 625, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> - /
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #41 from Andy Furniss --- (In reply to comment #40) > (In reply to comment #39) > > If you let it run with Basic theme and few rounds you will spot i guess > > that only first round there is unusual maybe 2-3 times 1-2 sec stutters, > > then second time and later it is stutter free. > > Andy, you have behavior like that (more or less those seconds for stuter) > if PIPE_USAGE_STREAM is reverted, right? The Bad was with vanilla mesa (couple of days old) The good was that + the patch in Comment 19 I looked again at Unreal Reflections - there is a difference but it's only right at the start, both have a couple of stutters and they are longer with vanilla then the rest is OK in both cases. -- 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/20140901/2668dca6/attachment.html>
[pull] radeon drm-fixes-3.17
On 08/22/2014 10:52 AM, Alex Deucher wrote: > Hi Dave, > > This pull just contains some new pci ids. > > The following changes since commit 20a984c2a51d379bce08ee1031b32020f273e532: > >Merge tag 'drm-intel-fixes-2014-08-21' of > git://anongit.freedesktop.org/drm-intel (2014-08-22 07:29:52 +1000) > > are available in the git repository at: > > >git://people.freedesktop.org/~agd5f/linux drm-fixes-3.17 > > for you to fetch changes up to 37dbeab788a8f23fd946c0be083e5484d6f929a1: > >drm/radeon: add additional SI pci ids (2014-08-22 10:47:59 -0400) > > > Alex Deucher (3): >drm/radeon: add new KV pci id >drm/radeon: add new bonaire pci ids >drm/radeon: add additional SI pci ids > > drivers/gpu/drm/radeon/cik.c | 1 + > include/drm/drm_pciids.h | 7 +++ > 2 files changed, 8 insertions(+) > Is there any reason this pull can't go into fixes-3.16? or even 3.15? 3.17 is months away for me! Fedora 20 is on 3.15. sean
[PULL REQUEST] ttm fence conversion
Hey, Op 01-09-14 om 14:31 schreef Christian K?nig: > Please wait a second with that. > > I didn't had a chance to test this yet and nobody has yet given it's rb on at > least the radeon changes in this branch. Ok, my fault. I thought it was implicitly acked. I haven't made any functional changes to these patches, just some small fixups and a fix to make it apply after the upstream removal of RADEON_FENCE_SIGNALED_SEQ. ~Maarten
[PATCH] drm: Include task->name and master status in debugfs clients info
Hi
On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson
wrote:
> Showing who is the current master is useful for trying to decypher
> errors when trying to acquire master (e.g. a race with X taking over
> from plymouth). By including the process name as well as the pid
> simplifies the task of grabbing enough information remotely at the point
> of error.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_info.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
> index 15ec9f4..d813430 100644
> --- a/drivers/gpu/drm/drm_info.c
> +++ b/drivers/gpu/drm/drm_info.c
> @@ -184,14 +184,21 @@ int drm_clients_info(struct seq_file *m, void *data)
> struct drm_file *priv;
>
> mutex_lock(&dev->struct_mutex);
> - seq_printf(m, "a devpiduid magic\n\n");
> - list_for_each_entry(priv, &dev->filelist, lhead) {
> - seq_printf(m, "%c %3d %5d %5d %10u\n",
> - priv->authenticated ? 'y' : 'n',
> - priv->minor->index,
> + seq_printf(m, " pid dev master a uid
> magic\n");
Maybe mention "task" here? Or is this supposed to be a logical part of "pid"?
> + list_for_each_entry_reverse(priv, &dev->filelist, lhead) {
No idea why you do backwards traversal, but ok..
> + struct task_struct *task;
> +
> + rcu_read_lock();
What's that rcu-lock for? task->comm is pre-allocated, priv->pid is
static, kuid... no idea?
Anyway, patch looks good otherwise. Especially task->comm sounds
really handy in that list.
Thanks
David
> + task = pid_task(priv->pid, PIDTYPE_PID);
> + seq_printf(m, "%20s %5d %3d %c%c %5d %10u\n",
> + task ? task->comm : "",
>pid_vnr(priv->pid),
> + priv->minor->index,
> + priv->is_master ? 'y' : 'n',
> + priv->authenticated ? 'y' : 'n',
>from_kuid_munged(seq_user_ns(m), priv->uid),
>priv->magic);
> + rcu_read_unlock();
> }
> mutex_unlock(&dev->struct_mutex);
> return 0;
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Include task->name and master status in debugfs clients info
On Mon, Sep 01, 2014 at 04:11:43PM +0200, David Herrmann wrote:
> Hi
>
> On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson
> wrote:
> > Showing who is the current master is useful for trying to decypher
> > errors when trying to acquire master (e.g. a race with X taking over
> > from plymouth). By including the process name as well as the pid
> > simplifies the task of grabbing enough information remotely at the point
> > of error.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/drm_info.c | 17 -
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
> > index 15ec9f4..d813430 100644
> > --- a/drivers/gpu/drm/drm_info.c
> > +++ b/drivers/gpu/drm/drm_info.c
> > @@ -184,14 +184,21 @@ int drm_clients_info(struct seq_file *m, void *data)
> > struct drm_file *priv;
> >
> > mutex_lock(&dev->struct_mutex);
> > - seq_printf(m, "a devpiduid magic\n\n");
> > - list_for_each_entry(priv, &dev->filelist, lhead) {
> > - seq_printf(m, "%c %3d %5d %5d %10u\n",
> > - priv->authenticated ? 'y' : 'n',
> > - priv->minor->index,
> > + seq_printf(m, " pid dev master a uid
> > magic\n");
>
> Maybe mention "task" here? Or is this supposed to be a logical part of "pid"?
Yeah, I was thinking that comm/pid were essentially the same column. Top
uses command which would be reasonable to reuse.
> > + list_for_each_entry_reverse(priv, &dev->filelist, lhead) {
>
> No idea why you do backwards traversal, but ok..
Clients are added youngest-first. So traversing backwards gives
kernel
X/display manager
clients
> > + struct task_struct *task;
> > +
> > + rcu_read_lock();
>
> What's that rcu-lock for? task->comm is pre-allocated, priv->pid is
> static, kuid... no idea?
Cargo-culting the locking from the discussion with Tetsuo:
commit 3ec2f427e6f82b9b8f9b18dd2c758b864385df39
Author: Tetsuo Handa
Date: Fri Jan 3 20:42:18 2014 +0900
drm/i915: Fix refcount leak and possible NULL pointerdereference.
Since get_pid_task() grabs a reference on the task_struct, we have to drop
the
refcount after reading that task's comm name. Use pid_task() with RCU
instead.
Also, avoid directly reading like pid_task()->comm because
pid_task() will return NULL if the task have already exit()ed.
This patch fixes both problems.
> Anyway, patch looks good otherwise. Especially task->comm sounds
> really handy in that list.
It was. Thanks for the feedback, will add the extra header and comment.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[pull] radeon drm-fixes-3.17
Hi On Mon, Sep 1, 2014 at 3:29 PM, sean darcy wrote: > On 08/22/2014 10:52 AM, Alex Deucher wrote: >> >> Hi Dave, >> >> This pull just contains some new pci ids. >> >> The following changes since commit >> 20a984c2a51d379bce08ee1031b32020f273e532: >> >>Merge tag 'drm-intel-fixes-2014-08-21' of >> git://anongit.freedesktop.org/drm-intel (2014-08-22 07:29:52 +1000) >> >> are available in the git repository at: >> >> >>git://people.freedesktop.org/~agd5f/linux drm-fixes-3.17 >> >> for you to fetch changes up to 37dbeab788a8f23fd946c0be083e5484d6f929a1: >> >>drm/radeon: add additional SI pci ids (2014-08-22 10:47:59 -0400) >> >> >> Alex Deucher (3): >>drm/radeon: add new KV pci id >>drm/radeon: add new bonaire pci ids >>drm/radeon: add additional SI pci ids >> >> drivers/gpu/drm/radeon/cik.c | 1 + >> include/drm/drm_pciids.h | 7 +++ >> 2 files changed, 8 insertions(+) >> > > Is there any reason this pull can't go into fixes-3.16? or even 3.15? 3.17 > is months away for me! Fedora 20 is on 3.15. This is not how kernel stable releases work. Fixes first go into the current development branch and then are picked for older stable kernels. This guarantees all fixes in older kernels are _always_ also available in the development branch. So you just need to be patient and it will be backported in a timely manner. (obviously only for commits that are marked for stable, which should be the case for new device IDs if they work fine on older kernels). Thanks David
[PATCH] drm: Include task->name and master status in debugfs clients info
Hi
On Mon, Sep 1, 2014 at 4:19 PM, Chris Wilson
wrote:
> On Mon, Sep 01, 2014 at 04:11:43PM +0200, David Herrmann wrote:
>> Hi
>>
>> On Sat, Aug 9, 2014 at 8:22 AM, Chris Wilson
>> wrote:
>> > Showing who is the current master is useful for trying to decypher
>> > errors when trying to acquire master (e.g. a race with X taking over
>> > from plymouth). By including the process name as well as the pid
>> > simplifies the task of grabbing enough information remotely at the point
>> > of error.
>> >
>> > Signed-off-by: Chris Wilson
>> > ---
>> > drivers/gpu/drm/drm_info.c | 17 -
>> > 1 file changed, 12 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
>> > index 15ec9f4..d813430 100644
>> > --- a/drivers/gpu/drm/drm_info.c
>> > +++ b/drivers/gpu/drm/drm_info.c
>> > @@ -184,14 +184,21 @@ int drm_clients_info(struct seq_file *m, void *data)
>> > struct drm_file *priv;
>> >
>> > mutex_lock(&dev->struct_mutex);
>> > - seq_printf(m, "a devpiduid magic\n\n");
>> > - list_for_each_entry(priv, &dev->filelist, lhead) {
>> > - seq_printf(m, "%c %3d %5d %5d %10u\n",
>> > - priv->authenticated ? 'y' : 'n',
>> > - priv->minor->index,
>> > + seq_printf(m, " pid dev master a uid
>> > magic\n");
>>
>> Maybe mention "task" here? Or is this supposed to be a logical part of "pid"?
>
> Yeah, I was thinking that comm/pid were essentially the same column. Top
> uses command which would be reasonable to reuse.
Sounds all fine. Just wanted to go sure it's not a typo.
>> > + list_for_each_entry_reverse(priv, &dev->filelist, lhead) {
>>
>> No idea why you do backwards traversal, but ok..
>
> Clients are added youngest-first. So traversing backwards gives
> kernel
> X/display manager
> clients
>
>> > + struct task_struct *task;
>> > +
>> > + rcu_read_lock();
>>
>> What's that rcu-lock for? task->comm is pre-allocated, priv->pid is
>> static, kuid... no idea?
>
> Cargo-culting the locking from the discussion with Tetsuo:
>
> commit 3ec2f427e6f82b9b8f9b18dd2c758b864385df39
> Author: Tetsuo Handa
> Date: Fri Jan 3 20:42:18 2014 +0900
>
> drm/i915: Fix refcount leak and possible NULL pointerdereference.
>
> Since get_pid_task() grabs a reference on the task_struct, we have to
> drop the
> refcount after reading that task's comm name. Use pid_task() with RCU
> instead.
>
> Also, avoid directly reading like pid_task()->comm because
> pid_task() will return NULL if the task have already exit()ed.
>
> This patch fixes both problems.
Ah, right, this is for pid lookup not task->comm. Should have seen that..
Feel free to add:
Reviewed-by: David Herrmann
Thanks
David
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #42 from Andy Furniss --- Playing more with hud I can see that there is a 1 to 1 correlation between the pauses and spikes in num-bytes-moved. The scale on the graphs did get squashed a bit by outliers, which seemed a bit random sometimes - I saw 330 MB on one run - but anyway here's a couple of screens - I got these using sleep 120 && xwd -root ... the first one landed on a scene change so is black. -- 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/20140901/9490bfc8/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #43 from Andy Furniss --- Created attachment 105563 --> https://bugs.freedesktop.org/attachment.cgi?id=105563&action=edit valley vanilla mesa bad num bytes moved -- 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/20140901/dfcb2ef0/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #44 from Andy Furniss --- Created attachment 105564 --> https://bugs.freedesktop.org/attachment.cgi?id=105564&action=edit valley better with revert num bytes moved -- 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/20140901/27bd27b7/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #45 from smoki --- (In reply to comment #41) > (In reply to comment #40) > > (In reply to comment #39) > > > If you let it run with Basic theme and few rounds you will spot i guess > > > that only first round there is unusual maybe 2-3 times 1-2 sec stutters, > > > then second time and later it is stutter free. > > > > Andy, you have behavior like that (more or less those seconds for stuter) > > if PIPE_USAGE_STREAM is reverted, right? > > The Bad was with vanilla mesa (couple of days old) > > The good was that + the patch in Comment 19 I asked is Valley play the same with your good case here and with using Basic theme in Windows :). That is the case for me, and average fps is around 80% in comparasion. > I looked again at Unreal Reflections - there is a difference but it's only > right at the start, both have a couple of stutters and they are longer with > vanilla then the rest is OK in both cases. Those Unreal 4 Engine linux demos are slide show fest on Kabini, so i can't recognize if there is stutter between two frames :D. Iguess those simply needs at least 10X+ more powerfull GPU then i have. -- 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/20140901/d72fa5a6/attachment.html>
[PULL REQUEST] ttm fence conversion
Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
> Hey,
>
> Op 01-09-14 om 14:31 schreef Christian K?nig:
>> Please wait a second with that.
>>
>> I didn't had a chance to test this yet and nobody has yet given it's rb on
>> at least the radeon changes in this branch.
> Ok, my fault. I thought it was implicitly acked. I haven't made any
> functional changes to these patches,
> just some small fixups and a fix to make it apply after the upstream removal
> of RADEON_FENCE_SIGNALED_SEQ.
Yeah, but the resulting patch looks to complex for my taste and should
be simplified a bit more. Here is a more detailed review:
> +wait_queue_t fence_wake;
Only a nitpick, but please fix the indention and maybe add a comment.
> +struct work_struct delayed_irq_work;
Just drop that, the new fall back work item should take care of this
when the unfortunate case happens that somebody tries to
enable_signaling in the middle of a GPU reset.
> /*
> - * Cast helper
> - */
> -#define to_radeon_fence(p) ((struct radeon_fence *)(p))
> -
> -/*
Please define the new cast helper in radeon.h as well.
> if (!rdev->needs_reset) {
> -up_write(&rdev->exclusive_lock);
> +downgrade_write(&rdev->exclusive_lock);
> +wake_up_all(&rdev->fence_queue);
> +up_read(&rdev->exclusive_lock);
> return 0;
> }
Just drop that as well, no need to wake up anybody here.
> downgrade_write(&rdev->exclusive_lock);
> +wake_up_all(&rdev->fence_queue);
Same here, the IB test will wake up all fences for recheck anyway.
> + * radeon_fence_read_seq - Returns the current fence value without
> updating
> + *
> + * @rdev: radeon_device pointer
> + * @ring: ring index to return the seqno of
> + */
> +static uint64_t radeon_fence_read_seq(struct radeon_device *rdev, int
> ring)
> +{
> +uint64_t last_seq = atomic64_read(&rdev->fence_drv[ring].last_seq);
> +uint64_t last_emitted = rdev->fence_drv[ring].sync_seq[ring];
> +uint64_t seq = radeon_fence_read(rdev, ring);
> +
> +seq = radeon_fence_read(rdev, ring);
> +seq |= last_seq & 0xLL;
> +if (seq < last_seq) {
> +seq &= 0x;
> +seq |= last_emitted & 0xLL;
> +}
> +return seq;
> +}
Completely drop that and just check the last_seq signaled as set by
radeon_fence_activity.
> +if (!ret)
> +FENCE_TRACE(&fence->base, "signaled from irq context\n");
> +else
> +FENCE_TRACE(&fence->base, "was already signaled\n");
Is all that text tracing necessary? Probably better define a trace point
here.
> +if (atomic64_read(&rdev->fence_drv[fence->ring].last_seq) >=
> fence->seq ||
> +!rdev->ddev->irq_enabled)
> +return false;
Checking irq_enabled here might not be such a good idea if the fence
code don't has a fall back on it's own. What exactly happens if
enable_signaling returns false?
> +static signed long radeon_fence_default_wait(struct fence *f, bool intr,
> + signed long timeout)
> +{
> +struct radeon_fence *fence = to_radeon_fence(f);
> +struct radeon_device *rdev = fence->rdev;
> +bool signaled;
> +
> +fence_enable_sw_signaling(&fence->base);
> +
> +/*
> + * This function has to return -EDEADLK, but cannot hold
> + * exclusive_lock during the wait because some callers
> + * may already hold it. This means checking needs_reset without
> + * lock, and not fiddling with any gpu internals.
> + *
> + * The callback installed with fence_enable_sw_signaling will
> + * run before our wait_event_*timeout call, so we will see
> + * both the signaled fence and the changes to needs_reset.
> + */
> +
> +if (intr)
> +timeout = wait_event_interruptible_timeout(rdev->fence_queue,
> + ((signaled =
> (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->base.flags))) ||
> rdev->needs_reset),
> + timeout);
> +else
> +timeout = wait_event_timeout(rdev->fence_queue,
> + ((signaled =
> (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->base.flags))) ||
> rdev->needs_reset),
> + timeout);
> +
> +if (timeout > 0 && !signaled)
> +return -EDEADLK;
> +return timeout;
> +}
This at least needs to be properly formated, but I think since we now
don't need extra handling any more we don't need an extra wait function
as well.
Regards,
Christian.
[PATCH 0/2] Two imx-drm oops fixes
Greg, Here's two oops fixes for imx-drm, which I've had queued up for a number of months now. Shawn posted different fixes for the same oops recently as well. drivers/staging/imx-drm/imx-ldb.c | 3 +++ drivers/staging/imx-drm/ipuv3-plane.c | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
[Bug 68799] [APITRACE] Hyper-Z lockup with Falcon BMS 4.32u6 on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=68799 --- Comment #4 from Marek Ol??k --- Setting DB_RENDER_OVERRIDE.FAST_STENCIL_DISABLE works as a workaround. -- 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/20140901/9e3a02c0/attachment-0001.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #65 from Aaron B --- I don't know what changed, if anything, but I did upgrade Chrome about 3 days ago, and now the past 2 days ever since I saw them mentioning more then 3-4 crashes a day, I'm running into 15-20 crashes a day. I can't do anything with Chrome. Next time I watch a video, we'll see if that went down in stability. LIke I said though, I did upgrade Chrome, but I don't remember any regressions in the first day of use. Maybe I didn't close it so I wasn't running on the new version, but still my crash numbers have gone through the roof now, I can't keep chrome open at all unless it's needed. -- 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/20140901/34c9ed87/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #66 from Christian K?nig --- (In reply to comment #65) > I don't know what changed, if anything, but I did upgrade Chrome about 3 > days ago, and now the past 2 days ever since I saw them mentioning more then > 3-4 crashes a day, I'm running into 15-20 crashes a day. I can't do anything > with Chrome. Next time I watch a video, we'll see if that went down in > stability. LIke I said though, I did upgrade Chrome, but I don't remember > any regressions in the first day of use. Maybe I didn't close it so I wasn't > running on the new version, but still my crash numbers have gone through the > roof now, I can't keep chrome open at all unless it's needed. Well that at least makes the issue more reproducible. Could you try grabbing an apitrace log what what's going wrong? That would really help. -- 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/20140901/1f921e58/attachment.html>
[Bug 68799] [APITRACE] Hyper-Z lockup with Falcon BMS 4.32u6 on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=68799 --- Comment #5 from smoki --- (In reply to comment #4) > Setting DB_RENDER_OVERRIDE.FAST_STENCIL_DISABLE works as a workaround. Yes it works. But it works also with your patch set from last week, did you abandon those? I have these 7 applied and this apitrace does not lockup :) http://lists.freedesktop.org/archives/mesa-dev/2014-August/066388.html http://lists.freedesktop.org/archives/mesa-dev/2014-August/066519.html -- 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/20140901/01f516a6/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #67 from Aaron B --- Created attachment 105569 --> https://bugs.freedesktop.org/attachment.cgi?id=105569&action=edit API trace of a crash. > (In reply to comment #65) > > I don't know what changed, if anything, but I did upgrade Chrome about 3 > > days ago, and now the past 2 days ever since I saw them mentioning more then > > 3-4 crashes a day, I'm running into 15-20 crashes a day. I can't do anything > > with Chrome. Next time I watch a video, we'll see if that went down in > > stability. LIke I said though, I did upgrade Chrome, but I don't remember > > any regressions in the first day of use. Maybe I didn't close it so I wasn't > > running on the new version, but still my crash numbers have gone through the > > roof now, I can't keep chrome open at all unless it's needed. > > Well that at least makes the issue more reproducible. Could you try grabbing > an apitrace log what what's going wrong? > > That would really help. This what you're looking for? -- 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/20140901/4c35e6d5/attachment.html>
[PULL REQUEST] ttm fence conversion
Hey,
On 01-09-14 18:21, Christian K?nig wrote:
> Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
>> Hey,
>>
>> Op 01-09-14 om 14:31 schreef Christian K?nig:
>>> Please wait a second with that.
>>>
>>> I didn't had a chance to test this yet and nobody has yet given it's rb on
>>> at least the radeon changes in this branch.
>> Ok, my fault. I thought it was implicitly acked. I haven't made any
>> functional changes to these patches,
>> just some small fixups and a fix to make it apply after the upstream removal
>> of RADEON_FENCE_SIGNALED_SEQ.
>
> Yeah, but the resulting patch looks to complex for my taste and should be
> simplified a bit more. Here is a more detailed review:
>
>> +wait_queue_t fence_wake;
> Only a nitpick, but please fix the indention and maybe add a comment.
>
>> +struct work_struct delayed_irq_work;
> Just drop that, the new fall back work item should take care of this when the
> unfortunate case happens that somebody tries to enable_signaling in the
> middle of a GPU reset.
I can only drop it if radeon_gpu_reset will always call radeon_irq_set after
downgrading to read mode, even if no work needs to be done. :-)
Then again, should be possible.
>> /*
>> - * Cast helper
>> - */
>> -#define to_radeon_fence(p) ((struct radeon_fence *)(p))
>> -
>> -/*
> Please define the new cast helper in radeon.h as well.
The ops are only defined in radeon_fence.c, and nothing outside of
radeon_fence.c should care about the internals.
>> if (!rdev->needs_reset) {
>> -up_write(&rdev->exclusive_lock);
>> +downgrade_write(&rdev->exclusive_lock);
>> +wake_up_all(&rdev->fence_queue);
>> +up_read(&rdev->exclusive_lock);
>> return 0;
>> }
> Just drop that as well, no need to wake up anybody here.
Maybe not, but if I have to remove delayed_irq_work I do need to add a
radeon_irq_set here.
>> downgrade_write(&rdev->exclusive_lock);
>> +wake_up_all(&rdev->fence_queue);
> Same here, the IB test will wake up all fences for recheck anyway.
Same as previous comment. :-)
>> + * radeon_fence_read_seq - Returns the current fence value without updating
>> + *
>> + * @rdev: radeon_device pointer
>> + * @ring: ring index to return the seqno of
>> + */
>> +static uint64_t radeon_fence_read_seq(struct radeon_device *rdev, int ring)
>> +{
>> +uint64_t last_seq = atomic64_read(&rdev->fence_drv[ring].last_seq);
>> +uint64_t last_emitted = rdev->fence_drv[ring].sync_seq[ring];
>> +uint64_t seq = radeon_fence_read(rdev, ring);
>> +
>> +seq = radeon_fence_read(rdev, ring);
>> +seq |= last_seq & 0xLL;
>> +if (seq < last_seq) {
>> +seq &= 0x;
>> +seq |= last_emitted & 0xLL;
>> +}
>> +return seq;
>> +}
> Completely drop that and just check the last_seq signaled as set by
> radeon_fence_activity.
Do you mean call radeon_fence_activity in radeon_fence_signaled? Or should I
just use the cached value in radeon_fence_check_signaled.
I can't call fence_activity in check_signaled, because it would cause
re-entrancy in fence_queue.
>> +if (!ret)
>> +FENCE_TRACE(&fence->base, "signaled from irq context\n");
>> +else
>> +FENCE_TRACE(&fence->base, "was already signaled\n");
> Is all that text tracing necessary? Probably better define a trace point here.
It gets optimized out normally. There's already a tracepoint called in
fence_signal.
>> +if (atomic64_read(&rdev->fence_drv[fence->ring].last_seq) >= fence->seq
>> ||
>> +!rdev->ddev->irq_enabled)
>> +return false;
> Checking irq_enabled here might not be such a good idea if the fence code
> don't has a fall back on it's own. What exactly happens if enable_signaling
> returns false?
I thought irq_enabled couldn't happen under normal circumstances?
Anyway the fence gets treated as signaled if it returns false, and fence_signal
will get called.
>> +static signed long radeon_fence_default_wait(struct fence *f, bool intr,
>> + signed long timeout)
>> +{
>> +struct radeon_fence *fence = to_radeon_fence(f);
>> +struct radeon_device *rdev = fence->rdev;
>> +bool signaled;
>> +
>> +fence_enable_sw_signaling(&fence->base);
>> +
>> +/*
>> + * This function has to return -EDEADLK, but cannot hold
>> + * exclusive_lock during the wait because some callers
>> + * may already hold it. This means checking needs_reset without
>> + * lock, and not fiddling with any gpu internals.
>> + *
>> + * The callback installed with fence_enable_sw_signaling will
>> + * run before our wait_event_*timeout call, so we will see
>> + * both the signaled fence and the changes to needs_reset.
>> + */
>> +
>> +if (intr)
>> +timeout = wait_event_interruptible_timeout(rdev->fence_queue,
>> + ((signaled =
>> (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->base.flags))) ||
>> rd
[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary
https://bugs.freedesktop.org/show_bug.cgi?id=72685 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #32 from Marek Ol??k --- Fixed by 91050ff2154417d7f3a16b582f28c8bbdcea6cfb. Closing. -- 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/20140901/2a181372/attachment.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Bug 75112 depends on bug 72685, which changed state. Bug 72685 Summary: [radeonsi hyperz] Artifacts in Unigine Sanctuary https://bugs.freedesktop.org/show_bug.cgi?id=72685 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/20140901/fd0f711f/attachment.html>
[Bug 64471] Radeon HD6570 lockup in Brütal Legend with HyperZ
https://bugs.freedesktop.org/show_bug.cgi?id=64471 --- Comment #26 from Marek Ol??k --- The patch has been committed, but it's a workaround, not a fix. I think this bug should remain open until a proper fix has been found. -- 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/20140901/17bd4c66/attachment.html>
[Bug 68799] [APITRACE] Hyper-Z lockup with Falcon BMS 4.32u6 on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=68799 --- Comment #6 from Marek Ol??k --- The patch has been committed, but it's a workaround, not a fix. I think this bug should remain open until a proper fix has been found. -- 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/20140901/cdb5ea34/attachment.html>
[Bug 83205] GPU lockup when entering settings in Verdun game with HyperZ enabled
https://bugs.freedesktop.org/show_bug.cgi?id=83205 Cl?ment Gu?rin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Cl?ment Gu?rin --- Marking as RESOLVED FIXED since the fix has just been merged. Keep up the good work! -- 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/20140901/8f51fdb9/attachment.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Bug 75112 depends on bug 83205, which changed state. Bug 83205 Summary: GPU lockup when entering settings in Verdun game with HyperZ enabled https://bugs.freedesktop.org/show_bug.cgi?id=83205 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/20140901/af77ae02/attachment.html>
[Bug 74892] HyperZ GPU lockup with radeonsi 7970M PITCAIRN and Distance Alpha game
https://bugs.freedesktop.org/show_bug.cgi?id=74892 --- Comment #3 from Marek Ol??k --- Is this fixed with current Mesa git? If not, could you please make and upload a trace file using apitrace: https://github.com/apitrace/apitrace Thanks. -- 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/20140901/0fdb8942/attachment-0001.html>
[Bug 74863] [r600g] HyperZ broken on RV770 and CYPRESS (Left 4 Dead 2 trees corruption) bisected!
https://bugs.freedesktop.org/show_bug.cgi?id=74863 --- Comment #3 from Marek Ol??k --- Is this fixed with current Mesa git? If not, could you please make and upload a trace file using apitrace: https://github.com/apitrace/apitrace Thanks. -- 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/20140901/e410b5e0/attachment.html>
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 --- Comment #18 from Marek Ol??k --- Is this fixed with current Mesa git? -- 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/20140901/2d5e2a4f/attachment.html>
[Bug 74784] [hyperz] Strange artifacts when rendering trees in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=74784 --- Comment #11 from Marek Ol??k --- Could you please test if this is fixed with current Mesa git? -- 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/20140901/1707caa6/attachment.html>
[Bug 74428] hyperz causes gpu hang in Counter-strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=74428 --- Comment #5 from Marek Ol??k --- Is this fixed with current Mesa git? If not, could you please make and upload a trace file using apitrace: https://github.com/apitrace/apitrace Thanks. -- 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/20140901/85ec3731/attachment.html>
[Bug 74892] HyperZ GPU lockup with radeonsi 7970M PITCAIRN and Distance Alpha game
https://bugs.freedesktop.org/show_bug.cgi?id=74892 Christoph Haag changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Christoph Haag --- Yes, seems to work now after a few short tests. No hangs. Thanks! -- 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/20140901/80d527ea/attachment.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Bug 75112 depends on bug 74892, which changed state. Bug 74892 Summary: HyperZ GPU lockup with radeonsi 7970M PITCAIRN and Distance Alpha game https://bugs.freedesktop.org/show_bug.cgi?id=74892 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/20140901/d67613b2/attachment.html>
[Bug 58660] CAYMAN broken with HyperZ on
https://bugs.freedesktop.org/show_bug.cgi?id=58660 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Marek Ol??k --- I'm closing this 2-years-old bug. The report says that a patch which adds HTILE support causes a crash when compiz starts, but compiz doesn't even use a zbuffer, so we are not really using Hyper-Z here. I believe this is just a bug caused by incorrect register programming in the initial HTILE patch and must have been fixed since then. Feel free to reopen if you see this crash with current Mesa git. -- 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/20140901/a3266c06/attachment-0001.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Bug 75112 depends on bug 58660, which changed state. Bug 58660 Summary: CAYMAN broken with HyperZ on https://bugs.freedesktop.org/show_bug.cgi?id=58660 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- 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/20140901/a9469ea9/attachment-0001.html>
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 --- Comment #19 from funkydude --- I'll update my oibaf laptop and try get back to you as soon as possible. -- 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/20140901/639c085f/attachment.html>
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 --- Comment #20 from funkydude --- Oh I should ask this now. Is HyperZ enable now or do I need to change the Steam launch options? -- 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/20140901/afe13010/attachment.html>
[Bug 73088] [HyperZ] Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use
https://bugs.freedesktop.org/show_bug.cgi?id=73088 --- Comment #7 from Marek Ol??k --- appletorch, could you please test current Mesa git and see if it's 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/20140901/2fa7fb45/attachment.html>
[Bug 73785] [HyperZ] Team Fortress 2 causes random GPU stalls on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=73785 --- Comment #7 from Marek Ol??k --- Is this fixed with current Mesa git? -- 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/20140901/215fbf6a/attachment.html>
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 --- Comment #21 from Marek Ol??k --- You need to set the environment variable: R600_DEBUG=hyperz -- 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/20140901/7771c6fa/attachment.html>
[Bug 73088] [HyperZ] Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use
https://bugs.freedesktop.org/show_bug.cgi?id=73088 --- Comment #8 from Marek Ol??k --- Please don't forget to set this environment variable: R600_DEBUG=hyperz -- 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/20140901/dbfe9e57/attachment.html>
[Bug 74892] HyperZ GPU lockup with radeonsi 7970M PITCAIRN and Distance Alpha game
https://bugs.freedesktop.org/show_bug.cgi?id=74892 --- Comment #5 from Marek Ol??k --- Did you set this environment variable before testing? R600_DEBUG=hyperz -- 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/20140901/dc69bdcd/attachment.html>
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #9 from Connor Abbott --- Created attachment 105572 --> https://bugs.freedesktop.org/attachment.cgi?id=105572&action=edit debugging patch -- 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/20140901/e0589579/attachment-0001.html>
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #10 from Connor Abbott --- Can you try the patch I attached and tell me what output you get between the last "--- begin simplify ---" and "--- end simplify ---" pair? -- 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/20140901/c0140028/attachment.html>
[Bug 74892] HyperZ GPU lockup with radeonsi 7970M PITCAIRN and Distance Alpha game
https://bugs.freedesktop.org/show_bug.cgi?id=74892 --- Comment #6 from Christoph Haag --- (In reply to comment #5) > Did you set this environment variable before testing? > > R600_DEBUG=hyperz There are times when I don't know what I'm doing but this time I used this in steam: DRI_PRIME=1 GALLIUM_HUD="fps,VRAM-usage+GTT-usage" R600_DEBUG=hyperz %command% -- 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/20140901/1417c118/attachment.html>
[Bug 74892] HyperZ GPU lockup with radeonsi 7970M PITCAIRN and Distance Alpha game
https://bugs.freedesktop.org/show_bug.cgi?id=74892 --- Comment #7 from Marek Ol??k --- Ok, that looks good. Thanks. -- 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/20140901/e5a4ebc8/attachment.html>
[Bug 82918] [tahiti xt] dota2 crashes
https://bugs.freedesktop.org/show_bug.cgi?id=82918 --- Comment #14 from Sylvain BERTRAND --- Created attachment 105573 --> https://bugs.freedesktop.org/attachment.cgi?id=105573&action=edit steam output with R600_DEBUG -- 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/20140901/f28bbbe1/attachment.html>
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 --- Comment #22 from funkydude --- No. Still broken using latest Oibaf. -- 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/20140901/9196f52d/attachment.html>
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 --- Comment #23 from smoki --- (In reply to comment #22) > No. Still broken using latest Oibaf. Latest oibaf ppa packages still does not contain these fixes :) You need to wait for newer packages, one more update :) -- 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/20140901/a51c1f77/attachment.html>
[Bug 74863] [r600g] HyperZ broken on RV770 and CYPRESS (Left 4 Dead 2 trees corruption) bisected!
https://bugs.freedesktop.org/show_bug.cgi?id=74863 --- Comment #4 from Benjamin Bellec --- Problem still persists with current master (git-e8f8353). Tested on Evergreen. The apitrace can be downloaded here : https://drive.google.com/file/d/0B7D2Y0QXFND2bUlVc1JyMHZKVWc (364 MB, md5sum 3e80394465612a7f29aced09ea02bd78) -- 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/20140901/4f11343d/attachment.html>
drivers/video/hdmi.c: Source Product Description (SPD) Information frame logging
On Tue, Aug 26, 2014 at 03:31:02PM +0200, Damien Lespiau wrote: > On Tue, Aug 26, 2014 at 12:46:32PM +0200, Martin Bugge (marbugge) wrote: > > Hello Damien > > > > I'm writing to you as you seems to be one of latest maintainers of: > > > > include/linux/hdmi.h > > drivers/video/hdmi.c > > > > I wanted to add "Source Product Description information frame" > > logging for the drivers in > > > > ./drivers/media/i2c/adv7604.c > > ./drivers/media/i2c/adv7842.c > > > > But was advised to contact you and use some of the defines in > > include/linux/hdmi.h > > > > As you can see in: > > > > http://www.spinics.net/lists/linux-media/msg74727.html > > > > Would you consider the addition of a hdmi_spd_infoframe_log function > > in hdmi.c a good idea ? > > > > And the same goes for other HDMI Information frames. > > I don't see why not. Currently the code there is somewhat geared for > writing HDMI info frames, not really reading back/debug. > > The various structures are not a 1:1 mapping with how the fields are > actually represented in an info frame packet, so you get a _pack() > function to serialize the info frame structures. Something to > consider, then, for your logging API would be to either: > > - Give a buffer/size to your log() function and decode a raw buffer > - make an _unpack() function that takes a raw buffer and translate it > into one of the various infoframe structure and then have a _log > function that operates on the "unpacked" structure. > > Another thing to keep in mind is that those "unpacked" versions of the > infoframes don't actually have all the fields. eg. > >/* > * Data byte 1, bit 4 has to be set if we provide the active format > * aspect ratio > */ > if (frame->active_aspect & 0xf) > ptr[0] |= BIT(4); > > [...] > > ptr[1] = ((frame->colorimetry & 0x3) << 6) | > ((frame->picture_aspect & 0x3) << 4) | > (frame->active_aspect & 0xf); > > You can see that active_aspect needs two fields set, a "active aspect valid" > bit (data byte 1, bit 4) and the actual active_aspect value. To prevent the > user of the API to generate invalid infoframes (ie have a active_aspect value > but forgetting to set the valid bit), I decided to "hide" the valid bit and > set > it automatically if active_aspect is set. This isn't just theoritical, we've > had the bug that forgot the valid bit before. > > That's the details I can think about atm, I don't seen any reason to not > improve that code to be able to dump info frames. I have a slight preference > to > have an _unpack() version and have the _log() functions operate on the > "expoded" structures, maybe Thierry/Paulo (in Cc.) have some input as well. I do have a preference for adding an _unpack() variant, too. Although as you pointed out there could be difficulties in reconstructing that from the raw data given that we don't have a 1:1 encoding. For example, what does the _unpack() do if the active aspect is set but not the valid bit? One advantage perhaps would be that _unpack()/_pack() could act as a sanitizer. Thierry --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140901/92bfcec7/attachment.sig>
[PATCH] drm/panel: simple: Add AUO B116XW03 panel support
The AUO B116XW03 is a 11.6" HD TFT LCD panel connecting to a LVDS
interface and with an integrated LED backlight unit.
This panel is used on the Samsung Chromebook(XE303C12).
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/panel/auo,b116xw03.txt |7 ++
drivers/gpu/drm/panel/panel-simple.c | 25
2 files changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b116xw03.txt
diff --git a/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
new file mode 100644
index 000..690d0a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel
+
+Required properties:
+- compatible: should be "auo,b116xw03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4ce1db0..51566e0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -352,6 +352,28 @@ static const struct panel_desc auo_b101aw03 = {
},
};
+static const struct drm_display_mode auo_b116xw03_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b116xw03 = {
+ .modes = &auo_b116xw03_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 256,
+ .height = 144,
+ },
+};
+
static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -616,6 +638,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = &auo_b101aw03,
}, {
+ .compatible = "auo,b116xw03",
+ .data = &auo_b116xw03,
+ }, {
.compatible = "auo,b133htn01",
.data = &auo_b133htn01,
}, {
--
1.7.9.5
[PATCH 1/2] imx-drm: ipuv3-plane: fix ipu_plane_dpms()
When unbinding imx-drm, the following oops was observed:
Unable to handle kernel NULL pointer dereference at virtual address 0004
pgd = e995c000
[0004] *pgd=4fea5831
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac
brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma
snd_soc_sgtl5000 imx_sdma imx2_wdt imx_ldb(C) imx_thermal snd_soc_imx_sgtl5000
snd_soc_imx_spdif snd_soc_imx_audmux
CPU: 1 PID: 779 Comm: bash Tainted: G C3.16.0-rc2+ #1230
task: ea9eb180 ti: ea378000 task.ti: ea378000
PC is at ipu_dp_put+0x10/0x18
LR is at ipu_plane_dpms+0x60/0x8c
pc : []lr : []psr: 200f0013
sp : ea379d80 ip : ea379d90 fp : ea379d8c
r10: 00100100 r9 : r8 : 00200200
r7 : e9ba0264 r6 : e9ba01f8 r5 : r4 : ea34b800
r3 : r2 : r1 : 009b r0 :
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c53c7d Table: 3995c04a DAC: 0015
Process bash (pid: 779, stack limit = 0xea378240)
Stack: (0xea379d80 to 0xea37a000)
...
Backtrace:
[] (ipu_dp_put) from [] (ipu_plane_dpms+0x60/0x8c)
[] (ipu_plane_dpms) from [] (ipu_disable_plane+0x2c/0x60)
[] (ipu_disable_plane) from [] (ipu_plane_destroy+0x28/0x60)
[] (ipu_plane_destroy) from []
(drm_mode_config_cleanup+0x1b8/0x250)
[] (drm_mode_config_cleanup) from []
(imx_drm_driver_unload+0x44/0x4c)
[] (imx_drm_driver_unload) from []
(drm_dev_unregister+0x2c/0xa0)
[] (drm_dev_unregister) from [] (drm_put_dev+0x30/0x6c)
[] (drm_put_dev) from [] (imx_drm_unbind+0x14/0x18)
[] (imx_drm_unbind) from [] (component_master_del+0xbc/0xd8)
...
Code: e1a0c00d e92dd800 e24cb004 e3a03000 (e5c03004)
This is caused by a missing check in ipu_plane_dpms for a NULL pointer.
Fixes: b8d181e408af ("staging: drm/imx: add drm plane support")
Cc:
Signed-off-by: Russell King
---
drivers/staging/imx-drm/ipuv3-plane.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/ipuv3-plane.c
b/drivers/staging/imx-drm/ipuv3-plane.c
index 6f393a11f44d..50de10a550e9 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -281,7 +281,8 @@ static void ipu_plane_dpms(struct ipu_plane *ipu_plane, int
mode)
ipu_idmac_put(ipu_plane->ipu_ch);
ipu_dmfc_put(ipu_plane->dmfc);
- ipu_dp_put(ipu_plane->dp);
+ if (ipu_plane->dp)
+ ipu_dp_put(ipu_plane->dp);
}
}
--
1.8.3.1
[PATCH 2/2] imx-drm: imx-ldb: fix NULL pointer in imx_ldb_unbind()
When trying to unbind imx-drm, the following oops was observed from
the imx-ldb driver:
Unable to handle kernel NULL pointer dereference at virtual address 001c
pgd = de954000
[001c] *pgd=2e92c831, *pte=, *ppte=
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac
brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma imx_ldb(C)
imx_thermal imx_sdma imx2_wdt snd_soc_sgtl5000 snd_soc_imx_sgtl5000
snd_soc_imx_spdif snd_soc_imx_audmux
CPU: 1 PID: 1228 Comm: bash Tainted: G C3.16.0-rc2+ #1229
task: ea378d80 ti: de948000 task.ti: de948000
PC is at imx_ldb_unbind+0x1c/0x58 [imx_ldb]
LR is at component_unbind+0x38/0x70
pc : []lr : []psr: 200f0013
sp : de949da8 ip : de949dc0 fp : de949dbc
r10: e9a44b0c r9 : r8 : de949f78
r7 : 0012 r6 : e9b3f400 r5 : e9b133b8 r4 : e9b13010
r3 : r2 : e9b3f400 r1 : ea9a0210 r0 : e9b13020
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c53c7d Table: 2e95404a DAC: 0015
Process bash (pid: 1228, stack limit = 0xde948240)
Stack: (0xde949da8 to 0xde94a000)
...
Backtrace:
[] (imx_ldb_unbind [imx_ldb]) from []
(component_unbind+0x38/0x70)
[] (component_unbind) from []
(component_unbind_all+0x94/0xc8)
[] (component_unbind_all) from []
(imx_drm_driver_unload+0x34/0x4c)
[] (imx_drm_driver_unload) from []
(drm_dev_unregister+0x2c/0xa0)
[] (drm_dev_unregister) from [] (drm_put_dev+0x30/0x6c)
[] (drm_put_dev) from [] (imx_drm_unbind+0x14/0x18)
[] (imx_drm_unbind) from [] (component_master_del+0xbc/0xd8)
...
Code: e5904058 e2840010 e2845fea e59430a0 (e593301c)
---[ end trace 4f211c6dbbcd4963 ]---
This is caused by only having one channel out of the pair configured in
DT; the second channel remains uninitialised, but upon unbind, the
driver attempts to clean up both, thereby dereferencing a NULL pointer.
Avoid this by checking that the second channel is initialised.
Fixes: 1b3f76756633 ("imx-drm: initialise drm components directly")
Cc:
Signed-off-by: Russell King
---
drivers/staging/imx-drm/imx-ldb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index 7e3f019d7e72..4662e00b456a 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -574,6 +574,9 @@ static void imx_ldb_unbind(struct device *dev, struct
device *master,
for (i = 0; i < 2; i++) {
struct imx_ldb_channel *channel = &imx_ldb->channel[i];
+ if (!channel->connector.funcs)
+ continue;
+
channel->connector.funcs->destroy(&channel->connector);
channel->encoder.funcs->destroy(&channel->encoder);
}
--
1.8.3.1
[PATCH v4 1/2] ASoC:codecs: Add a generic HDMI audio CODEC
On Sun, Aug 31, 2014 at 12:45:39PM +0200, Jean-Francois Moine wrote:
> Documentation/devicetree/bindings/sound/hdmi2.txt | 32
> include/sound/hdmi2.h | 24 +++
> sound/soc/codecs/Kconfig | 3 +
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/hdmi2.c | 204
> ++
> 5 files changed, 265 insertions(+)
This is clearly not a good name and it's not clear what the difference
between this and the existing HDMI stub CODEC is intended to be.
> +Required properties:
> +
> + - audio-ports: must contain one or two HDMI transmitter dependant
> + values identifying the audio sources.
> + The source type is given by the corresponding entry in
> + the audio-port-names property.
> +
> + - audio-port-names: must contain entries matching the entries in
> + the audio-ports property.
> + Each value may be "i2s" or "spdif", giving the type of
> + the associated audio port.
It seems hard to see this binding as really generic - I'd expect to see
other devices which are just able to have fixed audio ports for example.
> +static int hdmi2_probe(struct snd_soc_codec *codec)
> +{
> + struct i2c_client *i2c_client = to_i2c_client(codec->dev);
> + struct hdmi2_codec *audio = i2c_get_clientdata(i2c_client);
> + struct device_node *np = codec->dev->of_node;
> + int i, j, ret;
> + const char *p;
> +
> + if (!audio)
> + return -ENODEV;
> + snd_soc_codec_set_drvdata(codec, audio);
The code also seems pretty device specific. I think it's probably
better to leave the binding device specific for now and concentrate on
sharing inside the kernel, making any generic binding additions be about
how the devices interface rather than what's going on inside a specific
device.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140901/d1cc1f1b/attachment-0001.sig>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #33 from Michel D?nzer --- (In reply to comment #28) > > I submitted the change reverting the behaviour of PIPE_USAGE_STREAM for > > review, but it's strange: I couldn't notice any significant difference in > > stutter in Valley regardless of any of these changes. Also, according to GALLIUM_HUD=requested-VRAM+VRAM-usage,requested-GTT+GTT-usage, Valley only seems to allocate about 10-20 MB for streaming BOs, so I'm not sure why putting them in VRAM or not makes such a big difference for you. > > BTW, what CPU are you using? > > It's an AMD Phenom II x4 965be. I assume the chipset for that doesn't support PCIe 3.0, does it? I wonder if maybe streaming BOs should be in VRAM with PCIe 3.0 but not with PCIe 2.0. -- 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/20140901/1370b911/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #59 from Aaron B --- *Still active OB in VM"* Just had about 3 crashes in 2 hours. This is a joke of a bug that it seems nobody cares, and probably affects all SI, and probably R600 users. -- 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/20140901/47f16737/attachment.html>
[PATCH] drm/vmwgfx: select FB when DRM_VMWGFX is selected
Otherwise, if FB is not selected build fails at linking step: vmwgfx_fb.c:(.text+0x4098b): undefined reference to `register_framebuffer' vmwgfx_fb.c:(.text+0x409c0): undefined reference to `framebuffer_release' vmwgfx_fb.c:(.text+0x409f4): undefined reference to `unregister_framebuffer' vmwgfx_fb.c:(.text+0x40a0e): undefined reference to `framebuffer_release' Patch ae6445ac7475ff05 drm/vmwgfx: depends on FB added dependency on FB that was subsequently removed in patch 04381b987292256d drm: Move plane helpers into drm_kms_helper.ko Signed-off-by: Max Filippov --- drivers/gpu/drm/vmwgfx/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig index 67720f7..4fba548 100644 --- a/drivers/gpu/drm/vmwgfx/Kconfig +++ b/drivers/gpu/drm/vmwgfx/Kconfig @@ -1,6 +1,7 @@ config DRM_VMWGFX tristate "DRM driver for VMware Virtual GPU" depends on DRM && PCI + select FB select FB_DEFERRED_IO select FB_CFB_FILLRECT select FB_CFB_COPYAREA -- 1.7.7.6
[PATCH] drm/vmwgfx: select FB when DRM_VMWGFX is selected
On Mon, Sep 1, 2014 at 3:20 AM, Randy Dunlap wrote: > On 08/31/14 16:07, Max Filippov wrote: >> Otherwise, if FB is not selected build fails at linking step: >> vmwgfx_fb.c:(.text+0x4098b): undefined reference to `register_framebuffer' >> vmwgfx_fb.c:(.text+0x409c0): undefined reference to `framebuffer_release' >> vmwgfx_fb.c:(.text+0x409f4): undefined reference to >> `unregister_framebuffer' >> vmwgfx_fb.c:(.text+0x40a0e): undefined reference to `framebuffer_release' >> >> Patch ae6445ac7475ff05 drm/vmwgfx: depends on FB >> added dependency on FB that was subsequently removed in patch >> 04381b987292256d drm: Move plane helpers into drm_kms_helper.ko >> >> Signed-off-by: Max Filippov >> --- >> drivers/gpu/drm/vmwgfx/Kconfig |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig >> index 67720f7..4fba548 100644 >> --- a/drivers/gpu/drm/vmwgfx/Kconfig >> +++ b/drivers/gpu/drm/vmwgfx/Kconfig >> @@ -1,6 +1,7 @@ >> config DRM_VMWGFX >> tristate "DRM driver for VMware Virtual GPU" >> depends on DRM && PCI >> + select FB >> select FB_DEFERRED_IO >> select FB_CFB_FILLRECT >> select FB_CFB_COPYAREA >> > > My experience with these "select FB_*" things is that this symbol (DRM_VMWGFX) > should still depend on FB. Has something changed recently to negate that? I see the following if I replace 'select FB' with 'depends on FB': drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:39: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:33: symbol DRM_KMS_HELPER is selected by DRM_VMWGFX drivers/gpu/drm/vmwgfx/Kconfig:1: symbol DRM_VMWGFX depends on FB -- Thanks. -- Max
[Bug 83234] Opening Steam crashes X session
https://bugs.freedesktop.org/show_bug.cgi?id=83234 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|dri-devel at lists.freedesktop |xorg-team at lists.x.org |.org| QA Contact||xorg-team at lists.x.org Product|Mesa|xorg Component|Drivers/Gallium/radeonsi|Server/Ext/GLX -- 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/20140901/0845802b/attachment.html>
[Bug 83274] XCom Enemy Unknown segfault at src/gallium/drivers/radeon/r600_texture.c:602
https://bugs.freedesktop.org/show_bug.cgi?id=83274 --- Comment #1 from Michel D?nzer --- Looks like memory corruption. If it's not bug 80673 (which is supposed to be fixed in the latest game update), can you attach the output from running the game in valgrind? -- 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/20140901/93921a4b/attachment-0001.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #60 from Aaron B --- I mean, if it helps, every crash is always during a situation where new graphics information would be loaded up to the card, that can't me that much of the Mesa code since I'd imagine the most complex part is all the OpenGL standards compliance. I run my R9 270X on a PCIe 3.0 port on a M5A99FX Pro 2.0 Evo motherboard. Anyone else on majorly different hardware and have this problem? (Fun fact, it had an uncovered crashed while I was typing this in, no other screen updates at all.) -- 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/20140901/92defe0e/attachment.html>
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 --- Comment #26 from Aaron B --- This should be a duplicate of my bug here: https://bugs.freedesktop.org/show_bug.cgi?id=81644 SHort story: THe blank screen crash (and rare recover) usually happens for me is triggered by Chromium, VLC, and OpenGL games opened when Chromium or VLC are opened. Also rarely on game start ups in general it seems. I believe it's a bug in Mesa, no clue where, but the apps that trigger it all should be pushing data to the GPU, so I'd imagine it's a fault in that pipe/allocation. -- 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/20140901/49e9ba60/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #61 from Damian Nowak --- My story: https://bugs.freedesktop.org/show_bug.cgi?id=65963#c4 tl;dr Mesa 10.1.4 is the last version that doesn't cause the problem. -- 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/20140901/96e6164e/attachment.html>
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 Damian Nowak changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #27 from Damian Nowak --- Although this issue is older than #81644, the latter contains way more information. Closing this one. *** This bug has been marked as a duplicate of bug 81644 *** -- 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/20140901/36240503/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 Damian Nowak changed: What|Removed |Added CC||nowaker at geozone.pl --- Comment #62 from Damian Nowak --- *** Bug 65963 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/20140901/f8c0edb2/attachment.html>
[PATCH RFC v2 3/8] component: add support for component match array
On 2014? 08? 31? 06:33, Russell King - ARM Linux wrote:
> On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote:
>> 2014-07-01 23:22 GMT+09:00 Russell King - ARM Linux > arm.linux.org.uk>:
>>> On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote:
On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
> Hi Russell,
>
> On Tue, Jun 24, 2014 at 9:29 PM, Russell King
> wrote:
> [...]
>> +/*
>> + * Add a component to be matched.
>> + *
>> + * The match array is first created or extended if necessary.
>> + */
>> +void component_match_add(struct device *dev, struct component_match
>> **matchptr,
>> + int (*compare)(struct device *, void *), void *compare_data)
>> +{
>> + struct component_match *match = *matchptr;
>> +
>> + if (IS_ERR(match))
>> + return;
>> +
>> + if (!match || match->num == match->alloc) {
>> + size_t new_size = match ? match->alloc + 16 : 15;
>> +
>> + match = component_match_realloc(dev, match, new_size);
>> +
>> + *matchptr = match;
>> +
>> + if (IS_ERR(match))
>> + return;
>> + }
>> +
>> + match->compare[match->num].fn = compare;
>> + match->compare[match->num].data = compare_data;
>> + match->num++;
>> +}
>
> component_match_add should be exported.
Fixed, thanks.
>>>
>>> As there's no further comments, and Inki Dae has not responded, I'm
>>
>> It's has been just a week. I will check and look into your patch
>> series. I think Exynos drm should also be considered for the use of
>> component match array.
>
> It has now been almost two months. What's happening on this?
>
> Please note that I'm planning to push the rest of the component updates
> during the next merge window, which will result in unconverted drivers
> breaking.
>
Sorry for this. I was busy with other works. I will update and post it
until this week.
Thanks,
Inki Dae
> Thanks.
>
[Bug 79696] 10.2.x GPU stall & Xorg crash while using Geeqie
https://bugs.freedesktop.org/show_bug.cgi?id=79696 --- Comment #21 from Michel D?nzer --- (In reply to comment #20) > I would appreciate an update to this bug as I am stuck on 10.1.4. I'm afraid bisecting is still the best bet. To avoid bisecting to a wrong commit, make sure to wait long enough before declaring any commit good. Also, if you can't test some commits because of the segfault fixed by http://cgit.freedesktop.org/mesa/mesa/commit/?id=cb4ad1368551b64756c7b6e2007588e34739b188 , you can apply that manually for testing those commits. -- 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/20140901/b817a073/attachment-0001.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #63 from Michel D?nzer --- (In reply to comment #61) > tl;dr Mesa 10.1.4 is the last version that doesn't cause the problem. If somebody could bisect that regression between Mesa 10.1 and 10.2, that would be very helpful. See https://bugs.freedesktop.org/show_bug.cgi?id=79696#c21 for some hints. -- 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/20140901/d62f78e1/attachment.html>
[Bug 79696] 10.2.x GPU stall & Xorg crash while using Geeqie
https://bugs.freedesktop.org/show_bug.cgi?id=79696 --- Comment #22 from Michel D?nzer --- BTW, I assume Mesa 10.1.5/6 and the current Git 10.1 branch are not affected? -- 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/20140901/b61db63d/attachment.html>
[PATCH] drm: Do not use BUG_ON(!spin_is_locked())
>ssert_spin_locked() is a better option. >> > > >> > >> > Unless there's a bug, assert_spin_locked() is just going to incur an >> > unnecessary cost every time it is called at runtime. My suggestion was >> > to >> > limit that check only to debugging kernels that include enabling lockdep >> > when tracking down problems rather than needlessly evaluating the >> > conditional every time when there are no bugs. >> >> My experience with gpu drivers (i915) has been that hw and the software >> running it is varied enough that almost always it's better to >> unconditionally enable this stuff. I much prefer assert_spin_locked and >> friends over the lockdep versions since enabling full lockdep is not >> something you usually do. Especially not normal users, and we rely upon >> them for testing the old stuff. Furthermore for the modeset code the >> overhead is totally irrelevant since we're doing metric piles of register >> reads and writes in there anyway. Did anything translate into an R-b here? Dave.
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #32 from Michel D?nzer --- (In reply to comment #30) Mathieu, it sounds like your problem isn't related to this report. Please file your own report, and it would be great if you could bisect Mesa or the kernel. -- 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/20140901/aab35b5c/attachment.html>
