[Bug 31708] [RADEON:KMS:TTM] kernel oops when loading large images with firefox
https://bugs.freedesktop.org/show_bug.cgi?id=31708 --- Comment #15 from Reiner 2012-09-14 07:08:40 UTC --- I can confirm this bug with the following configuration: - Thinkpad R40 w/ ATI Radeon Mobility M7 (AGP) - XUbuntu 12.04.01 with kernel 3.2.0-30-generic #48-Ubuntu SMP - X.Org X Server 1.11.3 - open radeon driver 6.14.99 - KMS, DRI, EXA (bug does not occur with XAA, but then 2D performance is poor; fiddling with EXA options did not get rid of the bug) full Xorg log: [34.083] X.Org X Server 1.11.3 Release Date: 2011-12-16 [34.083] X Protocol Version 11, Revision 0 [34.083] Build Operating System: Linux 2.6.42-26-generic i686 Ubuntu [34.084] Current Operating System: Linux boris 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:54:40 UTC 2012 i686 [34.084] Kernel command line: BOOT_IMAGE=/vmlinuz-3.2.0-30-generic root=UUID=c29eb28f-af18-48d5-99ff-8f871967d672 ro quiet splash vt.handoff=7 [34.084] Build Date: 04 August 2012 01:51:24AM [34.084] xorg-server 2:1.11.4-0ubuntu10.7 (For technical support please see http://www.ubuntu.com/support) [34.084] Current version of pixman: 0.24.4 [34.084] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [34.084] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [34.084] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Sep 14 07:47:48 2012 [34.107] (==) Using config directory: "/etc/X11/xorg.conf.d" [34.107] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [34.108] (==) No Layout section. Using the first Screen section. [34.108] (==) No screen section available. Using defaults. [34.108] (**) |-->Screen "Default Screen Section" (0) [34.108] (**) | |-->Monitor "" [34.108] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [34.108] (**) | |-->Device "Radeon" [34.108] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [34.108] (==) Automatically adding devices [34.108] (==) Automatically enabling devices [34.108] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [34.108] Entry deleted from font path. [34.108] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [34.108] Entry deleted from font path. [34.109] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [34.109] Entry deleted from font path. [34.109] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [34.109] Entry deleted from font path. [34.109] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [34.109] Entry deleted from font path. [34.109] (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. [34.109] Entry deleted from font path. [34.109] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, built-ins [34.109] (==) ModulePath set to "/usr/lib/i386-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules" [34.109] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [34.109] (II) Loader magic: 0xdea5a0 [34.109] (II) Module ABI versions: [34.109] X.Org ANSI C Emulation: 0.4 [34.109] X.Org Video Driver: 11.0 [34.109] X.Org XInput driver : 16.0 [34.109] X.Org Server Extension : 6.0 [34.110] (--) PCI:*(0:1:0:0) 1002:4c57:1014:0527 rev 0, Mem @ 0xe000/134217728, 0xc010/65536, I/O @ 0x3000/256, BIOS @ 0x/131072 [34.110] (II) Open ACPI successful (/var/run/acpid.socket) [34.110] (II) LoadModule: "extmod" [34.129] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [34.129] (II) Module extmod: vendor="X.Org Foundation" [34.129] compiled for 1.11.3, module version = 1.0.0 [34.129] Module class: X.Org Server Extension [34.129] ABI class: X.Org Server Extension, version 6.0 [34.129] (II) Loading extension MIT-SCREEN-SAVER [34.129] (II) Loading extension XFree86-VidModeExtension [34.129] (II) Loading extension XFree86-DGA [34.129] (II) Loading extension DPMS [34.129] (II) Loading extension XVideo [34.129] (II) Loading extension XVideo-MotionCompensation [34.129] (II) Loading extension X-Resource [34.129] (II) LoadModule: "dbe" [34.130] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [34.130] (II) Module dbe: vendor="X.Org Foundation" [34.130] compiled for 1.11.3, module version = 1.0.0 [34.130] Module class: X.Org Server Extension [34.130] ABI class: X.Org Server Extension, version 6.0 [34.130] (II
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #44 from lukensh...@ngi.it 2012-09-14 07:59:36 UTC --- Sorry, I've managed to resolve my first problem (screen blanking after boot for about 30-40 seconds): it is not related to drm, but it depends on fbcon loaded as a module (instead of it being compiled statically). As explained in /usr/src/linux/Documentation/fb/fbcon.txt if fbcon is compiled as a module (CONFIG_FRAMEBUFFER_CONSOLE=m) it can produce blanking and/or garbage on display if it is not loaded immediately. If "Framebuffer Console support" is compiled statically (CONFIG_FRAMEBUFFER_CONSOLE=y) there is no blanking here. "Works for me" HTH. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.
On Don, 2012-09-13 at 18:13 +0400, Dmitry Cherkasov wrote:
> PDE/PTE update code uses CP ring for memory writes.
> All page table entries are preallocated for now in alloc_pt().
>
> It is made as whole because it's hard to divide it to several patches
> that compile and doesn't break anything being applied separately.
>
> Tested on cayman card.
>
> Signed-off-by: Dmitry Cherkasov
> ---
> I couldn't test in on SI card, so would be happy if someone could check it
> there.
[...]
> radeon_ring_write(ring, addr & 0x);
> radeon_ring_write(ring, (addr >> 32) & 0x);
FWIW, masking with 0x is superfluous here, as 64 bit values will
be implicitly truncated to 32 bits. The compiler will hopefully optimize
away the unnecessary & operations, but it might be better not to require
that in the first place.
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 4d67f0f..062896f 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 2f7adea..0df6a55 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1377,6 +1377,7 @@ static struct radeon_asic cayman_asic = {
> .fini = &cayman_vm_fini,
> .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
> .set_page = &cayman_vm_set_page,
> + .set_pdes = &cayman_vm_set_pdes,
> },
> .ring = {
> [RADEON_RING_TYPE_GFX_INDEX] = {
This also needs to be added to si_asic and trinity_asic, or it can't
work on SI or Trinity.
With that fixed, it seems to work on SI, but seems to slow things down
significantly. Have you noticed that as well? Any idea what might be the
reason?
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 2f28ff3..f9bda6e 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -576,9 +579,13 @@ retry:
> return r;
> }
>
> - vm->pt = radeon_sa_bo_cpu_addr(vm->sa_bo);
> - vm->pt_gpu_addr = radeon_sa_bo_gpu_addr(vm->sa_bo);
> - memset(vm->pt, 0, RADEON_GPU_PAGE_ALIGN(vm->last_pfn * 8));
> + DRM_INFO("radeon: reserved %d kb pd & pt tables\n",
> + gpuvm_tables_sz/1024);
DRM_INFO() is too noisy here. Make it DRM_DEBUG_DRIVER() or drop it.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.
On 13.09.2012 20:42, Jerome Glisse wrote: On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher wrote: On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote: On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov wrote: PDE/PTE update code uses CP ring for memory writes. All page table entries are preallocated for now in alloc_pt(). It is made as whole because it's hard to divide it to several patches that compile and doesn't break anything being applied separately. Tested on cayman card. Signed-off-by: Dmitry Cherkasov --- I couldn't test in on SI card, so would be happy if someone could check it there. I wonder how this could have work as you don't set PAGE_TABLE_BLOCK_SIZE field so each page directory entry cover only 1 page. I think PAGE_TABLE_BLOCK_SIZE refers number of 4k pages used for PTE entries per PDE. E.g., 1 4k page contains 512 64 bit PTEs. so if BLOCK_SIZE is set to 1 page, each PDE points to 1 page (4k) or PTE entries. If BLOCK_SIZE is 2, each PDE points to 2 pages (8k) or PTEs, etc. Alex If so then it's ok Yeah, minor nitpick: BLOCK_SIZE seems to be number of 4k pages in a page directory entry minus 1. So with a BLOCK_SIZE of 0 you get one 4K page and with a BLOCK_SIZE of 1 you get 8K, etc... Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.
On Fre, 2012-09-14 at 13:04 +0400, Dmitry Cherkassov wrote: > > With that fixed, it seems to work on SI, but seems to slow things down > > significantly. Have you noticed that as well? Any idea what might be the > > reason? > > > Thanks I'll put it up to the patch. > > I had everything running slow on cayman when having lots of debugging output, > removing it fixed the slowness. I don't think that was it. The only output was the DRM_INFO printed once for each 3D app. > Could you please tell what benchmark/application you noticed slowness with? E.g. reflect from Mesa Demos wasn't able to sustain 60 fps in fullscreen. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.
> With that fixed, it seems to work on SI, but seems to slow things down > significantly. Have you noticed that as well? Any idea what might be the > reason? > Thanks I'll put it up to the patch. I had everything running slow on cayman when having lots of debugging output, removing it fixed the slowness. Could you please tell what benchmark/application you noticed slowness with? -- With best regards, Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] staging: drm/imx: add i.MX IPUv3 base driver
On Fri, Sep 14, 2012 at 11:29:06AM +0200, Dirk Behme wrote:
> On 12.09.2012 12:31, Sascha Hauer wrote:
> >+
> >+ timeout = jiffies + msecs_to_jiffies(1000);
> >+ while (ipu_cm_read(ipu, IPU_MEM_RST) & 0x8000) {
> >+ if (time_after(jiffies, timeout))
> >+ return -ETIME;
> >+ cpu_relax();
> >+ }
> >+
> >+ mdelay(300);
>
>
> >+ return 0;
> >+}
>
> While doing some boot time measurement with i.MX6, we found that the
> above mdelay(300) is hurting regarding boot time. On i.MX6 you have
> two IPU instances, so in the end you get 600ms additional delay.
>
> Looking at the Freescale code, this function looks like
>
> static int ipu_reset(struct ipu_soc *ipu)
> {
> int timeout = 1000;
>
> ipu_cm_write(ipu, 0x807F, IPU_MEM_RST);
>
> while (ipu_cm_read(ipu, IPU_MEM_RST) & 0x8000) {
> if (!timeout--)
>return -ETIME;
> msleep(1);
> }
> return 0;
> }
>
> So there is a msleep() in the loop but no mdelay() outside. Any idea
> why the mdelay() is needed here? Or what could be done regarding
> boot time with this?
I remember we had issues on i.MX51 or 53 without it, but I would have to
recheck it.
In any way, I think this should be reworked. The reset takes quite a
long time and it's not nice to block the boot process for so long.
Some asynchronous reset would be nice here.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #4 from Anisse Astier 2012-09-14 10:16:22 --- I think it is indeed a regression. After many power cycles, I wasn't able to reproduce it with 3.2.16. This is going to take forever to bisect… -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes
I realise this a bit bigger than I would want at this point, exynos is a large chunk, I got them to half what they wanted already, and hey its ARM based, so not going to hurt many people, radeon has only two fixes, but the PLL fixes were a bit bigger, but required for a lot of scenarios, the fence fix is really urgent vmwgfx: I've pulled in a dumb ioctl support patch that I was going to shove in later and cc stable, but we need it asap, its mainly to stop mesa growing a really ugly dependency in userspace to run stuff on vmware, and if I don't stick it in the kernel now, everyone will have to ship ugly userspace libs to workaround it. nouveau: single urgent fix found in F18 testing, causes X to not start properly when f18 plymouth is used i915: smattering of fixes and debug quieting gma500: single regression fix so as I said a bit large, but its fairly well scattered and its all stuff I'll be shipping in F18's 3.6 kernel. Dave. The following changes since commit 0bd1189e239c76eb3a50e458548fbe7e4a5dfff1: Merge branch 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq (2012-09-12 07:16:54 +0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 610bd7da160f76f1644ecb4cd7f39511b49a22cc: drm/nouveau: fix booting with plymouth + dumb support (2012-09-14 15:45:01 +1000) Alan Cox (1): gma500: Fix regression on Oaktrail devices Alex Deucher (1): drm/radeon: rework pll selection (v3) Alexander Shishkin (1): drm/i915: initialize dpio_lock spin lock Christian König (1): drm/radeon: make 64bit fences more robust v3 Daniel Vetter (2): drm/i915: set the right gen3 flip_done mode also at resume drm/i915: fix up the IBX transcoder B check Dave Airlie (6): drm/i915/edp: get the panel delay before powering up Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes vmwgfx: add dumb ioctl support Merge branch 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drm/nouveau: fix booting with plymouth + dumb support Inki Dae (2): drm/exynos: fixed page align bug. drm/exynos: remove DRM_FORMAT_NV12M from plane module Jani Nikula (2): drm/i915: only enable sdvo hotplug irq if needed drm/i915: do not expose a dysfunctional backlight interface to userspace Mandeep Singh Baines (1): drm/exynos: fix double call of drm_prime_(init/destroy)_file_private Sachin Kamat (9): drm/exynos: Remove redundant check in exynos_hdmi.c file drm/exynos: Remove redundant check in exynos_drm_fimd.c file drm/exynos: Use devm_kzalloc in exynos_drm_vidi.c file drm/exynos: Use devm_kzalloc in exynos_drm_hdmi.c file drm/exynos: Use devm_* functions in exynos_drm_g2d.c file drm/exynos: Add dependency for G2D in Kconfig drm/exynos: Make g2d_pm_ops static drm/exynos: Add missing braces around sizeof in exynos_hdmi.c drm/exynos: Add missing braces around sizeof in exynos_mixer.c Thomas Meyer (1): drm/exynos: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. [1] Tomasz Stanislawski (1): drm/exynos: add dummy support for dmabuf-mmap Ville Syrjälä (1): drm: Drop the NV12M and YUV420M formats drivers/gpu/drm/exynos/Kconfig | 2 +- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 7 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c| 2 - drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 - drivers/gpu/drm/exynos/exynos_drm_g2d.c| 52 ++--- drivers/gpu/drm/exynos/exynos_drm_gem.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 - drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 11 +- drivers/gpu/drm/exynos/exynos_mixer.c | 6 +- drivers/gpu/drm/gma500/oaktrail_device.c | 2 + drivers/gpu/drm/i915/i915_dma.c| 1 + drivers/gpu/drm/i915/i915_irq.c| 3 - drivers/gpu/drm/i915/intel_display.c | 6 +- drivers/gpu/drm/i915/intel_dp.c| 11 +- drivers/gpu/drm/i915/intel_panel.c | 31 -- drivers/gpu/drm/i915/intel_pm.c| 3 + drivers/gpu/drm/i915/intel_sdvo.c | 15 ++- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- drivers/gpu/drm/radeon/atombios_crtc.c | 163 +++-- drivers/gpu/drm/radeon/radeon_fence.c | 8 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 5 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 10 ++ drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 73 + include/drm/drm_fourcc.h | 6 +- 26 files changed, 298 insertions
[Bug 31708] [RADEON:KMS:TTM] kernel oops when loading large images with firefox
https://bugs.freedesktop.org/show_bug.cgi?id=31708 --- Comment #16 from Michel Dänzer 2012-09-14 10:49:11 UTC --- (In reply to comment #15) > I can confirm this bug with the following configuration: > - Thinkpad R40 w/ ATI Radeon Mobility M7 (AGP) > - XUbuntu 12.04.01 with kernel 3.2.0-30-generic #48-Ubuntu SMP I doubt it's exactly the same bug (this one should be fixed since 2.6.37?), so it would be better to track your problem in a separate report. Please provide the dmesg output corresponding to your problem, but please attach files instead of pasting them in comments. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Memory eviction in ttm
Hi Maarten! Broadening the audience a bit.. On 9/14/12 9:12 AM, Maarten Lankhorst wrote: Op 13-09-12 23:00, Thomas Hellstrom schreef: On 09/13/2012 07:13 PM, Maarten Lankhorst wrote: Hey Op 13-09-12 18:41, Thomas Hellstrom schreef: On 09/13/2012 05:19 PM, Maarten Lankhorst wrote: Hey, Op 12-09-12 15:28, Thomas Hellstrom schreef: On 09/12/2012 02:48 PM, Maarten Lankhorst wrote: Hey Thomas, I'm playing around with moving reservations from ttm to global, but how ttm ttm is handling reservations is getting in the way. The code wants to move the bo from the lru lock at the same time a reservation is made, but that seems to be slightly too strict. It would really help me if that guarantee is removed. Hi, Maarten. Removing that restriction is not really possible at the moment. Also the memory accounting code depends on this, and may cause reservations in the most awkward places. Since these reservations don't have a ticket they may and will cause deadlocks. So in short the restriction is there to avoid deadlocks caused by ticketless reservations. I have finished the lockdep annotations now which seems to catch almost all abuse I threw at it, so I'm feeling slightly more confident about moving the locking order and reservations around. Maarten, moving reservations in TTM out of the lru lock is incorrect as the code is written now. If we want to move it out we need something for ticketless reservations I've been thinking of having a global hash table of tickets with the task struct pointer as the key, but even then, we'd need to be able to handle EBUSY errors on every operation that might try to reserve a buffer. The fact that lockdep doesn't complain isn't enough. There *will* be deadlock use-cases when TTM is handed the right data-set. Isn't there a way that a subsystem can register a callback to be performed to remove stuff from LRU and to take a pre-reservation lock? What if multiple subsystems need those? You will end up with a deadlock again. I think it would be easier to change the code in ttm_bo.c to not assume the first item on the lru list is really the least recently used, and assume the first item that can be reserved without blocking IS the least recently used instead. So what would happen then is that we'd spin on the first item on the LRU list, since when reserving we must release the LRU lock, and if reserving fails, we thus need to restart LRU traversal. Typically after a schedule(). That's bad. So let's take a step back and analyze why the LRU lock has become a problem. From what I can tell, it's because you want to use per-object lock when reserving instead of a global reservation lock (that TTM could use as the LRU lock). Is that correct? and in that case, in what situation do you envision such a global lock being contended to the extent that it hurts performance? Lockdep WILL complain about trying to use multiple tickets, doing ticketed and unticketed blocking reservations mixed, etc. I want to remove the global fence_lock and make it a per buffer lock, with some lockdep annotations it's perfectly legal to grab obj->fence_lock and obj2->fence_lock if you have a reservation, but it should complain loudly about trying to take 2 fence_locks at the same time without a reservation. Yes, TTM was previously using per buffer fence locks, and that works fine from a deadlock perspective, but it hurts performance. Fencing 200 buffers in a command submission (google-earth for example) will mean 198 unnecessary locks, each discarding the processor pipelines. Locking is a *slow* operation, particularly on systems with many processors, and I don't think it's a good idea to change that back, without analyzing the performance impact. There are reasons people are writing stuff like RCU to avoid locking... So why don't we simply use RCU for fence pointers and get rid of the fence locking? :D danvet originally suggested it as a joke but if you think about it, it would make a lot of sense for this usecase. I thought of that before, but the problem is you'd still need a spinlock to change the buffer's fence pointer, even if reading it becomes quick. Actually, I changed lockdep annotations a bit to distinguish between the cases where ttm_bo_wait is called without reservation, and ttm_bo_wait is called with, as far as I can see there are only 2 places that do it without, at least if I converted my git tree properly.. http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip First one is nouveau_bo_vma_del, this can be fixed easily. Second one is ttm_bo_cleanup_refs and ttm_bo_cleanup_refs_or_queue, if reservation is done first before ttm_bo_wait, the fence_lock could be dropped entirely by adding smb_mb() in reserve and unreserve, functionally there would be no difference. So if you can verify my lockdep annotations are correct in the most recent commit wrt what's using ttm_bo_wait without reservation we could remove the fence_lock entirely. ~Maarten Being a
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 --- Comment #12 from Andy Furniss 2012-09-14 11:24:08 UTC --- Created attachment 67147 --> https://bugs.freedesktop.org/attachment.cgi?id=67147 before r300g: fix colormask with non-BGRA formats -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 --- Comment #13 from Andy Furniss 2012-09-14 11:25:38 UTC --- Created attachment 67148 --> https://bugs.freedesktop.org/attachment.cgi?id=67148 after r300g: fix colormask with non-BGRA formats -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 --- Comment #14 from Andy Furniss 2012-09-14 11:27:03 UTC --- (In reply to comment #11) > Sorry, I should have written "partially fixes..". It only fixes the crash, not > the playback problems. Decode on a 9600 has just been improved slightly by mesa commit - 1e51d368eb5360378218217ff35731896f48512f r300g: fix colormask with non-BGRA formats See attached r300-vdpau-before.png and after. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] SH Mobile DRM driver for v3.7
Hi Dave, The SH Mobile DRM driver is now (in my opinion) ready for mainline. It requires GEM and KMS/FB helpers that have been reviewed on the list and tested. Sascha is waiting for them to reach your tree to send a pull request for another new driver. The following changes since commit 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: gma500: Remove unused variable (2012-09-13 11:40:05 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/fbdev.git drm-lcdc Lars-Peter Clausen (1): DRM: Add DRM KMS/FB CMA helper Laurent Pinchart (2): drm: Add NV24 and NV42 pixel formats drm: Renesas SH Mobile DRM driver Sascha Hauer (1): DRM: Add DRM GEM CMA helper drivers/gpu/drm/Kconfig| 17 + drivers/gpu/drm/Makefile |3 + drivers/gpu/drm/drm_crtc.c |6 + drivers/gpu/drm/drm_fb_cma_helper.c| 406 + drivers/gpu/drm/drm_gem_cma_helper.c | 251 drivers/gpu/drm/shmobile/Kconfig | 10 + drivers/gpu/drm/shmobile/Makefile |7 + drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 90 +++ drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 23 + drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 763 +++ drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 60 ++ drivers/gpu/drm/shmobile/shmob_drm_drv.c | 361 +++ drivers/gpu/drm/shmobile/shmob_drm_drv.h | 48 ++ drivers/gpu/drm/shmobile/shmob_drm_kms.c | 160 + drivers/gpu/drm/shmobile/shmob_drm_kms.h | 34 + drivers/gpu/drm/shmobile/shmob_drm_plane.c | 268 + drivers/gpu/drm/shmobile/shmob_drm_plane.h | 22 + drivers/gpu/drm/shmobile/shmob_drm_regs.h | 311 ++ include/drm/drm_fb_cma_helper.h| 27 + include/drm/drm_fourcc.h |2 + include/drm/drm_gem_cma_helper.h | 44 ++ include/drm/shmob_drm.h| 99 +++ 22 files changed, 3012 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/drm_fb_cma_helper.c create mode 100644 drivers/gpu/drm/drm_gem_cma_helper.c create mode 100644 drivers/gpu/drm/shmobile/Kconfig create mode 100644 drivers/gpu/drm/shmobile/Makefile create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h create mode 100644 include/drm/drm_fb_cma_helper.h create mode 100644 include/drm/drm_gem_cma_helper.h create mode 100644 include/drm/shmob_drm.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47471] Radeon - NMI: PCI system error (SERR) for reason a1 on CPU 0.
https://bugzilla.kernel.org/show_bug.cgi?id=47471 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||DOCUMENTED -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] SH Mobile DRM driver for v3.7
On Fri, 14 Sep 2012 14:38:10 +0200 Laurent Pinchart wrote: > Hi Dave, > > The SH Mobile DRM driver is now (in my opinion) ready for mainline. It > requires GEM and KMS/FB helpers that have been reviewed on the list and > tested. Sascha is waiting for them to reach your tree to send a pull request > for another new driver. > > The following changes since commit 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > are available in the git repository at: > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc Wrong summary ?? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: > On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä > wrote: > > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote: > >> On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrjälä > >> wrote: > >> > On Wed, Sep 12, 2012 at 02:40:56PM -0500, Rob Clark wrote: > >> >> On Wed, Sep 12, 2012 at 1:58 PM, Ville Syrjälä > >> >> wrote: > >> >> > On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote: > >> >> >> On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä > >> >> >> wrote: > >> >> >> > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote: > >> >> >> >> But I think we could still do this w/ one ioctl per crtc for > >> >> >> >> atomic-pageflip. > >> >> >> > > >> >> >> > We could, if we want to sacrifice the synced multi display case. I > >> >> >> > just > >> >> >> > think it might be a real use case at some point. IVI feels like > >> >> >> > the most > >> >> >> > likely short term cadidate to me, but perhaps someone would finally > >> >> >> > introduce some new style phone/tablet thingy. I have seen > >> >> >> > concepts/prototypes of such multi display gadgets in the past, but > >> >> >> > the > >> >> >> > industry apparently got a bit stuck on the rectangular slab with > >> >> >> > touchscreen on one side design. > >> >> >> > >> >> >> I could be wrong, but I think IVI the screens would normally be too > >> >> >> far apart to matter? > >> >> > > >> >> > I was thinking of something like a display on the dash that normally > >> >> > sits low with only a small sliver visible, and extends upwards when > >> >> > you fire up a movie player for example. Internally it could be made > >> >> > up of two displays for power savings purposes. > >> >> > > >> >> >> Anyways, it is really only a problem if you can't do two ioctl()s > >> >> >> within one vblank period. If it actually turns out to be a real > >> >> >> problem, > >> >> > > >> >> > Well exactly that's the problem this whole atomic pageflip stuff is > >> >> > trying to tackle, no? ;) > >> >> > > >> >> >> we could always add later an ioctl that takes an array of > >> >> >> 'struct drm_mode_crtc_atomic_page_flip's. I'm not sure if this is > >> >> >> really useful or not.. but maybe I'm thinking too much about how > >> >> >> weston does it's rendering of different output's independently. > >> >> > > >> >> > I'm just now thinking of surfaceflinger's way of doing things, with > >> >> > its prepare and commit phases. If you need to issue two ioctls to > >> >> > handle > >> >> > cloned displays, then you can end up in a somewhat funky situation. > >> >> > > >> >> > Let's say you have a video overlay in use (one each display > >> >> > naturally), > >> >> > and you increase the downscaling factor enough so that you now have > >> >> > enough memory bandwith to support only one overlay. With independent > >> >> > check ioctls for each display, you never have the full device state > >> >> > available in the kernel, so each check succeeds during the prepare > >> >> > phase. So you decide that you can keep using the video overlays. > >> >> > > >> >> > You then proceed to commit the state, but after the first display has > >> >> > been commited you get an error when trying to commit the second one. > >> >> > What can you do now? The only option is to keep displaying the old > >> >> > frame on the other displays for some time longer, and then on the > >> >> > next frame you can switch to GPU composition. But on the next frame > >> >> > you > >> >> > perhaps no longer need to use GPU composition, but since you can't > >> >> > verify that in the prepare phase, you have no other option but to use > >> >> > GPU composition. > >> >> > > >> >> > So when you run into a configuration that can be supported only > >> >> > partially, you get animation stalls on some displays due to skipped > >> >> > frames, and you always have to fall back to GPU composition for the > >> >> > next frame. > >> >> > > >> >> > If on the other hand you would check the whole state in one ioctl, > >> >> > you'd get the error in the first prepare phase, and could fall back > >> >> > to GPU composition immediately. > >> >> > > >> >> > Am I too much of a perfectionst in considering such things? I don't > >> >> > think so, but perhaps other people disagree. > >> >> > >> >> Ok, if you have a case where the state of the two crtc's are not > >> >> actually independent, then I think you have a valid point. > >> >> > >> >> I'm not quite sure what userspace would do about it, though.. for the > >> >> general case where vsync isn't locked, and you can't even necessarily > >> >> assume vsync period is the same, then I don't really think you want to > >> >> couple rendering to the displays. > >> > > >> > I would say this is going to be the most common use case if you consider > >> > just the number of shipping devices. It's pretty much what every Android > >> > phone/tablet with a HDMI port has to do. > >> > >> bleh, surfaceflinger kinda sucks then.. > > > >
Re: [PATCH] i915: Quirk out disconnected backlight
On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely wrote: > Some platforms (for instance MacbookPros) have custom backlight drivers > and don't use the integrated i915 backlight control. This patch adds a > quirk to disable registering the intel backlight when unused on a > platform. > > Tested on MacbookPro8,3. Without this patch both the intel_backlight and > gmux_backlight devices get registered and userspace doesn't know which > it should use. Userspace is informed throught the backlight/type property. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] SH Mobile DRM driver for v3.7
Hi Alan, On Friday 14 September 2012 13:47:33 Alan Cox wrote: > On Fri, 14 Sep 2012 14:38:10 +0200 Laurent Pinchart wrote: > > Hi Dave, > > > > The SH Mobile DRM driver is now (in my opinion) ready for mainline. It > > requires GEM and KMS/FB helpers that have been reviewed on the list and > > tested. Sascha is waiting for them to reach your tree to send a pull > > request for another new driver. > > > > The following changes since commit 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > > > are available in the git repository at: > > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc > > Wrong summary ?? The repository is oddly named because I've initially created it to hold fbdev patches. The drm-lcdc branch contains DRM patches. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.
> -Original Message- > From: Christian König [mailto:deathsim...@vodafone.de] > Sent: Friday, September 14, 2012 4:49 AM > To: Jerome Glisse > Cc: Alex Deucher; Cherkasov, Dmitrii; linux-ker...@vger.kernel.org; dri- > de...@lists.freedesktop.org; Deucher, Alexander; Dave Airlie; Dmitry > Cherkasov > Subject: Re: [PATCH] Add 2-level GPUVM pagetables support to radeon > driver. > > On 13.09.2012 20:42, Jerome Glisse wrote: > > On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher > wrote: > >> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse > wrote: > >>> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov > >>> wrote: > PDE/PTE update code uses CP ring for memory writes. > All page table entries are preallocated for now in alloc_pt(). > > It is made as whole because it's hard to divide it to several patches > that compile and doesn't break anything being applied separately. > > Tested on cayman card. > > Signed-off-by: Dmitry Cherkasov > --- > I couldn't test in on SI card, so would be happy if someone could check > it there. > >>> I wonder how this could have work as you don't set > >>> PAGE_TABLE_BLOCK_SIZE field so each page directory entry cover only 1 > >>> page. > >> I think PAGE_TABLE_BLOCK_SIZE refers number of 4k pages used for PTE > >> entries per PDE. E.g., 1 4k page contains 512 64 bit PTEs. so if > >> BLOCK_SIZE is set to 1 page, each PDE points to 1 page (4k) or PTE > >> entries. If BLOCK_SIZE is 2, each PDE points to 2 pages (8k) or PTEs, > >> etc. > >> > >> Alex > >> > > If so then it's ok > Yeah, minor nitpick: BLOCK_SIZE seems to be number of 4k pages in a page > directory entry minus 1. > > So with a BLOCK_SIZE of 0 you get one 4K page and with a BLOCK_SIZE of 1 > you get 8K, etc... It's LOG2: PAGE_TABLE_BLOCK_SIZE 27:24 0x0 log2 number of pages in page table block (default = 1 page) > > Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Quirk out disconnected backlight
On Fri, 2012-09-14 at 14:09 +0100, Grant Likely wrote: > On Fri, Sep 14, 2012 at 2:01 PM, Chris Wilson > wrote: > > On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely > > wrote: > >> Some platforms (for instance MacbookPros) have custom backlight drivers > >> and don't use the integrated i915 backlight control. This patch adds a > >> quirk to disable registering the intel backlight when unused on a > >> platform. > >> > >> Tested on MacbookPro8,3. Without this patch both the intel_backlight and > >> gmux_backlight devices get registered and userspace doesn't know which > >> it should use. > > > > Userspace is informed throught the backlight/type property. > > Perhaps, but userspace (Ubuntu) isn't doing anything with it, and it > still remains that it makes no sense whatsoever to register a > backlight device that doesn't exist. Indeed. Userspace (well, gnome-settings-daemon) will use the backlight provided by X, in preference to anything it finds in /sys/class/backlight. So if the Intel one is present (and thus exposed via X) then userspace will never bother with comparing types and choosing the sanest backlight to use. See https://bugzilla.redhat.com/show_bug.cgi?id=752595 -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä
wrote:
> On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote:
>> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä
>> wrote:
>> > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote:
>> >> On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrjälä
>> >> wrote:
[snip]
>> >> >
>> >> > I would say this is going to be the most common use case if you consider
>> >> > just the number of shipping devices. It's pretty much what every Android
>> >> > phone/tablet with a HDMI port has to do.
>> >>
>> >> bleh, surfaceflinger kinda sucks then..
>> >
>> > Why? This use case is not enforced by surfaceflinger, it's just the use
>> > case most devices would have.
>> >
>> > I don't think there's anything wrong with the way surfaceflinger is
>> > designed
>> > with the prepare and commit phases. How else would you do it?
>>
>> well, maybe I misunderstood how surfaceflinger works, but it sounded
>> like it has one prepare/commit phase across outputs, vs what weston
>> compositor does where each output is rendered and flipped
>> independently at the rate of that particular output. If the two
>> outputs just happen to be vsync aligned, you would end up flipping at
>> the same time, but if the are not locked you don't have any artificial
>> constraint in the rendering/flipping.
>
> OK so it's purely a pull based model, whereas surfaceflinger is more
> push based.
>
> I suppose it might be possible to make surfaceflinger support a pull
> model by driving the compositor loop through a combined signal from
> multiple outputs. But IIRC it did have some timing related code in
> there somewhere, so it might not be happy about it. It might also
As I understood, at least in older versions android versions,
rendering was based on a timer as there was no vblank event to
userspace on most SoC platforms (which sounds strange, but so far most
SoC's are using fbdev and/or crazy hacks rather than drm/kms)
not sure if the timer is still there.. but I hope it goes away, it is
really a horrible way to keep track of vsync
> affect the clients' rendering speed since the compositor would be
> pulling their buffers from queue at non-constant speed. I don't
> remember the details of the buffer management very well, so I can't be
> sure though. But I probably wouldn't bother trying this, since the
> straightforward approach is so simple, and the results are reasonably
> good.
>
> The pull model does seem more flexible. But it does require a bit of
> extra complexity in the compositor to avoid compositing the same scene
> multiple times needlessly when multiple cloned displays are involved.
> I suppose ideally you'd want to recompose for each display to minimize
> visible latency, but from power usage POV it may not be a good idea.
fwiw, weston is already being pretty clever about keeping track of
damage and minimizing the area of the screen that must be re-rendered.
I'm not sure if SF does anything like this.
>> >> >> >From userspace API, I guess something like:
>> >> >>
>> >> >> struct drm_mode_crtc_atomic_page_flip {
>> >> >> uint32_t flags;
>> >> >> uint32_t count_crtcs;
>> >> >> uint64_t crtc_ids_ptr; /* array of uint32_t */
>> >> >> uint64_t count_props_ptr; /* array of uint32_t, # of prop's per
>> >> >> crtc */
>> >> >> uint64_t props_ptr; /* ptr to array of
>> >> >> drm_mode_obj_set_property */
>> >> >> uint64_t user_data;
>> >> >> };
>> >> >
>> >> > Starting to look much like my drm_mode_atomic struct :)
>> >> >
>> >> > Let's compare:
>> >> >
>> >> > struct drm_mode_atomic {
>> >> > __u32 flags;
>> >> > __u32 count_objs;
>> >> > __u64 objs_ptr;
>> >> > __u64 count_props_ptr;
>> >> > __u64 props_ptr;
>> >> > __u64 prop_values_ptr;
>> >> > __u64 blob_values_ptr;
>> >> > };
>> >>
>> >> well, you do miss userdata, I think
>> >
>> > Sure, because I didn't add the event stuff yet.
>>
>> note that the test phase doesn't need vblank events, and also
>> shouldn't -EBUSY if there is still a pending flip[*],
>
> Right. Personally I'm not a fan of the EBUSY behaviour at all. Seems
> a bit pointless since user space can take care of it via the event
> mechanism. But I suppose you want it for omap so that you can avoid
> having to write software workarounds to overcome the GO bit
> limitations.
I the main issue is disconnecting an overlay from one crtc and
connecting to another.. I would expect that any hw which can connect
an ovl to more than one possible crtc would have the same limit (ie.
have to wait until scanout on previous crtc completes), so I think
EBUSY is a good way to indicate to userspace that the requested
configuration is not possible *now* but would be possible in the
future.
>> so I'd propose
>> that however we go about pageflip (one super-ioctl, or one per crtc),
>> we could use the atomic-modeset ioctl for the test step
>
> Yeah that seems reasonable. If we do that, then it doesn't matter
[Bug 51652] [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=51652 --- Comment #4 from okias 2012-09-14 13:26:32 UTC --- to picture - I tested rc2 and I accidantally discovered, that it's because OpenGL Kwin, after deactivating affects it's ok. So some git mesa update... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Quirk out disconnected backlight
On Fri, 14 Sep 2012 14:12:19 +0100, David Woodhouse wrote: > On Fri, 2012-09-14 at 14:09 +0100, Grant Likely wrote: > > On Fri, Sep 14, 2012 at 2:01 PM, Chris Wilson > > wrote: > > > On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely > > > wrote: > > >> Some platforms (for instance MacbookPros) have custom backlight drivers > > >> and don't use the integrated i915 backlight control. This patch adds a > > >> quirk to disable registering the intel backlight when unused on a > > >> platform. > > >> > > >> Tested on MacbookPro8,3. Without this patch both the intel_backlight and > > >> gmux_backlight devices get registered and userspace doesn't know which > > >> it should use. > > > > > > Userspace is informed throught the backlight/type property. > > > > Perhaps, but userspace (Ubuntu) isn't doing anything with it, and it > > still remains that it makes no sense whatsoever to register a > > backlight device that doesn't exist. > > Indeed. Userspace (well, gnome-settings-daemon) will use the backlight > provided by X, in preference to anything it finds > in /sys/class/backlight. So if the Intel one is present (and thus > exposed via X) then userspace will never bother with comparing types and > choosing the sanest backlight to use. > > See https://bugzilla.redhat.com/show_bug.cgi?id=752595 And if you look at that bug, it starts off by complaining that a workaround is required in order to use the intel_backlight. By the time you hit the issue with apple_gmux, the upstream ddx already carried the fix for a couple of months and even had it in a release. And more recently we took a patch to allow the user to override which backlight is preferred to handle the case of a broken platform/firmware interface being selected instead of intel_backlight. Userspace is indeed trying to do the right thing with the information provided by the kernel. apple_gmux is not the only device with a phantom PWM BLC, which is why the default preference is to use the platform/firmware provided backlight interface, if any. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Memory eviction in ttm
Op 14-09-12 12:50, Thomas Hellström schreef: > Hi Maarten! > > Broadening the audience a bit.. > > On 9/14/12 9:12 AM, Maarten Lankhorst wrote: >> Op 13-09-12 23:00, Thomas Hellstrom schreef: >>> On 09/13/2012 07:13 PM, Maarten Lankhorst wrote: Hey Op 13-09-12 18:41, Thomas Hellstrom schreef: > On 09/13/2012 05:19 PM, Maarten Lankhorst wrote: >> Hey, >> >> Op 12-09-12 15:28, Thomas Hellstrom schreef: >>> On 09/12/2012 02:48 PM, Maarten Lankhorst wrote: Hey Thomas, I'm playing around with moving reservations from ttm to global, but how ttm ttm is handling reservations is getting in the way. The code wants to move the bo from the lru lock at the same time a reservation is made, but that seems to be slightly too strict. It would really help me if that guarantee is removed. >>> Hi, Maarten. >>> >>> Removing that restriction is not really possible at the moment. >>> Also the memory accounting code depends on this, and may cause >>> reservations >>> in the most awkward places. Since these reservations don't have a ticket >>> they may and will cause deadlocks. So in short the restriction is there >>> to avoid deadlocks caused by ticketless reservations. >> I have finished the lockdep annotations now which seems to catch almost >> all abuse I threw at it, so I'm feeling slightly more confident about >> moving >> the locking order and reservations around. > Maarten, moving reservations in TTM out of the lru lock is incorrect as > the code is > written now. If we want to move it out we need something for ticketless > reservations > > I've been thinking of having a global hash table of tickets with the task > struct pointer as the key, > but even then, we'd need to be able to handle EBUSY errors on every > operation that might try to > reserve a buffer. > > The fact that lockdep doesn't complain isn't enough. There *will* be > deadlock use-cases when TTM is handed > the right data-set. > > Isn't there a way that a subsystem can register a callback to be > performed to remove stuff from LRU and > to take a pre-reservation lock? What if multiple subsystems need those? You will end up with a deadlock again. I think it would be easier to change the code in ttm_bo.c to not assume the first item on the lru list is really the least recently used, and assume the first item that can be reserved without blocking IS the least recently used instead. >>> So what would happen then is that we'd spin on the first item on the LRU >>> list, since >>> when reserving we must release the LRU lock, and if reserving fails, we thus >>> need to restart LRU traversal. Typically after a schedule(). That's bad. >>> >>> So let's take a step back and analyze why the LRU lock has become a problem. >>> From what I can tell, it's because you want to use per-object lock when >>> reserving instead of a >>> global reservation lock (that TTM could use as the LRU lock). Is that >>> correct? >>> and in that case, in what situation do you envision such a global lock >>> being contended >>> to the extent that it hurts performance? >>> >> Lockdep WILL complain about trying to use multiple tickets, doing >> ticketed >> and unticketed blocking reservations mixed, etc. >> >> I want to remove the global fence_lock and make it a per buffer lock, >> with some >> lockdep annotations it's perfectly legal to grab obj->fence_lock and >> obj2->fence_lock >> if you have a reservation, but it should complain loudly about trying to >> take 2 fence_locks >> at the same time without a reservation. > Yes, TTM was previously using per buffer fence locks, and that works fine > from a deadlock perspective, but > it hurts performance. Fencing 200 buffers in a command submission > (google-earth for example) will mean > 198 unnecessary locks, each discarding the processor pipelines. Locking > is a *slow* operation, particularly > on systems with many processors, and I don't think it's a good idea to > change that back, without analyzing > the performance impact. There are reasons people are writing stuff like > RCU to avoid locking... So why don't we simply use RCU for fence pointers and get rid of the fence locking? :D danvet originally suggested it as a joke but if you think about it, it would make a lot of sense for this usecase. >>> I thought of that before, but the problem is you'd still need a spinlock to >>> change the buffer's fence pointer, >>> even if reading it becomes quick. >> Actually, I changed lockdep annotations a bit to distinguish between the >> cases where ttm_bo_wait is called without reservation, and ttm_bo_wait >> is called with, as fa
[Bug 54877] [bisected] rendering corrupted for windows larger than 2048 pixels in one dimension
https://bugs.freedesktop.org/show_bug.cgi?id=54877 --- Comment #4 from Alex Deucher 2012-09-14 13:47:19 UTC --- (In reply to comment #3) > (In reply to comment #2) > > Created attachment 67121 [details] [review] [review] > > fix > > > > This fixes it. I need to find out how the quant mode affects the range of > > values. > > My guess is that QUANT_MODE determines the position of fixed point for > internal > calculations in hw. Quantization precision 1/4096 means 12 bits, and it looks > like we have 11 bits before the point in that case, with 23 bits total. So if > we need to increase the range, we have to move the point lowering the > precision. > > I've tried 1/256 and other values on evergreen for initial implementation of > that patch in hope that it'll be enough, but IIRC 1/4096 fixed more tests > (though possibly some test results were simply random). If some tests are > really failing due to lower precision, I guess we might want to adjust > QUANT_MODE dynamically. That makes sense. The hw worked similarly on r300-r500. We should adjust the mode based on the size of the buffer I suppose. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Quirk out disconnected backlight
On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote: > Tested on MacbookPro8,3. Without this patch both the intel_backlight and > gmux_backlight devices get registered and userspace doesn't know which > it should use. Userspace should be figuring out which one to use from the type field. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP
On Wed, 12 Sep 2012 18:47:07 +0300, ville.syrj...@linux.intel.com wrote:
> +static void intel_flip_finish(struct drm_flip *flip)
> +{
> + struct intel_flip *intel_flip =
> + container_of(flip, struct intel_flip, base);
> + struct drm_device *dev = intel_flip->crtc->dev;
> +
> + if (intel_flip->old_bo) {
> + mutex_lock(&dev->struct_mutex);
> +
> + intel_finish_fb(intel_flip->old_bo);
So if I understand correctly, this code is called after the flip is
already complete?
The intel_finish_fb() exists to flush pending batches and flips on the
current fb, prior to changing the scanout registers. (There is a
hardware dependency such that the GPU may be executing a command that
required the current modesetting.) In the case of flip completion, all
of those dependencies have already been retired and so the finish should
be a no-op. And so it should no be required, nor the changes to
intel_finish_fb (which should have included a change in the name to
indicate that is now taking the fb_obj).
> + intel_unpin_fb_obj(intel_flip->old_bo);
> +
> + mutex_unlock(&dev->struct_mutex);
> + }
> +
> +}
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote:
> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä
> wrote:
> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote:
> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä
> >> wrote:
> >> > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote:
> >> >> On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrjälä
> >> >> wrote:
> [snip]
> >> >> >
> >> >> > I would say this is going to be the most common use case if you
> >> >> > consider
> >> >> > just the number of shipping devices. It's pretty much what every
> >> >> > Android
> >> >> > phone/tablet with a HDMI port has to do.
> >> >>
> >> >> bleh, surfaceflinger kinda sucks then..
> >> >
> >> > Why? This use case is not enforced by surfaceflinger, it's just the use
> >> > case most devices would have.
> >> >
> >> > I don't think there's anything wrong with the way surfaceflinger is
> >> > designed
> >> > with the prepare and commit phases. How else would you do it?
> >>
> >> well, maybe I misunderstood how surfaceflinger works, but it sounded
> >> like it has one prepare/commit phase across outputs, vs what weston
> >> compositor does where each output is rendered and flipped
> >> independently at the rate of that particular output. If the two
> >> outputs just happen to be vsync aligned, you would end up flipping at
> >> the same time, but if the are not locked you don't have any artificial
> >> constraint in the rendering/flipping.
> >
> > OK so it's purely a pull based model, whereas surfaceflinger is more
> > push based.
> >
> > I suppose it might be possible to make surfaceflinger support a pull
> > model by driving the compositor loop through a combined signal from
> > multiple outputs. But IIRC it did have some timing related code in
> > there somewhere, so it might not be happy about it. It might also
>
> As I understood, at least in older versions android versions,
> rendering was based on a timer as there was no vblank event to
> userspace on most SoC platforms (which sounds strange, but so far most
> SoC's are using fbdev and/or crazy hacks rather than drm/kms)
>
> not sure if the timer is still there.. but I hope it goes away, it is
> really a horrible way to keep track of vsync
I've only looked at ICS in any detail. At least there we used the page
flip event from one display to set the pace of the compositor loop.
IIRC JB is supposed to have some vsync related changes, but I haven't
looked at the code.
> > affect the clients' rendering speed since the compositor would be
> > pulling their buffers from queue at non-constant speed. I don't
> > remember the details of the buffer management very well, so I can't be
> > sure though. But I probably wouldn't bother trying this, since the
> > straightforward approach is so simple, and the results are reasonably
> > good.
> >
> > The pull model does seem more flexible. But it does require a bit of
> > extra complexity in the compositor to avoid compositing the same scene
> > multiple times needlessly when multiple cloned displays are involved.
> > I suppose ideally you'd want to recompose for each display to minimize
> > visible latency, but from power usage POV it may not be a good idea.
>
> fwiw, weston is already being pretty clever about keeping track of
> damage and minimizing the area of the screen that must be re-rendered.
> I'm not sure if SF does anything like this.
IIRC it can do that, but the EGL implementation needs to support
EGL_BUFFER_PRESERVED.
I suppose the best way to implement EGL_BUFFER_PRESERVED with
page flips would be to schedule the flip and immediately perform
a blit from the new front buffer to the new back buffer. Well,
unless the hardware has some more clever mechanism for it.
Does weston depend on preserved flips too, or can it even track
damage independently for each buffer?
> >> >> >> >From userspace API, I guess something like:
> >> >> >>
> >> >> >> struct drm_mode_crtc_atomic_page_flip {
> >> >> >> uint32_t flags;
> >> >> >> uint32_t count_crtcs;
> >> >> >> uint64_t crtc_ids_ptr; /* array of uint32_t */
> >> >> >> uint64_t count_props_ptr; /* array of uint32_t, # of prop's
> >> >> >> per crtc */
> >> >> >> uint64_t props_ptr; /* ptr to array of
> >> >> >> drm_mode_obj_set_property */
> >> >> >> uint64_t user_data;
> >> >> >> };
> >> >> >
> >> >> > Starting to look much like my drm_mode_atomic struct :)
> >> >> >
> >> >> > Let's compare:
> >> >> >
> >> >> > struct drm_mode_atomic {
> >> >> > __u32 flags;
> >> >> > __u32 count_objs;
> >> >> > __u64 objs_ptr;
> >> >> > __u64 count_props_ptr;
> >> >> > __u64 props_ptr;
> >> >> > __u64 prop_values_ptr;
> >> >> > __u64 blob_values_ptr;
> >> >> > };
> >> >>
> >> >> well, you do miss userdata, I think
> >> >
> >> > Sure, because I didn't add the event stuff yet.
> >>
> >> note that the test phase doesn't need vblank events, and also
> >> shouldn't -EBUSY if there i
[Bug 54767] [r300g] 298 failures on WebGL Conformance Test
https://bugs.freedesktop.org/show_bug.cgi?id=54767 --- Comment #2 from Tomasz P. 2012-09-14 14:05:25 UTC --- Forgot to add. I have compiled withtexture npot video enabled in r300_screen.c During test there was few errors in konsole. r300 FP: Compiler Error: compiler/r300_fragprog_emit.c::translate_rgb_opcode(): translate_rgb_opcode: Unknown opcode DDX Using a dummy shader instead. r300 FP: Compiler Error: compiler/r300_fragprog_emit.c::emit_alu(): Too many ALU instructions Using a dummy shader instead. r300: ERROR: FS input FACE unassigned. When I also enabled Hyper-Z I have got 51 errors. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP
On Fri, Sep 14, 2012 at 02:57:26PM +0100, Chris Wilson wrote:
> On Wed, 12 Sep 2012 18:47:07 +0300, ville.syrj...@linux.intel.com wrote:
> > +static void intel_flip_finish(struct drm_flip *flip)
> > +{
> > + struct intel_flip *intel_flip =
> > + container_of(flip, struct intel_flip, base);
> > + struct drm_device *dev = intel_flip->crtc->dev;
> > +
> > + if (intel_flip->old_bo) {
> > + mutex_lock(&dev->struct_mutex);
> > +
> > + intel_finish_fb(intel_flip->old_bo);
>
> So if I understand correctly, this code is called after the flip is
> already complete?
Yes.
> The intel_finish_fb() exists to flush pending batches and flips on the
> current fb, prior to changing the scanout registers. (There is a
> hardware dependency such that the GPU may be executing a command that
> required the current modesetting.) In the case of flip completion, all
> of those dependencies have already been retired and so the finish should
> be a no-op. And so it should no be required, nor the changes to
> intel_finish_fb (which should have included a change in the name to
> indicate that is now taking the fb_obj).
Actually I'm not quite sure where this intel_finish_fb() call originated.
Based on the name it didn't make sense to me, but I left it there for
now. Hmm. OK it came from one patch from Imre while I was on vacation.
I suppose he got it from intel_pipe_set_base() which does call
intel_finish_fb() on the old fb. Why does it do that?
I've not really dug into the GPU synchronization side and pin/fence stuff,
so it's no surprise my code is a bit fscked up in those areas.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP
On Fri, 14 Sep 2012 17:21:30 +0300, Ville Syrjälä
wrote:
> On Fri, Sep 14, 2012 at 02:57:26PM +0100, Chris Wilson wrote:
> > On Wed, 12 Sep 2012 18:47:07 +0300, ville.syrj...@linux.intel.com wrote:
> > > +static void intel_flip_finish(struct drm_flip *flip)
> > > +{
> > > + struct intel_flip *intel_flip =
> > > + container_of(flip, struct intel_flip, base);
> > > + struct drm_device *dev = intel_flip->crtc->dev;
> > > +
> > > + if (intel_flip->old_bo) {
> > > + mutex_lock(&dev->struct_mutex);
> > > +
> > > + intel_finish_fb(intel_flip->old_bo);
> >
> > So if I understand correctly, this code is called after the flip is
> > already complete?
>
> Yes.
>
> > The intel_finish_fb() exists to flush pending batches and flips on the
> > current fb, prior to changing the scanout registers. (There is a
> > hardware dependency such that the GPU may be executing a command that
> > required the current modesetting.) In the case of flip completion, all
> > of those dependencies have already been retired and so the finish should
> > be a no-op. And so it should no be required, nor the changes to
> > intel_finish_fb (which should have included a change in the name to
> > indicate that is now taking the fb_obj).
>
> Actually I'm not quite sure where this intel_finish_fb() call originated.
> Based on the name it didn't make sense to me, but I left it there for
> now. Hmm. OK it came from one patch from Imre while I was on vacation.
> I suppose he got it from intel_pipe_set_base() which does call
> intel_finish_fb() on the old fb. Why does it do that?
It all boils down to the modeset being asynchronous to the GPU
processing the command stream. So we may be currently processing a batch
that is waiting on the pipe to go past a particular scanline, and if the
modesetting were to disable that pipe, or to change its size, then we
risk the WAIT_FOR_EVENT never completing - leading to hangcheck
detecting the frozen display and an angry user.
The other aspect is to synchronize the modeset with any outstanding
pageflips.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Quirk out disconnected backlight
On Fri, 2012-09-14 at 14:48 +0100, Matthew Garrett wrote: > On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote: > > > Tested on MacbookPro8,3. Without this patch both the intel_backlight and > > gmux_backlight devices get registered and userspace doesn't know which > > it should use. > > Userspace should be figuring out which one to use from the type field. It only does that if it's using gsd-backlight-helper to poke at /sys/class/backlight directly. If X exposes a backlight, (as it does for the Intel backlight), then gsd will just use that. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Quirk out disconnected backlight
On Fri, Sep 14, 2012 at 03:29:14PM +0100, David Woodhouse wrote: > On Fri, 2012-09-14 at 14:48 +0100, Matthew Garrett wrote: > > On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote: > > > > > Tested on MacbookPro8,3. Without this patch both the intel_backlight and > > > gmux_backlight devices get registered and userspace doesn't know which > > > it should use. > > > > Userspace should be figuring out which one to use from the type field. > > It only does that if it's using gsd-backlight-helper to poke > at /sys/class/backlight directly. If X exposes a backlight, (as it does > for the Intel backlight), then gsd will just use that. Yeah, X should be doing the same. If it's not then it's broken. OTOH, I do agree that if we already know that we can't do anything with the backlight (as is clearly the case if the PWM field is 0) we should just disable it. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä wrote: > On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote: >> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä >> wrote: >> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: >> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä >> >> wrote: >> >> > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote: >> >> >> On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrjälä >> >> >> wrote: >> [snip] >> >> >> > >> >> >> > I would say this is going to be the most common use case if you >> >> >> > consider >> >> >> > just the number of shipping devices. It's pretty much what every >> >> >> > Android >> >> >> > phone/tablet with a HDMI port has to do. >> >> >> >> >> >> bleh, surfaceflinger kinda sucks then.. >> >> > >> >> > Why? This use case is not enforced by surfaceflinger, it's just the use >> >> > case most devices would have. >> >> > >> >> > I don't think there's anything wrong with the way surfaceflinger is >> >> > designed >> >> > with the prepare and commit phases. How else would you do it? >> >> >> >> well, maybe I misunderstood how surfaceflinger works, but it sounded >> >> like it has one prepare/commit phase across outputs, vs what weston >> >> compositor does where each output is rendered and flipped >> >> independently at the rate of that particular output. If the two >> >> outputs just happen to be vsync aligned, you would end up flipping at >> >> the same time, but if the are not locked you don't have any artificial >> >> constraint in the rendering/flipping. >> > >> > OK so it's purely a pull based model, whereas surfaceflinger is more >> > push based. >> > >> > I suppose it might be possible to make surfaceflinger support a pull >> > model by driving the compositor loop through a combined signal from >> > multiple outputs. But IIRC it did have some timing related code in >> > there somewhere, so it might not be happy about it. It might also >> >> As I understood, at least in older versions android versions, >> rendering was based on a timer as there was no vblank event to >> userspace on most SoC platforms (which sounds strange, but so far most >> SoC's are using fbdev and/or crazy hacks rather than drm/kms) >> >> not sure if the timer is still there.. but I hope it goes away, it is >> really a horrible way to keep track of vsync > > I've only looked at ICS in any detail. At least there we used the page > flip event from one display to set the pace of the compositor loop. > IIRC JB is supposed to have some vsync related changes, but I haven't > looked at the code. > >> > affect the clients' rendering speed since the compositor would be >> > pulling their buffers from queue at non-constant speed. I don't >> > remember the details of the buffer management very well, so I can't be >> > sure though. But I probably wouldn't bother trying this, since the >> > straightforward approach is so simple, and the results are reasonably >> > good. >> > >> > The pull model does seem more flexible. But it does require a bit of >> > extra complexity in the compositor to avoid compositing the same scene >> > multiple times needlessly when multiple cloned displays are involved. >> > I suppose ideally you'd want to recompose for each display to minimize >> > visible latency, but from power usage POV it may not be a good idea. >> >> fwiw, weston is already being pretty clever about keeping track of >> damage and minimizing the area of the screen that must be re-rendered. >> I'm not sure if SF does anything like this. > > IIRC it can do that, but the EGL implementation needs to support > EGL_BUFFER_PRESERVED. > > I suppose the best way to implement EGL_BUFFER_PRESERVED with > page flips would be to schedule the flip and immediately perform > a blit from the new front buffer to the new back buffer. Well, > unless the hardware has some more clever mechanism for it. > > Does weston depend on preserved flips too, or can it even track > damage independently for each buffer? well, weston knows how many buffers are at play. So it takes the union of the damage from the last time the buffer was used (well, currently it assumes only double buffered) and the new damage. This way it avoids need for the gl driver, which doesn't know as well what is going on as the app, from needing to do a back-blit. It can do this because w/ drm/gbm egl winsys, eglSwapBuffers() doesn't actually swap the buffers on the display and weston is in charge of which buffer is displayed or rendered. Weston explicitly calls page flip ioctl. The good news being that it can atomically flip overlay layers at the same time once the new ioctl is in place. Maybe it is useful to look at http://github.com/robclark/kmscube .. it doesn't actually use planes, but shows the interaction of egl and kms. Maybe I should enhance it w/ multiple rotating cubes on different overlays. ;-) >> >> >> >> >From userspace API, I guess something like: >> >> >> >> >> >> >> >> struct drm_mode_crtc_atomic_page_flip
[Bug 34874] --enable-shared-glapi breaks apps
https://bugs.freedesktop.org/show_bug.cgi?id=34874 Andreas Boll changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Other -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
On Mit, 2012-09-12 at 15:29 +0200, Paul Menzel wrote: > Am Dienstag, den 11.09.2012, 15:24 +0200 schrieb Michel Dänzer: > > On Die, 2012-09-11 at 15:07 +0200, Paul Menzel wrote: > > > Am Dienstag, den 11.09.2012, 14:55 +0200 schrieb Michel Dänzer: > > > > On Die, 2012-09-11 at 14:42 +0200, Paul Menzel wrote: > > > > > > > > > > using Debian Sid/unstable with the awesome 3.4.13-1 window manager and > > > > > Evolution 3.4.3-1, htop shows X to constantly use 10 % of the CPU. > > > > > Closing Evolution the usage goes back to more or less 0 %. > > > > > > > > I'm not seeing this. Is there something in your Evolution window(s) that > > > > is constantly repainting, e.g. a spinner in the status bar, a blinking > > > > cursor, ... ? > > > > > > Now that you are mentioning it, in the bottom there is the message > > > »Checking for New Messages« and next to it there is an animation where > > > something goes around a circle. Canceling that removes X’s CPU usage. > > > > That's a GTK+ spinner widget, which uses RENDER trapezoids, which is a > > software rendering fallback with EXA. > > Could that be changed to not us some fallback? Anything could be done ;), but it would require a lot of work to EXA and the drivers, which is unlikely to happen at this point. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 Anisse Astier changed: What|Removed |Added Regression|No |Yes -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP
On Fri, Sep 14, 2012 at 03:27:05PM +0100, Chris Wilson wrote:
> On Fri, 14 Sep 2012 17:21:30 +0300, Ville Syrjälä
> wrote:
> > On Fri, Sep 14, 2012 at 02:57:26PM +0100, Chris Wilson wrote:
> > > On Wed, 12 Sep 2012 18:47:07 +0300, ville.syrj...@linux.intel.com wrote:
> > > > +static void intel_flip_finish(struct drm_flip *flip)
> > > > +{
> > > > + struct intel_flip *intel_flip =
> > > > + container_of(flip, struct intel_flip, base);
> > > > + struct drm_device *dev = intel_flip->crtc->dev;
> > > > +
> > > > + if (intel_flip->old_bo) {
> > > > + mutex_lock(&dev->struct_mutex);
> > > > +
> > > > + intel_finish_fb(intel_flip->old_bo);
> > >
> > > So if I understand correctly, this code is called after the flip is
> > > already complete?
> >
> > Yes.
> >
> > > The intel_finish_fb() exists to flush pending batches and flips on the
> > > current fb, prior to changing the scanout registers. (There is a
> > > hardware dependency such that the GPU may be executing a command that
> > > required the current modesetting.) In the case of flip completion, all
> > > of those dependencies have already been retired and so the finish should
> > > be a no-op. And so it should no be required, nor the changes to
> > > intel_finish_fb (which should have included a change in the name to
> > > indicate that is now taking the fb_obj).
> >
> > Actually I'm not quite sure where this intel_finish_fb() call originated.
> > Based on the name it didn't make sense to me, but I left it there for
> > now. Hmm. OK it came from one patch from Imre while I was on vacation.
> > I suppose he got it from intel_pipe_set_base() which does call
> > intel_finish_fb() on the old fb. Why does it do that?
>
> It all boils down to the modeset being asynchronous to the GPU
> processing the command stream. So we may be currently processing a batch
> that is waiting on the pipe to go past a particular scanline, and if the
> modesetting were to disable that pipe, or to change its size, then we
> risk the WAIT_FOR_EVENT never completing - leading to hangcheck
> detecting the frozen display and an angry user.
intel_pipe_set_base() won't disable the pipe or change the size,
it'll just flip the primary plane. So that doesn't quite explain
why the call is there, as opposed to being called just from the
full modeset path.
Also wouldn't any batch buffer with WAIT_FOR_EVENT be in risk of
stalling, not just ones related to the old fb?
> The other aspect is to synchronize the modeset with any outstanding
> pageflips.
Right, that does make sense. But doing it from a function called
intel_finish_fb() is a bit confusing, as the condition really
shouldn't depend on any specific fb object. But I suppose this is
just a result of the "only one outstanding flip" policy.
BTW regarding this WAIT_FOR_EVENT thing. I got the impression that
the scanline window wait doesn't work on recent hardware generations
any more. Is that true? I was thinking that perhaps I could use it
along with the load register command to perform the flips through
the command queue.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP
On Fri, Sep 14, 2012 at 5:30 PM, Ville Syrjälä wrote: > intel_pipe_set_base() won't disable the pipe or change the size, > it'll just flip the primary plane. So that doesn't quite explain > why the call is there, as opposed to being called just from the > full modeset path. intel_pipe_set_base is also called in the modeset case, i.e. when we could potentially change the height of the mode. And if we wait on a large enough scanline which doesn't exist in the new mode this would hang. The other callsite of finish_fb is from intel_crtc_disable. btw, some slight digging around with git blame gives you in both cases the commits and comments that explain this all ;-) Cheers, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31708] [RADEON:KMS:TTM] kernel oops when loading large images with firefox
https://bugs.freedesktop.org/show_bug.cgi?id=31708 --- Comment #17 from Reiner 2012-09-14 15:42:47 UTC --- Created attachment 67172 --> https://bugs.freedesktop.org/attachment.cgi?id=67172 kern.log NULL pointer dereference bug Thanks Michel. Here is kern.log re the bug that occurred when loading the large image in Firefox. I have since had a slightly different kind of Oops, also while using Firefox, for which I provide a separate attachment. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [pull] drm-intel-next
On Fri, Sep 14, 2012 at 09:55:58AM -0400, Bobby Powers wrote: > This tree gives me recursive dependency problems, which ends up > removing a big (& important) part of my .config: > > [bpowers@fina linux]$ git reset --hard drm-intel-next-2012-09-09 > HEAD is now at e04190e drm/fb helper: don't call > drm_helper_connector_dpms directly > [bpowers@fina linux]$ git status > # On branch master > # Your branch and 'origin/master' have diverged, > # and have 207 and 323 different commits each, respectively. > # > nothing to commit (working directory clean) > [bpowers@fina linux]$ make oldconfig > scripts/kconfig/conf --oldconfig Kconfig > drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected! > drivers/gpu/drm/udl/Kconfig:1:symbol DRM_UDL depends on > USB_ARCH_HAS_HCD > drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT > drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB > drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL > # > # configuration written to .config > # That's an issue with Dave Airlie's udl code I'd say - the drm-intel-next tree here simply includes a few drm-next patches already. Dave? -Daniel > > > I've attached my config & the diff between what is attached and the > result of make oldconfig. Let me know if there is any other info that > would help, or if I'm just doing something boneheaded. Thanks! > > yours, > Bobby > > On Thu, Sep 13, 2012 at 10:18 AM, Daniel Vetter wrote: > > Hi Dave, > > > > The big ticket item here is the new i915 modeset infrastructure. > > Shockingly it didn't not blow up all over the place (i.e. I've managed to > > fix the ugly issues before merging). 1-2 smaller corner cases broke, but > > we have patches. Also, there's tons of patches on top of this that clean > > out cruft and fix a few bugs that couldn't be fixed with the crtc helper > > based stuff. So more stuff to come ;-) > > > > Also a few other things: > > - Tiny fix in the fb helper to go through the official dpms interface > > instead of calling the crtc helper code. > > - forcewake code frobbery from Ben, code should be more in-line with > > what Windows does now. > > - fixes for the render ring flush on hsw (Paulo) > > - gpu frequency tracepoint > > - vlv forcewake changes to better align it with our understanding of the > > forcewake magic. > > - a few smaller cleanups > > > > Cheers, Daniel > > > > > > The following changes since commit d7c3b937bdf45f0b844400b7bf6fd3ed50bac604: > > > > drm/i915: Remove __GFP_NO_KSWAPD (2012-08-27 17:11:38 +0200) > > > > are available in the git repository at: > > > > git://people.freedesktop.org/~danvet/drm-intel > > tags/drm-intel-next-2012-09-09 > > > > for you to fetch changes up to e04190e0ecb236c51af181c18c545ea076fb9cca: > > > > drm/fb helper: don't call drm_helper_connector_dpms directly (2012-09-08 > > 00:51:15 +0200) > > > > > > > > Ben Widawsky (5): > > drm/i915: Extract forcewake ack timeout > > drm/i915: use cpu_relax() in wait_for_atomic > > drm/i915: Change forcewake timeout to 2ms > > drm/i915: Never read FORCEWAKE > > drm/i915: Enable some sysfs stuff without CONFIG_PM > > > > Chris Wilson (1): > > drm/i915: Convert remaining debugfs iterators over rings to > > for_each_ring() > > > > Daniel Vetter (66): > > drm/ips: move drps/ips/ilk related variables into dev_priv->ips > > drm/i915: add a tracepoint for gpu frequency changes > > drm/i915: align vlv forcewake with common lore > > drm/i915: differ error message between forcwake timeouts > > drm/i915: add crtc->enable/disable vfuncs insted of dpms > > drm/i915: rip out crtc prepare/commit indirection > > drm/i915: add direct encoder disable/enable infrastructure > > drm/i915/hdmi: convert to encoder->disable/enable > > drm/i915/tv: convert to encoder enable/disable > > drm/i915/lvds: convert to encoder disable/enable > > drm/i915/dp: convert to encoder disable/enable > > drm/i915/crt: convert to encoder disable/enable > > drm/i915/sdvo: convert to encoder disable/enable > > drm/i915/dvo: convert to encoder disable/enable > > drm/i915: convert dpms functions of dvo/sdvo/crt > > drm/i915: rip out encoder->disable/enable checks > > drm/i915: clean up encoder_prepare/commit > > drm/i915: copy&paste drm_crtc_helper_set_config > > drm/i915: call set_base directly > > drm/i915: inline intel_best_encoder > > drm/i915: copy&paste drm_crtc_helper_set_mode > > drm/i915: simplify intel_crtc_prepare_encoders > > drm/i915: rip out encoder->prepare/commit > > drm/i915: call crtc functions directly > > drm/i915: WARN when trying to enabled an unused crtc > > drm/i915: Add interfaces to read out encoder/connector hw state > > drm/i915/dp: implement get_hw_
[Bug 31708] [RADEON:KMS:TTM] kernel oops when loading large images with firefox
https://bugs.freedesktop.org/show_bug.cgi?id=31708 --- Comment #18 from Reiner 2012-09-14 15:48:27 UTC --- Created attachment 67175 --> https://bugs.freedesktop.org/attachment.cgi?id=67175 kern.log unable to handle kernel paging request bug This Oops occurred also while Firefox was rendering something, but am unsure of what exactly it was on the page that caused the crash since it was a fairly complex web site. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote: > On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä > wrote: > > On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote: > >> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä > >> wrote: > >> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: > >> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä > >> >> wrote: > >> >> > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote: > >> >> >> On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrjälä > >> >> >> wrote: > >> [snip] > >> >> >> > > >> >> >> > I would say this is going to be the most common use case if you > >> >> >> > consider > >> >> >> > just the number of shipping devices. It's pretty much what every > >> >> >> > Android > >> >> >> > phone/tablet with a HDMI port has to do. > >> >> >> > >> >> >> bleh, surfaceflinger kinda sucks then.. > >> >> > > >> >> > Why? This use case is not enforced by surfaceflinger, it's just the > >> >> > use > >> >> > case most devices would have. > >> >> > > >> >> > I don't think there's anything wrong with the way surfaceflinger is > >> >> > designed > >> >> > with the prepare and commit phases. How else would you do it? > >> >> > >> >> well, maybe I misunderstood how surfaceflinger works, but it sounded > >> >> like it has one prepare/commit phase across outputs, vs what weston > >> >> compositor does where each output is rendered and flipped > >> >> independently at the rate of that particular output. If the two > >> >> outputs just happen to be vsync aligned, you would end up flipping at > >> >> the same time, but if the are not locked you don't have any artificial > >> >> constraint in the rendering/flipping. > >> > > >> > OK so it's purely a pull based model, whereas surfaceflinger is more > >> > push based. > >> > > >> > I suppose it might be possible to make surfaceflinger support a pull > >> > model by driving the compositor loop through a combined signal from > >> > multiple outputs. But IIRC it did have some timing related code in > >> > there somewhere, so it might not be happy about it. It might also > >> > >> As I understood, at least in older versions android versions, > >> rendering was based on a timer as there was no vblank event to > >> userspace on most SoC platforms (which sounds strange, but so far most > >> SoC's are using fbdev and/or crazy hacks rather than drm/kms) > >> > >> not sure if the timer is still there.. but I hope it goes away, it is > >> really a horrible way to keep track of vsync > > > > I've only looked at ICS in any detail. At least there we used the page > > flip event from one display to set the pace of the compositor loop. > > IIRC JB is supposed to have some vsync related changes, but I haven't > > looked at the code. > > > >> > affect the clients' rendering speed since the compositor would be > >> > pulling their buffers from queue at non-constant speed. I don't > >> > remember the details of the buffer management very well, so I can't be > >> > sure though. But I probably wouldn't bother trying this, since the > >> > straightforward approach is so simple, and the results are reasonably > >> > good. > >> > > >> > The pull model does seem more flexible. But it does require a bit of > >> > extra complexity in the compositor to avoid compositing the same scene > >> > multiple times needlessly when multiple cloned displays are involved. > >> > I suppose ideally you'd want to recompose for each display to minimize > >> > visible latency, but from power usage POV it may not be a good idea. > >> > >> fwiw, weston is already being pretty clever about keeping track of > >> damage and minimizing the area of the screen that must be re-rendered. > >> I'm not sure if SF does anything like this. > > > > IIRC it can do that, but the EGL implementation needs to support > > EGL_BUFFER_PRESERVED. > > > > I suppose the best way to implement EGL_BUFFER_PRESERVED with > > page flips would be to schedule the flip and immediately perform > > a blit from the new front buffer to the new back buffer. Well, > > unless the hardware has some more clever mechanism for it. > > > > Does weston depend on preserved flips too, or can it even track > > damage independently for each buffer? > > well, weston knows how many buffers are at play. So it takes the > union of the damage from the last time the buffer was used (well, > currently it assumes only double buffered) and the new damage. With more buffer it'll get a bit more complicate as it needs to keep accumulating the damage for all buffers. But it should still be fairly trivial when you're in full control of the buffers. > This > way it avoids need for the gl driver, which doesn't know as well what > is going on as the app, from needing to do a back-blit. It can do > this because w/ drm/gbm egl winsys, eglSwapBuffers() doesn't actually > swap the buffers on the display and weston is in charge of which > buffer is displayed or rendered. Weston explicitly calls page flip > ioctl. T
[Bug 54767] [r300g] 298 failures on WebGL Conformance Test
https://bugs.freedesktop.org/show_bug.cgi?id=54767 --- Comment #3 from Marek Olšák 2012-09-14 15:51:21 UTC --- r300 cannot pass some of the tests, because the hardware is too limited (some features cannot be implemented on r300), while other features may produce slightly different results due to precision issues. Some tests are simply unfixable. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP
On Fri, Sep 14, 2012 at 05:39:30PM +0200, Daniel Vetter wrote: > On Fri, Sep 14, 2012 at 5:30 PM, Ville Syrjälä > wrote: > > intel_pipe_set_base() won't disable the pipe or change the size, > > it'll just flip the primary plane. So that doesn't quite explain > > why the call is there, as opposed to being called just from the > > full modeset path. > > intel_pipe_set_base is also called in the modeset case, i.e. when we > could potentially change the height of the mode. And if we wait on a > large enough scanline which doesn't exist in the new mode this would > hang. Yes, I know it's called in both cases. But my point is that there doesn't seem to be any reason to call it in the pure set_base case. > The other callsite of finish_fb is from intel_crtc_disable. Yep. There it does make sense to me. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP
On Fri, 14 Sep 2012 18:30:21 +0300, Ville Syrjälä
wrote:
> On Fri, Sep 14, 2012 at 03:27:05PM +0100, Chris Wilson wrote:
> > On Fri, 14 Sep 2012 17:21:30 +0300, Ville Syrjälä
> > wrote:
> > > On Fri, Sep 14, 2012 at 02:57:26PM +0100, Chris Wilson wrote:
> > > > On Wed, 12 Sep 2012 18:47:07 +0300, ville.syrj...@linux.intel.com wrote:
> > > > > +static void intel_flip_finish(struct drm_flip *flip)
> > > > > +{
> > > > > + struct intel_flip *intel_flip =
> > > > > + container_of(flip, struct intel_flip, base);
> > > > > + struct drm_device *dev = intel_flip->crtc->dev;
> > > > > +
> > > > > + if (intel_flip->old_bo) {
> > > > > + mutex_lock(&dev->struct_mutex);
> > > > > +
> > > > > + intel_finish_fb(intel_flip->old_bo);
> > > >
> > > > So if I understand correctly, this code is called after the flip is
> > > > already complete?
> > >
> > > Yes.
> > >
> > > > The intel_finish_fb() exists to flush pending batches and flips on the
> > > > current fb, prior to changing the scanout registers. (There is a
> > > > hardware dependency such that the GPU may be executing a command that
> > > > required the current modesetting.) In the case of flip completion, all
> > > > of those dependencies have already been retired and so the finish should
> > > > be a no-op. And so it should no be required, nor the changes to
> > > > intel_finish_fb (which should have included a change in the name to
> > > > indicate that is now taking the fb_obj).
> > >
> > > Actually I'm not quite sure where this intel_finish_fb() call originated.
> > > Based on the name it didn't make sense to me, but I left it there for
> > > now. Hmm. OK it came from one patch from Imre while I was on vacation.
> > > I suppose he got it from intel_pipe_set_base() which does call
> > > intel_finish_fb() on the old fb. Why does it do that?
> >
> > It all boils down to the modeset being asynchronous to the GPU
> > processing the command stream. So we may be currently processing a batch
> > that is waiting on the pipe to go past a particular scanline, and if the
> > modesetting were to disable that pipe, or to change its size, then we
> > risk the WAIT_FOR_EVENT never completing - leading to hangcheck
> > detecting the frozen display and an angry user.
>
> intel_pipe_set_base() won't disable the pipe or change the size,
> it'll just flip the primary plane. So that doesn't quite explain
> why the call is there, as opposed to being called just from the
> full modeset path.
Hmm, at the time it was a convenient point. Now, it is clearly called too
late in the modeset sequence. Daniel, fix please. :)
> Also wouldn't any batch buffer with WAIT_FOR_EVENT be in risk of
> stalling, not just ones related to the old fb?
>
> > The other aspect is to synchronize the modeset with any outstanding
> > pageflips.
>
> Right, that does make sense. But doing it from a function called
> intel_finish_fb() is a bit confusing, as the condition really
> shouldn't depend on any specific fb object. But I suppose this is
> just a result of the "only one outstanding flip" policy.
Again, a nice convenient point, calling it an intel_crtc_wait_*() would
probably help (after fixing the ordering).
> BTW regarding this WAIT_FOR_EVENT thing. I got the impression that
> the scanline window wait doesn't work on recent hardware generations
> any more. Is that true? I was thinking that perhaps I could use it
> along with the load register command to perform the flips through
> the command queue.
That impression is pretty accurate. There is a suggestion that some form
of scanline wait was restored for IVB, but driving it seems pretty hit
and miss. Atomic flipping should all be possible with MI_DISPLAY_FLIP,
so presumably you are mostly thinking about atomic modeset? Is the
presumption that it will be an infrequent request and so better to keep
as simple as possible?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP
On Fri, Sep 14, 2012 at 04:56:00PM +0100, Chris Wilson wrote:
> On Fri, 14 Sep 2012 18:30:21 +0300, Ville Syrjälä
> wrote:
> > On Fri, Sep 14, 2012 at 03:27:05PM +0100, Chris Wilson wrote:
> > > On Fri, 14 Sep 2012 17:21:30 +0300, Ville Syrjälä
> > > wrote:
> > > > On Fri, Sep 14, 2012 at 02:57:26PM +0100, Chris Wilson wrote:
> > > > > On Wed, 12 Sep 2012 18:47:07 +0300, ville.syrj...@linux.intel.com
> > > > > wrote:
> > > > > > +static void intel_flip_finish(struct drm_flip *flip)
> > > > > > +{
> > > > > > + struct intel_flip *intel_flip =
> > > > > > + container_of(flip, struct intel_flip, base);
> > > > > > + struct drm_device *dev = intel_flip->crtc->dev;
> > > > > > +
> > > > > > + if (intel_flip->old_bo) {
> > > > > > + mutex_lock(&dev->struct_mutex);
> > > > > > +
> > > > > > + intel_finish_fb(intel_flip->old_bo);
> > > > >
> > > > > So if I understand correctly, this code is called after the flip is
> > > > > already complete?
> > > >
> > > > Yes.
> > > >
> > > > > The intel_finish_fb() exists to flush pending batches and flips on the
> > > > > current fb, prior to changing the scanout registers. (There is a
> > > > > hardware dependency such that the GPU may be executing a command that
> > > > > required the current modesetting.) In the case of flip completion, all
> > > > > of those dependencies have already been retired and so the finish
> > > > > should
> > > > > be a no-op. And so it should no be required, nor the changes to
> > > > > intel_finish_fb (which should have included a change in the name to
> > > > > indicate that is now taking the fb_obj).
> > > >
> > > > Actually I'm not quite sure where this intel_finish_fb() call
> > > > originated.
> > > > Based on the name it didn't make sense to me, but I left it there for
> > > > now. Hmm. OK it came from one patch from Imre while I was on vacation.
> > > > I suppose he got it from intel_pipe_set_base() which does call
> > > > intel_finish_fb() on the old fb. Why does it do that?
> > >
> > > It all boils down to the modeset being asynchronous to the GPU
> > > processing the command stream. So we may be currently processing a batch
> > > that is waiting on the pipe to go past a particular scanline, and if the
> > > modesetting were to disable that pipe, or to change its size, then we
> > > risk the WAIT_FOR_EVENT never completing - leading to hangcheck
> > > detecting the frozen display and an angry user.
> >
> > intel_pipe_set_base() won't disable the pipe or change the size,
> > it'll just flip the primary plane. So that doesn't quite explain
> > why the call is there, as opposed to being called just from the
> > full modeset path.
>
> Hmm, at the time it was a convenient point. Now, it is clearly called too
> late in the modeset sequence. Daniel, fix please. :)
>
> > Also wouldn't any batch buffer with WAIT_FOR_EVENT be in risk of
> > stalling, not just ones related to the old fb?
> >
> > > The other aspect is to synchronize the modeset with any outstanding
> > > pageflips.
> >
> > Right, that does make sense. But doing it from a function called
> > intel_finish_fb() is a bit confusing, as the condition really
> > shouldn't depend on any specific fb object. But I suppose this is
> > just a result of the "only one outstanding flip" policy.
>
> Again, a nice convenient point, calling it an intel_crtc_wait_*() would
> probably help (after fixing the ordering).
>
> > BTW regarding this WAIT_FOR_EVENT thing. I got the impression that
> > the scanline window wait doesn't work on recent hardware generations
> > any more. Is that true? I was thinking that perhaps I could use it
> > along with the load register command to perform the flips through
> > the command queue.
>
> That impression is pretty accurate. There is a suggestion that some form
> of scanline wait was restored for IVB, but driving it seems pretty hit
> and miss. Atomic flipping should all be possible with MI_DISPLAY_FLIP,
> so presumably you are mostly thinking about atomic modeset? Is the
> presumption that it will be an infrequent request and so better to keep
> as simple as possible?
MI_DISPLAY_FLIP is _very_ limited. You can't really do anything
interesting with. Sure it's enough to flip the buffers of some game
or whatever, but it's practically useless for hardware composition
type stuff.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Don't register backlight when max PWM value is unknown
On Fri, Sep 14, 2012 at 04:34:28PM +0100, Grant Likely wrote:
> When a backlight isn't connected to the i915 it doesn't make any sense
> to register the backlight device, but the driver currently tries to limp
> along using a max brightness value of 1. Instead, this patch makes it so
> that if the maximum PWM value cannot be determined, then the backlight
> will not be registered.
>
> Tested on MacbookPro8,3.
>
> Signed-off-by: Grant Likely
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Matthew Garrett
> Cc: David Woodhouse
I've already merged a rather similar patch from Jani Nikula
commit 28dcc2d60cb570d9f549c329b2f51400553412a1
Author: Jani Nikula
Date: Mon Sep 3 16:25:12 2012 +0300
drm/i915: do not expose a dysfunctional backlight interface to
userspace
Should land in 3.6 rsn.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_panel.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 3df4f5f..f410c6e 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -168,13 +168,8 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
> u32 max;
>
> max = i915_read_blc_pwm_ctl(dev_priv);
> - if (max == 0) {
> - /* XXX add code here to query mode clock or hardware clock
> - * and program max PWM appropriately.
> - */
> - pr_warn_once("fixme: max PWM is zero\n");
> - return 1;
> - }
> + if (max == 0)
> + return 0; /* Cannot read max PWM. Assume no backlight */
>
> if (HAS_PCH_SPLIT(dev)) {
> max >>= 16;
> @@ -413,6 +408,12 @@ int intel_panel_setup_backlight(struct drm_device *dev)
> struct backlight_properties props;
> struct drm_connector *connector;
>
> + /* Is there a backlight present? max will be zero if not */
> + if (intel_panel_get_max_backlight(dev) == 0) {
> + DRM_INFO("i915 doesn't seem to be connected to backlight\n");
> + return 0;
> + }
> +
> intel_panel_init_backlight(dev);
>
> if (dev_priv->int_lvds_connector)
> --
> 1.7.9.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 10:48 AM, Ville Syrjälä wrote: > On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote: >> On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä >> wrote: >> > On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote: >> >> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä >> >> wrote: >> >> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: >> >> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä >> >> >> wrote: >> >> >> > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote: >> >> >> >> On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrjälä >> >> >> >> wrote: >> >> [snip] >> >> >> >> > >> >> >> >> > I would say this is going to be the most common use case if you >> >> >> >> > consider >> >> >> >> > just the number of shipping devices. It's pretty much what every >> >> >> >> > Android >> >> >> >> > phone/tablet with a HDMI port has to do. >> >> >> >> >> >> >> >> bleh, surfaceflinger kinda sucks then.. >> >> >> > >> >> >> > Why? This use case is not enforced by surfaceflinger, it's just the >> >> >> > use >> >> >> > case most devices would have. >> >> >> > >> >> >> > I don't think there's anything wrong with the way surfaceflinger is >> >> >> > designed >> >> >> > with the prepare and commit phases. How else would you do it? >> >> >> >> >> >> well, maybe I misunderstood how surfaceflinger works, but it sounded >> >> >> like it has one prepare/commit phase across outputs, vs what weston >> >> >> compositor does where each output is rendered and flipped >> >> >> independently at the rate of that particular output. If the two >> >> >> outputs just happen to be vsync aligned, you would end up flipping at >> >> >> the same time, but if the are not locked you don't have any artificial >> >> >> constraint in the rendering/flipping. >> >> > >> >> > OK so it's purely a pull based model, whereas surfaceflinger is more >> >> > push based. >> >> > >> >> > I suppose it might be possible to make surfaceflinger support a pull >> >> > model by driving the compositor loop through a combined signal from >> >> > multiple outputs. But IIRC it did have some timing related code in >> >> > there somewhere, so it might not be happy about it. It might also >> >> >> >> As I understood, at least in older versions android versions, >> >> rendering was based on a timer as there was no vblank event to >> >> userspace on most SoC platforms (which sounds strange, but so far most >> >> SoC's are using fbdev and/or crazy hacks rather than drm/kms) >> >> >> >> not sure if the timer is still there.. but I hope it goes away, it is >> >> really a horrible way to keep track of vsync >> > >> > I've only looked at ICS in any detail. At least there we used the page >> > flip event from one display to set the pace of the compositor loop. >> > IIRC JB is supposed to have some vsync related changes, but I haven't >> > looked at the code. >> > >> >> > affect the clients' rendering speed since the compositor would be >> >> > pulling their buffers from queue at non-constant speed. I don't >> >> > remember the details of the buffer management very well, so I can't be >> >> > sure though. But I probably wouldn't bother trying this, since the >> >> > straightforward approach is so simple, and the results are reasonably >> >> > good. >> >> > >> >> > The pull model does seem more flexible. But it does require a bit of >> >> > extra complexity in the compositor to avoid compositing the same scene >> >> > multiple times needlessly when multiple cloned displays are involved. >> >> > I suppose ideally you'd want to recompose for each display to minimize >> >> > visible latency, but from power usage POV it may not be a good idea. >> >> >> >> fwiw, weston is already being pretty clever about keeping track of >> >> damage and minimizing the area of the screen that must be re-rendered. >> >> I'm not sure if SF does anything like this. >> > >> > IIRC it can do that, but the EGL implementation needs to support >> > EGL_BUFFER_PRESERVED. >> > >> > I suppose the best way to implement EGL_BUFFER_PRESERVED with >> > page flips would be to schedule the flip and immediately perform >> > a blit from the new front buffer to the new back buffer. Well, >> > unless the hardware has some more clever mechanism for it. >> > >> > Does weston depend on preserved flips too, or can it even track >> > damage independently for each buffer? >> >> well, weston knows how many buffers are at play. So it takes the >> union of the damage from the last time the buffer was used (well, >> currently it assumes only double buffered) and the new damage. > > With more buffer it'll get a bit more complicate as it needs to keep > accumulating the damage for all buffers. But it should still be fairly > trivial when you're in full control of the buffers. well, just track previous damage per buffer.. but yeah, slightly more complicated >> This >> way it avoids need for the gl driver, which doesn't know as well what >> is going on as the app, from needing to do a back
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 11:29:04AM -0500, Rob Clark wrote: > On Fri, Sep 14, 2012 at 10:48 AM, Ville Syrjälä > wrote: > > On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote: > >> On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä > >> wrote: > >> > On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote: > >> >> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä > >> >> wrote: > >> >> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: > >> >> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä > >> >> >> wrote: > >> >> >> > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote: > > I wonder if you've though about omap's FIFO merge. It can cause similar > > issues, that is some operations may need two vblanks to complete. And it > > looks like I'll get to worry about this stuff too since there are some > > watermark related wait_for_vblank() workarounds in the IVB sprite code, > > sigh. > > yeah, FIFO merge is a nice big headache.. and not really ideal for > latency unless you have some advanced warning to disable FIFO merge > before userspace wants to switch on an extra overlay. > > I think the best way to deal is just start switching off FIFO merge > when userspace first does test w/ overlay, but return EBUSY. It means > we'll use the gpu for rendering for one frame, but I think that is > better than blocking the compositor for a vblank or two. Thou shalt > not block the compositor. Yeah, I suppose it could be handled through another property as well. Perhaps some kind of "LOW_POWER_OPTIMIZATIONS" property that you'd disable one vblank in advance. But then it's starting to be a bit hardware specific ie. you more or less have to know the circumstances when the property must be disabled. On omap it would be when more than one plane is used, on IVB it appears that you need it when you want to enable scaling. I'm not too thrilled about the idea that the test phase would actually touch the hardware. What happens if you do multiple test steps between commits? But I can't immediately think of a good solution that would avoid the need for hardware specific knowledge. > >> And if we do support multiple crtc's w/ pageflip, I'm not sure if > >> there is a good way to enforce two-steps. Having a standardized way > >> to tell userspace to try later seems like a good thing. > > > > Sure, for that it seems reasonable. > > > >> >> >> >> Also, if you pageflip on multiple CRTC's, should the be multiple > >> >> >> >> vblank events, and multiple userdata's? > >> >> >> > > >> >> >> > That's a bit of an open question. I was considering several > >> >> >> > options: > >> >> >> > >> >> >> the thing I like about one ioctl per crtc is that it avoids this > >> >> >> whole > >> >> >> question.. > >> >> >> > >> >> >> And, I think as long as you have to update multiple different scanout > >> >> >> address registers, there is always going to be a race in multi-crtc > >> >> >> flipping. Having a single ioctl does make the race smaller. I'm not > >> >> >> sure how important that point is. > >> >> > > >> >> > Which race? > >> >> > >> >> ie. if you set REG_CRTC1_ADDR just immediately before vblank and > >> >> REG_CRTC2_ADDR just after > >> > > >> > Well, with unsynced crtcs I wouldn't call that any kind of meaningful > >> > race. > >> > The same problem after all exists even with a single crtc. You either > >> > make > >> > the deadline and write the register before vblank, or you don't make it > >> > and end up with a repeated frame. > >> > >> I meant w/ sync'd crtc's, there is still no 100% guarantee that the > >> two flip at the same time. > > > > Sure there is. That's what the vblank evade stuff gives you. I just > > happen to need it even when using just one crtc because the hardware > > doesn't have the necessary mechanism to flip several planes atomically. > > hmm, I guess I don't quite follow then. But I guess I don't know the > intel hw well enough. It seemed like you weren't atomically updating > scanout registers. I guarantee the atomicity by making sure I'm not too close to the start of vblank when I write the registers. It's a very generic solution that will work on any hardware with double buffered registers that get flipped on vblank. Even if some of the registers would get flipped at slightly different times (eg. plane A flips at vbl_start+1, plane B at vbl_start+10) you could still use this method by extending the range of scanlines to be avoided. I suppose the most difficult bit is determining how long you need to write all the necessary registers. You want to make it long enough to guarantee atomic operation, but short enough to avoid blocking needlessly. Currently I just have a hardcoded number there. If the driver is going to be deployed on a specific device, it's easy enough to measure it and tweak the number, but it would be nice to have the driver calibrate itself. Or you just have a sysfs knob so that it could tweaked more easily for specific systems by non-developers. > But an
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 12:02 PM, Ville Syrjälä wrote: > On Fri, Sep 14, 2012 at 11:29:04AM -0500, Rob Clark wrote: >> On Fri, Sep 14, 2012 at 10:48 AM, Ville Syrjälä >> wrote: >> > On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote: >> >> On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä >> >> wrote: >> >> > On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote: >> >> >> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä >> >> >> wrote: >> >> >> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: >> >> >> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä >> >> >> >> wrote: >> >> >> >> > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote: > >> > I wonder if you've though about omap's FIFO merge. It can cause similar >> > issues, that is some operations may need two vblanks to complete. And it >> > looks like I'll get to worry about this stuff too since there are some >> > watermark related wait_for_vblank() workarounds in the IVB sprite code, >> > sigh. >> >> yeah, FIFO merge is a nice big headache.. and not really ideal for >> latency unless you have some advanced warning to disable FIFO merge >> before userspace wants to switch on an extra overlay. >> >> I think the best way to deal is just start switching off FIFO merge >> when userspace first does test w/ overlay, but return EBUSY. It means >> we'll use the gpu for rendering for one frame, but I think that is >> better than blocking the compositor for a vblank or two. Thou shalt >> not block the compositor. > > Yeah, I suppose it could be handled through another property as well. > Perhaps some kind of "LOW_POWER_OPTIMIZATIONS" property that you'd > disable one vblank in advance. But then it's starting to be a bit > hardware specific ie. you more or less have to know the circumstances > when the property must be disabled. On omap it would be when more than > one plane is used, on IVB it appears that you need it when you want to > enable scaling. > > I'm not too thrilled about the idea that the test phase would actually > touch the hardware. What happens if you do multiple test steps between > commits? But I can't immediately think of a good solution that would > avoid the need for hardware specific knowledge. yeah, that is the problem.. But then again, I suppose we could make fifo-merge disabled by default and explicitly controlled by userspace via property. A generic userspace, and the property would never be set. A userspace a bit more optimized/customized for the hw, however, is in a better position to know if there is likely to be changes in the next frame (ie. based on user input, etc) and could make perhaps some more intelligent decisions about when to enable it. >> >> And if we do support multiple crtc's w/ pageflip, I'm not sure if >> >> there is a good way to enforce two-steps. Having a standardized way >> >> to tell userspace to try later seems like a good thing. >> > >> > Sure, for that it seems reasonable. >> > >> >> >> >> >> Also, if you pageflip on multiple CRTC's, should the be multiple >> >> >> >> >> vblank events, and multiple userdata's? >> >> >> >> > >> >> >> >> > That's a bit of an open question. I was considering several >> >> >> >> > options: >> >> >> >> >> >> >> >> the thing I like about one ioctl per crtc is that it avoids this >> >> >> >> whole >> >> >> >> question.. >> >> >> >> >> >> >> >> And, I think as long as you have to update multiple different >> >> >> >> scanout >> >> >> >> address registers, there is always going to be a race in multi-crtc >> >> >> >> flipping. Having a single ioctl does make the race smaller. I'm >> >> >> >> not >> >> >> >> sure how important that point is. >> >> >> > >> >> >> > Which race? >> >> >> >> >> >> ie. if you set REG_CRTC1_ADDR just immediately before vblank and >> >> >> REG_CRTC2_ADDR just after >> >> > >> >> > Well, with unsynced crtcs I wouldn't call that any kind of meaningful >> >> > race. >> >> > The same problem after all exists even with a single crtc. You either >> >> > make >> >> > the deadline and write the register before vblank, or you don't make it >> >> > and end up with a repeated frame. >> >> >> >> I meant w/ sync'd crtc's, there is still no 100% guarantee that the >> >> two flip at the same time. >> > >> > Sure there is. That's what the vblank evade stuff gives you. I just >> > happen to need it even when using just one crtc because the hardware >> > doesn't have the necessary mechanism to flip several planes atomically. >> >> hmm, I guess I don't quite follow then. But I guess I don't know the >> intel hw well enough. It seemed like you weren't atomically updating >> scanout registers. > > I guarantee the atomicity by making sure I'm not too close to the start > of vblank when I write the registers. It's a very generic solution that > will work on any hardware with double buffered registers that get > flipped on vblank. Even if some of the registers would get flipped at > slightly different times (eg. plane A flips at vbl_start+1
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 12:34:59PM -0500, Rob Clark wrote: > On Fri, Sep 14, 2012 at 12:02 PM, Ville Syrjälä > wrote: > > On Fri, Sep 14, 2012 at 11:29:04AM -0500, Rob Clark wrote: > >> On Fri, Sep 14, 2012 at 10:48 AM, Ville Syrjälä > >> wrote: > >> > On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote: > >> >> On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä > >> >> wrote: > >> >> > On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote: > >> >> >> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä > >> >> >> wrote: > >> >> >> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: > >> >> >> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä > >> >> >> >> wrote: > >> >> >> >> > That's a bit of an open question. I was considering several > >> >> >> >> > options: > >> >> >> >> > >> >> >> >> the thing I like about one ioctl per crtc is that it avoids this > >> >> >> >> whole > >> >> >> >> question.. > >> >> >> >> > >> >> >> >> And, I think as long as you have to update multiple different > >> >> >> >> scanout > >> >> >> >> address registers, there is always going to be a race in > >> >> >> >> multi-crtc > >> >> >> >> flipping. Having a single ioctl does make the race smaller. I'm > >> >> >> >> not > >> >> >> >> sure how important that point is. > >> >> >> > > >> >> >> > Which race? > >> >> >> > >> >> >> ie. if you set REG_CRTC1_ADDR just immediately before vblank and > >> >> >> REG_CRTC2_ADDR just after > >> >> > > >> >> > Well, with unsynced crtcs I wouldn't call that any kind of meaningful > >> >> > race. > >> >> > The same problem after all exists even with a single crtc. You either > >> >> > make > >> >> > the deadline and write the register before vblank, or you don't make > >> >> > it > >> >> > and end up with a repeated frame. > >> >> > >> >> I meant w/ sync'd crtc's, there is still no 100% guarantee that the > >> >> two flip at the same time. > >> > > >> > Sure there is. That's what the vblank evade stuff gives you. I just > >> > happen to need it even when using just one crtc because the hardware > >> > doesn't have the necessary mechanism to flip several planes atomically. > >> > >> hmm, I guess I don't quite follow then. But I guess I don't know the > >> intel hw well enough. It seemed like you weren't atomically updating > >> scanout registers. > > > > I guarantee the atomicity by making sure I'm not too close to the start > > of vblank when I write the registers. It's a very generic solution that > > will work on any hardware with double buffered registers that get > > flipped on vblank. Even if some of the registers would get flipped at > > slightly different times (eg. plane A flips at vbl_start+1, plane B at > > vbl_start+10) you could still use this method by extending the range of > > scanlines to be avoided. > > ahh, ok, double-buffered.. well, if they are double buffered you > should be able to tolerate two ioctl() calls, because you have a > relatively large window to update all the registers ;-) Hey, if "should" would be good enough, there would be no need for an atomic page flip ioctl. And somehwat ironically, if I didn't have double buffered registers, I'd just write the lot of them from the vblank irq handler, which would be simpler in some sense. Well, to tell the truth, not all registers in Intel HW are double buffered. Gamma tables/ramps for example are single buffered, and if we actually start to care about accurate color reproduction we may need to mix the two approaches. The other approach would be to reject changes to features backed by single buffered registers while the relevant piece of hardware is enabled. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [pull] drm-intel-next
Hi 2012/9/14 Daniel Vetter : > On Fri, Sep 14, 2012 at 09:55:58AM -0400, Bobby Powers wrote: >> This tree gives me recursive dependency problems, which ends up >> removing a big (& important) part of my .config: >> >> [bpowers@fina linux]$ git reset --hard drm-intel-next-2012-09-09 >> HEAD is now at e04190e drm/fb helper: don't call >> drm_helper_connector_dpms directly >> [bpowers@fina linux]$ git status >> # On branch master >> # Your branch and 'origin/master' have diverged, >> # and have 207 and 323 different commits each, respectively. >> # >> nothing to commit (working directory clean) >> [bpowers@fina linux]$ make oldconfig >> scripts/kconfig/conf --oldconfig Kconfig >> drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected! >> drivers/gpu/drm/udl/Kconfig:1:symbol DRM_UDL depends on >> USB_ARCH_HAS_HCD >> drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT >> drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB >> drivers/gpu/drm/Kconfig:22: symbol DRM_USB is selected by DRM_UDL >> # >> # configuration written to .config >> # > You want this: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=95ca19cf8cbf6163805dc9dc6a83f73b3e75ea13 > That's an issue with Dave Airlie's udl code I'd say - the drm-intel-next > tree here simply includes a few drm-next patches already. Dave? > -Daniel > >> >> >> I've attached my config & the diff between what is attached and the >> result of make oldconfig. Let me know if there is any other info that >> would help, or if I'm just doing something boneheaded. Thanks! >> >> yours, >> Bobby >> >> On Thu, Sep 13, 2012 at 10:18 AM, Daniel Vetter wrote: >> > Hi Dave, >> > >> > The big ticket item here is the new i915 modeset infrastructure. >> > Shockingly it didn't not blow up all over the place (i.e. I've managed to >> > fix the ugly issues before merging). 1-2 smaller corner cases broke, but >> > we have patches. Also, there's tons of patches on top of this that clean >> > out cruft and fix a few bugs that couldn't be fixed with the crtc helper >> > based stuff. So more stuff to come ;-) >> > >> > Also a few other things: >> > - Tiny fix in the fb helper to go through the official dpms interface >> > instead of calling the crtc helper code. >> > - forcewake code frobbery from Ben, code should be more in-line with >> > what Windows does now. >> > - fixes for the render ring flush on hsw (Paulo) >> > - gpu frequency tracepoint >> > - vlv forcewake changes to better align it with our understanding of the >> > forcewake magic. >> > - a few smaller cleanups >> > >> > Cheers, Daniel >> > >> > >> > The following changes since commit >> > d7c3b937bdf45f0b844400b7bf6fd3ed50bac604: >> > >> > drm/i915: Remove __GFP_NO_KSWAPD (2012-08-27 17:11:38 +0200) >> > >> > are available in the git repository at: >> > >> > git://people.freedesktop.org/~danvet/drm-intel >> > tags/drm-intel-next-2012-09-09 >> > >> > for you to fetch changes up to e04190e0ecb236c51af181c18c545ea076fb9cca: >> > >> > drm/fb helper: don't call drm_helper_connector_dpms directly (2012-09-08 >> > 00:51:15 +0200) >> > >> > >> > >> > Ben Widawsky (5): >> > drm/i915: Extract forcewake ack timeout >> > drm/i915: use cpu_relax() in wait_for_atomic >> > drm/i915: Change forcewake timeout to 2ms >> > drm/i915: Never read FORCEWAKE >> > drm/i915: Enable some sysfs stuff without CONFIG_PM >> > >> > Chris Wilson (1): >> > drm/i915: Convert remaining debugfs iterators over rings to >> > for_each_ring() >> > >> > Daniel Vetter (66): >> > drm/ips: move drps/ips/ilk related variables into dev_priv->ips >> > drm/i915: add a tracepoint for gpu frequency changes >> > drm/i915: align vlv forcewake with common lore >> > drm/i915: differ error message between forcwake timeouts >> > drm/i915: add crtc->enable/disable vfuncs insted of dpms >> > drm/i915: rip out crtc prepare/commit indirection >> > drm/i915: add direct encoder disable/enable infrastructure >> > drm/i915/hdmi: convert to encoder->disable/enable >> > drm/i915/tv: convert to encoder enable/disable >> > drm/i915/lvds: convert to encoder disable/enable >> > drm/i915/dp: convert to encoder disable/enable >> > drm/i915/crt: convert to encoder disable/enable >> > drm/i915/sdvo: convert to encoder disable/enable >> > drm/i915/dvo: convert to encoder disable/enable >> > drm/i915: convert dpms functions of dvo/sdvo/crt >> > drm/i915: rip out encoder->disable/enable checks >> > drm/i915: clean up encoder_prepare/commit >> > drm/i915: copy&paste drm_crtc_helper_set_config >> > drm/i915: call set_base directly >> > drm/i915: inline intel_best_encoder >> > drm/i915: copy&paste drm_crtc_helper_set_mode >> > drm/i915: simplify intel_crtc_prepare_encoders >> >
[PATCH] intel: Mark bo's exported to prime as not reusable
It's the same situation as flink and we need take the same pre-cautions.
---
intel/intel_bufmgr_gem.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3bcc849..92c0444 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int
*prime_fd)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+ int ret;
- return drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
DRM_CLOEXEC, prime_fd);
+ ret = drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
+DRM_CLOEXEC, prime_fd);
+ if (ret == 0)
+ bo_gem->reusable = false;
+
+ return ret;
}
static int
--
1.7.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] intel: Mark bo's exported to prime as not reusable
On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg
wrote:
> It's the same situation as flink and we need take the same pre-cautions.
> ---
> intel/intel_bufmgr_gem.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 3bcc849..92c0444 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int
> *prime_fd)
> {
> drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
> drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
> + int ret;
>
> - return drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
> DRM_CLOEXEC, prime_fd);
> + ret = drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
> + DRM_CLOEXEC, prime_fd);
> + if (ret == 0)
> + bo_gem->reusable = false;
Now that you mention it...
To be consistent with libdrm_intel, we should return -errno on error; so
rephrasing this as
if (ret)
return -errno;
bo_gem->reusable = false;
return 0;
would work better.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] intel: Mark bo's exported to prime as not reusable
On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson wrote:
> On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg
> wrote:
>> It's the same situation as flink and we need take the same pre-cautions.
>> ---
>> intel/intel_bufmgr_gem.c |8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
>> index 3bcc849..92c0444 100644
>> --- a/intel/intel_bufmgr_gem.c
>> +++ b/intel/intel_bufmgr_gem.c
>> @@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo,
>> int *prime_fd)
>> {
>> drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
>> drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
>> + int ret;
>>
>> - return drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
>> DRM_CLOEXEC, prime_fd);
>> + ret = drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
>> + DRM_CLOEXEC, prime_fd);
>> + if (ret == 0)
>> + bo_gem->reusable = false;
>
> Now that you mention it...
> To be consistent with libdrm_intel, we should return -errno on error; so
> rephrasing this as
> if (ret)
> return -errno;
>
> bo_gem->reusable = false;
> return 0;
>
> would work better.
Argh, yes, I copy and pasted that from drm_intel_gem_bo_flink() but
edited it away later... with that change, can I add your reviewed-by
and commit?
Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] intel: Mark bo's exported to prime as not reusable
On Fri, 14 Sep 2012 17:01:18 -0400, Kristian Høgsberg
wrote:
> On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson
> wrote:
> > On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg
> > wrote:
> >> It's the same situation as flink and we need take the same pre-cautions.
> >> ---
> >> intel/intel_bufmgr_gem.c |8 +++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> >> index 3bcc849..92c0444 100644
> >> --- a/intel/intel_bufmgr_gem.c
> >> +++ b/intel/intel_bufmgr_gem.c
> >> @@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo,
> >> int *prime_fd)
> >> {
> >> drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)
> >> bo->bufmgr;
> >> drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
> >> + int ret;
> >>
> >> - return drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
> >> DRM_CLOEXEC, prime_fd);
> >> + ret = drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
> >> + DRM_CLOEXEC, prime_fd);
> >> + if (ret == 0)
> >> + bo_gem->reusable = false;
> >
> > Now that you mention it...
> > To be consistent with libdrm_intel, we should return -errno on error; so
> > rephrasing this as
> > if (ret)
> > return -errno;
> >
> > bo_gem->reusable = false;
> > return 0;
> >
> > would work better.
>
> Argh, yes, I copy and pasted that from drm_intel_gem_bo_flink() but
> edited it away later... with that change, can I add your reviewed-by
> and commit?
Yes,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46241] Resume to black screen on AMD A8-3500m/Radeon 6620G
https://bugzilla.kernel.org/show_bug.cgi?id=46241 --- Comment #7 from Alex Deucher 2012-09-14 21:11:57 --- This should be fixed in my drm-next-3.7-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #9 from Alex Deucher 2012-09-04 13:07:53 UTC --- *** Bug 54484 has been marked as a duplicate of this bug. *** --- Comment #10 from Alex Deucher 2012-09-14 21:12:11 UTC --- This should be fixed in my drm-next-3.7-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Wed, 12 Sep 2012 21:58:31 +0300 Ville Syrjälä wrote: > On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote: > > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä > > wrote: > > > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote: > > >> But I think we could still do this w/ one ioctl per crtc for > > >> atomic-pageflip. > > > > > > We could, if we want to sacrifice the synced multi display case. I just > > > think it might be a real use case at some point. IVI feels like the most > > > likely short term cadidate to me, but perhaps someone would finally > > > introduce some new style phone/tablet thingy. I have seen > > > concepts/prototypes of such multi display gadgets in the past, but the > > > industry apparently got a bit stuck on the rectangular slab with > > > touchscreen on one side design. > > > > I could be wrong, but I think IVI the screens would normally be too > > far apart to matter? > > I was thinking of something like a display on the dash that normally > sits low with only a small sliver visible, and extends upwards when > you fire up a movie player for example. Internally it could be made > up of two displays for power savings purposes. > > > Anyways, it is really only a problem if you can't do two ioctl()s > > within one vblank period. If it actually turns out to be a real > > problem, > > Well exactly that's the problem this whole atomic pageflip stuff is > trying to tackle, no? ;) > > > we could always add later an ioctl that takes an array of > > 'struct drm_mode_crtc_atomic_page_flip's. I'm not sure if this is > > really useful or not.. but maybe I'm thinking too much about how > > weston does it's rendering of different output's independently. > > I'm just now thinking of surfaceflinger's way of doing things, with > its prepare and commit phases. If you need to issue two ioctls to handle > cloned displays, then you can end up in a somewhat funky situation. > > Let's say you have a video overlay in use (one each display naturally), > and you increase the downscaling factor enough so that you now have > enough memory bandwith to support only one overlay. With independent > check ioctls for each display, you never have the full device state > available in the kernel, so each check succeeds during the prepare > phase. So you decide that you can keep using the video overlays. > > You then proceed to commit the state, but after the first display has > been commited you get an error when trying to commit the second one. > What can you do now? The only option is to keep displaying the old > frame on the other displays for some time longer, and then on the > next frame you can switch to GPU composition. But on the next frame you > perhaps no longer need to use GPU composition, but since you can't > verify that in the prepare phase, you have no other option but to use > GPU composition. > > So when you run into a configuration that can be supported only > partially, you get animation stalls on some displays due to skipped > frames, and you always have to fall back to GPU composition for the > next frame. > > If on the other hand you would check the whole state in one ioctl, > you'd get the error in the first prepare phase, and could fall back > to GPU composition immediately. > > Am I too much of a perfectionst in considering such things? I don't > think so, but perhaps other people disagree. I don't think there's any harm in having multiple ioctls for different things. I was initially hoping the nuclear page flip would be very simple. Intended for simply updating buffers of several planes associated with a single display. That makes the inner loop of something like Wayland or SF simple, but obviously doesn't cover every case (in fact I had avoided dealing with moving planes initially). Rob's patchset goes further than that, but obviously not as far as you propose. OTOH, keeping things really simple and not very featureful means there are fewer points of failure, which is what I think callers would expect from a flip API... So where does that leave us? I'd propose we have a very simple, stripped down, single crtc flip ioctl, along with a big atomic mode set ioctl, and then perhaps a fancier multi-crtc flip ioctl. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 4:14 PM, Jesse Barnes wrote: > On Wed, 12 Sep 2012 21:58:31 +0300 > Ville Syrjälä wrote: > >> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote: >> > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä >> > wrote: >> > > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote: >> > >> But I think we could still do this w/ one ioctl per crtc for >> > >> atomic-pageflip. >> > > >> > > We could, if we want to sacrifice the synced multi display case. I just >> > > think it might be a real use case at some point. IVI feels like the most >> > > likely short term cadidate to me, but perhaps someone would finally >> > > introduce some new style phone/tablet thingy. I have seen >> > > concepts/prototypes of such multi display gadgets in the past, but the >> > > industry apparently got a bit stuck on the rectangular slab with >> > > touchscreen on one side design. >> > >> > I could be wrong, but I think IVI the screens would normally be too >> > far apart to matter? >> >> I was thinking of something like a display on the dash that normally >> sits low with only a small sliver visible, and extends upwards when >> you fire up a movie player for example. Internally it could be made >> up of two displays for power savings purposes. >> >> > Anyways, it is really only a problem if you can't do two ioctl()s >> > within one vblank period. If it actually turns out to be a real >> > problem, >> >> Well exactly that's the problem this whole atomic pageflip stuff is >> trying to tackle, no? ;) >> >> > we could always add later an ioctl that takes an array of >> > 'struct drm_mode_crtc_atomic_page_flip's. I'm not sure if this is >> > really useful or not.. but maybe I'm thinking too much about how >> > weston does it's rendering of different output's independently. >> >> I'm just now thinking of surfaceflinger's way of doing things, with >> its prepare and commit phases. If you need to issue two ioctls to handle >> cloned displays, then you can end up in a somewhat funky situation. >> >> Let's say you have a video overlay in use (one each display naturally), >> and you increase the downscaling factor enough so that you now have >> enough memory bandwith to support only one overlay. With independent >> check ioctls for each display, you never have the full device state >> available in the kernel, so each check succeeds during the prepare >> phase. So you decide that you can keep using the video overlays. >> >> You then proceed to commit the state, but after the first display has >> been commited you get an error when trying to commit the second one. >> What can you do now? The only option is to keep displaying the old >> frame on the other displays for some time longer, and then on the >> next frame you can switch to GPU composition. But on the next frame you >> perhaps no longer need to use GPU composition, but since you can't >> verify that in the prepare phase, you have no other option but to use >> GPU composition. >> >> So when you run into a configuration that can be supported only >> partially, you get animation stalls on some displays due to skipped >> frames, and you always have to fall back to GPU composition for the >> next frame. >> >> If on the other hand you would check the whole state in one ioctl, >> you'd get the error in the first prepare phase, and could fall back >> to GPU composition immediately. >> >> Am I too much of a perfectionst in considering such things? I don't >> think so, but perhaps other people disagree. > > I don't think there's any harm in having multiple ioctls for different > things. > > I was initially hoping the nuclear page flip would be very simple. > Intended for simply updating buffers of several planes associated with > a single display. That makes the inner loop of something like Wayland > or SF simple, but obviously doesn't cover every case (in fact I had > avoided dealing with moving planes initially). > > Rob's patchset goes further than that, but obviously not as far as you > propose. > > OTOH, keeping things really simple and not very featureful means there > are fewer points of failure, which is what I think callers would expect > from a flip API... > > So where does that leave us? I'd propose we have a very simple, > stripped down, single crtc flip ioctl, along with a big atomic mode set > ioctl, and then perhaps a fancier multi-crtc flip ioctl. well, I do think it is quite useful to be able to enable/disable planes as part as part of the flip.. you really don't want to have to block the compositor for a synchronous operation to enable/disable a plane.. even if you have to return -EBUSY for a transition (ie. if a plane is still pending vblank on other crtc to switch over, etc) I am on the fence about multi-crtc flip. Although the everything-is-a-property approach does, I suppose, means we could support it with one ioctl. Maybe we should start without. If later we want to support multi-crtc flip, we can add a driver cap to give userspac
Re: [RFC 0/9] nuclear pageflip
On Fri, Sep 14, 2012 at 1:23 PM, Ville Syrjälä wrote: > On Fri, Sep 14, 2012 at 12:34:59PM -0500, Rob Clark wrote: >> On Fri, Sep 14, 2012 at 12:02 PM, Ville Syrjälä >> wrote: >> > On Fri, Sep 14, 2012 at 11:29:04AM -0500, Rob Clark wrote: >> >> On Fri, Sep 14, 2012 at 10:48 AM, Ville Syrjälä >> >> wrote: >> >> > On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote: >> >> >> On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä >> >> >> wrote: >> >> >> > On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote: >> >> >> >> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä >> >> >> >> wrote: >> >> >> >> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: >> >> >> >> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä >> >> >> >> >> wrote: >> >> >> >> >> > That's a bit of an open question. I was considering several >> >> >> >> >> > options: >> >> >> >> >> >> >> >> >> >> the thing I like about one ioctl per crtc is that it avoids this >> >> >> >> >> whole >> >> >> >> >> question.. >> >> >> >> >> >> >> >> >> >> And, I think as long as you have to update multiple different >> >> >> >> >> scanout >> >> >> >> >> address registers, there is always going to be a race in >> >> >> >> >> multi-crtc >> >> >> >> >> flipping. Having a single ioctl does make the race smaller. >> >> >> >> >> I'm not >> >> >> >> >> sure how important that point is. >> >> >> >> > >> >> >> >> > Which race? >> >> >> >> >> >> >> >> ie. if you set REG_CRTC1_ADDR just immediately before vblank and >> >> >> >> REG_CRTC2_ADDR just after >> >> >> > >> >> >> > Well, with unsynced crtcs I wouldn't call that any kind of >> >> >> > meaningful race. >> >> >> > The same problem after all exists even with a single crtc. You >> >> >> > either make >> >> >> > the deadline and write the register before vblank, or you don't make >> >> >> > it >> >> >> > and end up with a repeated frame. >> >> >> >> >> >> I meant w/ sync'd crtc's, there is still no 100% guarantee that the >> >> >> two flip at the same time. >> >> > >> >> > Sure there is. That's what the vblank evade stuff gives you. I just >> >> > happen to need it even when using just one crtc because the hardware >> >> > doesn't have the necessary mechanism to flip several planes atomically. >> >> >> >> hmm, I guess I don't quite follow then. But I guess I don't know the >> >> intel hw well enough. It seemed like you weren't atomically updating >> >> scanout registers. >> > >> > I guarantee the atomicity by making sure I'm not too close to the start >> > of vblank when I write the registers. It's a very generic solution that >> > will work on any hardware with double buffered registers that get >> > flipped on vblank. Even if some of the registers would get flipped at >> > slightly different times (eg. plane A flips at vbl_start+1, plane B at >> > vbl_start+10) you could still use this method by extending the range of >> > scanlines to be avoided. >> >> ahh, ok, double-buffered.. well, if they are double buffered you >> should be able to tolerate two ioctl() calls, because you have a >> relatively large window to update all the registers ;-) > > Hey, if "should" would be good enough, there would be no need for an > atomic page flip ioctl. Well, true.. but there is a bit of a difference of scale.. I mean flipping multiple layers on a single CRTC that is not vblank sync'd with another CRTC should be a common case, and you can get incorrect results on the screen, so an "it *should* work" solution is less acceptable. vsync locked crtc's seem like it would be less common, and less likely to be noticed if once in a while the flip is off by a frame. So it seems like a less urgent issue to solve. Just playing devil's advocate here ;-) BR, -R > And somehwat ironically, if I didn't have double buffered registers, > I'd just write the lot of them from the vblank irq handler, which would > be simpler in some sense. Well, to tell the truth, not all registers in > Intel HW are double buffered. Gamma tables/ramps for example are single > buffered, and if we actually start to care about accurate color > reproduction we may need to mix the two approaches. The other approach > would be to reject changes to features backed by single buffered registers > while the relevant piece of hardware is enabled. > > -- > Ville Syrjälä > syrj...@sci.fi > http://www.sci.fi/~syrjala/ > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] SH Mobile DRM driver for v3.7
On Fri, 14 Sep 2012 15:05:44 +0200 Laurent Pinchart wrote: > Hi Alan, > > On Friday 14 September 2012 13:47:33 Alan Cox wrote: > > On Fri, 14 Sep 2012 14:38:10 +0200 Laurent Pinchart wrote: > > > Hi Dave, > > > > > > The SH Mobile DRM driver is now (in my opinion) ready for mainline. It > > > requires GEM and KMS/FB helpers that have been reviewed on the list and > > > tested. Sascha is waiting for them to reach your tree to send a pull > > > request for another new driver. > > > > > > The following changes since commit > 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > > > > > are available in the git repository at: > > > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc > > > > Wrong summary ?? > > The repository is oddly named because I've initially created it to hold fbdev > patches. The drm-lcdc branch contains DRM patches. Yeah but the only change in it is a gma500 change not an SH one ! > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] SH Mobile DRM driver for v3.7
Hi Alan, On Friday 14 September 2012 23:57:57 Alan Cox wrote: > On Fri, 14 Sep 2012 15:05:44 +0200 > > Laurent Pinchart wrote: > > Hi Alan, > > > > On Friday 14 September 2012 13:47:33 Alan Cox wrote: > > > On Fri, 14 Sep 2012 14:38:10 +0200 Laurent Pinchart wrote: > > > > Hi Dave, > > > > > > > > The SH Mobile DRM driver is now (in my opinion) ready for mainline. It > > > > requires GEM and KMS/FB helpers that have been reviewed on the list > > > > and tested. Sascha is waiting for them to reach your tree to send a > > > > pull request for another new driver. > > > > > > > > The following changes since commit > > > > 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > > > > > > > are available in the git repository at: > > > > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc > > > > > > Wrong summary ?? > > > > The repository is oddly named because I've initially created it to hold > > fbdev patches. The drm-lcdc branch contains DRM patches. > > Yeah but the only change in it is a gma500 change not an SH one ! I'll assume you need a cup of coffee ;-) Please reread the original mail, there are 4 changes *since* the gma500 commit. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] SH Mobile DRM driver for v3.7
On Fri, Sep 14, 2012 at 10:38 PM, Laurent Pinchart wrote: > Hi Dave, > > The SH Mobile DRM driver is now (in my opinion) ready for mainline. It > requires GEM and KMS/FB helpers that have been reviewed on the list and > tested. Sascha is waiting for them to reach your tree to send a pull request > for another new driver. Just a quick review before I pull, Why does include/drm/shmob_drm.h exist? this file is meant to define the userspace API to the driver, if you don't have any userspace API or driver specific ioctls, this file shouldn't be required. You might want to create include/drm/shmob_internal.h maybe, if this is used as an interface to other places in the kernel. I probably need to check other have been doing the right thing here as well. (driver_drm.h should be user facing only) Uggh drm_fb_cma_helper.c is pure midlayer mistake, are you 100% sure no driver is ever going to want to tweak the drm_fbdev_cma_ops? really? you are forcing the driver into a corner, drivers call into helpers, midlayers call into drivers or block them from being called. you should probably at least change it so the fb_ops are passed into drm_fbdev_cma_create. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] SH Mobile DRM driver for v3.7
Hi Dave, On Saturday 15 September 2012 09:28:14 Dave Airlie wrote: > On Fri, Sep 14, 2012 at 10:38 PM, Laurent Pinchart wrote: > > Hi Dave, > > > > The SH Mobile DRM driver is now (in my opinion) ready for mainline. It > > requires GEM and KMS/FB helpers that have been reviewed on the list and > > tested. Sascha is waiting for them to reach your tree to send a pull > > request for another new driver. > > Just a quick review before I pull, > > Why does include/drm/shmob_drm.h exist? this file is meant to define > the userspace API to the driver, if you don't have any userspace API > or driver specific ioctls, this file shouldn't be required. You might > want to create include/drm/shmob_internal.h maybe, if this is used as > an interface to other places in the kernel. I probably need to check > other have been doing the right thing here as well. (driver_drm.h > should be user facing only) The file contains platform data. I can move it to include/linux/platform_data/ > Uggh drm_fb_cma_helper.c is pure midlayer mistake, are you 100% sure > no driver is ever going to want to tweak the drm_fbdev_cma_ops? > really? you are forcing the driver into a corner, drivers call into > helpers, midlayers call into drivers or block them from being called. > you should probably at least change it so the fb_ops are passed into > drm_fbdev_cma_create. I'll let Lars answer that. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] nuclear pageflip
On Thu, Sep 13, 2012 at 11:35 AM, Rob Clark wrote: > note that the test phase doesn't need vblank events, and also > shouldn't -EBUSY if there is still a pending flip[*], so I'd propose > that however we go about pageflip (one super-ioctl, or one per crtc), > we could use the atomic-modeset ioctl for the test step actually, I think I take this back.. one thing that was discussed on IRC, but didn't make it to this email thread is the behavior of non-specified properties. What I am thinking: modeset: unspecified properties revert to default pageflip: unspecified properties preserve current value So I definitely do think there should be two ioctls, and that test for pageflip should go via atomic-pageflip ioctl to be consistent w/ the preserve-current-values approach. Instead I'll just move the is-there-a-pending-vblank to the top of atomic_commit() so it doesn't get in the way if you try to test for frame n+1 while waiting for vblank from frame n. BR. -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] intel: Mark bo's exported to prime as not reusable
On Fri, Sep 14, 2012 at 5:03 PM, Chris Wilson wrote:
> On Fri, 14 Sep 2012 17:01:18 -0400, Kristian Høgsberg
> wrote:
>> On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson
>> wrote:
>> > On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg
>> > wrote:
>> >> It's the same situation as flink and we need take the same pre-cautions.
>> >> ---
>> >> intel/intel_bufmgr_gem.c |8 +++-
>> >> 1 file changed, 7 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
>> >> index 3bcc849..92c0444 100644
>> >> --- a/intel/intel_bufmgr_gem.c
>> >> +++ b/intel/intel_bufmgr_gem.c
>> >> @@ -2472,8 +2472,14 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo,
>> >> int *prime_fd)
>> >> {
>> >> drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)
>> >> bo->bufmgr;
>> >> drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
>> >> + int ret;
>> >>
>> >> - return drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
>> >> DRM_CLOEXEC, prime_fd);
>> >> + ret = drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
>> >> + DRM_CLOEXEC, prime_fd);
>> >> + if (ret == 0)
>> >> + bo_gem->reusable = false;
>> >
>> > Now that you mention it...
>> > To be consistent with libdrm_intel, we should return -errno on error; so
>> > rephrasing this as
>> > if (ret)
>> > return -errno;
>> >
>> > bo_gem->reusable = false;
>> > return 0;
>> >
>> > would work better.
>>
>> Argh, yes, I copy and pasted that from drm_intel_gem_bo_flink() but
>> edited it away later... with that change, can I add your reviewed-by
>> and commit?
>
> Yes,
>
> Reviewed-by: Chris Wilson
> -Chris
Thanks, pushed. Btw, before this patch,
drm_intel_bo_gem_export_to_prime() was actually just returning the
drmPrimeHandleToFD() return value directly, not -errno on error.
Kristian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gma600: Enable HDMI support
On Thu, Sep 13, 2012 at 10:30 PM, Alan Cox wrote: > On Thu, 13 Sep 2012 11:38:20 +1000 > Dave Airlie wrote: > >> > There are still some mysteries left, in particular how (and in >> > fact if) the EDID is supposed to work on the HDMI port. However >> > the basic stuff now works and I can plug my Q550 into an HDMI >> > display and get the expected results. >> >> Assumning this is for -next, and its got whitespace damage, >> (checkpatch and git complain :-) > > It is indeed for -next. > > Whitespace damage of what kind, messed up space/tabbing or 'doesn't apply > eaten by mail system' ? just messed up spaces, trailing spaces/tabs, i.e. git am complains. Dave.
[PATCH V6] drm: edid: add support for E-DDC
On Fri, Sep 14, 2012 at 12:36 AM, Shirish S wrote: > Gentle Reminder! you are a day late, I pushed it into drm-next yesterday :-) Dave.
[PATCH] drm/nouveau: fix booting with plymouth + dumb support
From: Dave Airlie We noticed a plymouth bug on Fedora 18, and I then noticed this stupid thinko, fixing it fixed the problem with plymouth. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_display.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 69688ef..7e16dc5 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -598,7 +598,7 @@ nouveau_display_dumb_create(struct drm_file *file_priv, struct drm_device *dev, args->size = args->pitch * args->height; args->size = roundup(args->size, PAGE_SIZE); - ret = nouveau_gem_new(dev, args->size, 0, TTM_PL_FLAG_VRAM, 0, 0, &bo); + ret = nouveau_gem_new(dev, args->size, 0, NOUVEAU_GEM_DOMAIN_VRAM, 0, 0, &bo); if (ret) return ret; -- 1.7.10.2
[PATCH 1/4] drm/exynos: add pid to g2d_runqueue_node
this patch adds pid to g2d_runqueue_node as member to identify
which process owns this node.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 1065e90..dcbc4cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -122,6 +122,7 @@ struct g2d_runqueue_node {
struct list_headlist;
struct list_headrun_cmdlist;
struct list_headevent_list;
+ pid_t pid;
struct completion complete;
int async;
};
@@ -679,6 +680,7 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev, void
*data,
}
mutex_lock(&g2d->runqueue_mutex);
+ runqueue_node->pid = current->pid;
list_add_tail(&runqueue_node->list, &g2d->runqueue);
if (!g2d->runqueue_node)
g2d_exec_runqueue(g2d);
--
1.7.4.1
[PATCH 2/4] drm/exynos: fix duplicated mutex lock issue
exynos_drm_crtc_dpms function doesn't need mutex lock
because mutex lock was called by drm framework so this
patch removes mutex lock call from that function to avoid
duplicated mutex locking.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b612bf5..8bd4d7e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -66,7 +66,6 @@ struct exynos_drm_crtc {
static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
{
- struct drm_device *dev = crtc->dev;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);
@@ -76,12 +75,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
return;
}
- mutex_lock(&dev->struct_mutex);
-
exynos_drm_fn_encoder(crtc, &mode, exynos_drm_encoder_crtc_dpms);
exynos_crtc->dpms = mode;
-
- mutex_unlock(&dev->struct_mutex);
}
static void exynos_drm_crtc_prepare(struct drm_crtc *crtc)
--
1.7.4.1
[PATCH 4/4] drm/exynos: check crtc's dpms mode at SetCrtc
when fb changing is requested, crtc's dpms mode should be on.
if not on, return -EPERM so that the hardware can't be accessed.
if user requesed dpms off and next SetCrtc with an another fb
then the hardware can be accessed with dpms off to write overlay
data onto some registers so this patch will prevent from accessing
the hardware with dpms off.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 5eda559..2810900 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -155,6 +155,12 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc
*crtc, int x, int y,
DRM_DEBUG_KMS("%s\n", __FILE__);
+ /* when framebuffer changing is requested, crtc's dpms should be on */
+ if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
+ DRM_ERROR("failed framebuffer changing request.\n");
+ return -EPERM;
+ }
+
crtc_w = crtc->fb->width - x;
crtc_h = crtc->fb->height - y;
--
1.7.4.1
[PATCH 3/4] drm/exynos: check crtc's dpms mode at page flip
when page flip is requested, crtc's dpms mode should be on.
if not on, return -EPERM so that the hardware can't be accessed.
if user requesed dpms off and next page flip then the hardware
can be accessed with dpms off to enable vblank so this patch
will prevent from accessing the hardware with dpms off.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 8bd4d7e..5eda559 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -207,6 +207,12 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
DRM_DEBUG_KMS("%s\n", __FILE__);
+ /* when the page flip is requested, crtc's dpms should be on */
+ if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
+ DRM_ERROR("failed page flip request.\n");
+ return -EPERM;
+ }
+
mutex_lock(&dev->struct_mutex);
if (event) {
--
1.7.4.1
[PATCH] drm/nouveau: fix booting with plymouth + dumb support
On Fri, Sep 14, 2012 at 01:29:55PM +1000, Dave Airlie wrote: > From: Dave Airlie > > We noticed a plymouth bug on Fedora 18, and I then > noticed this stupid thinko, fixing it fixed the problem > with plymouth. > > Signed-off-by: Dave Airlie Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/nouveau_display.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c > b/drivers/gpu/drm/nouveau/nouveau_display.c > index 69688ef..7e16dc5 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_display.c > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c > @@ -598,7 +598,7 @@ nouveau_display_dumb_create(struct drm_file *file_priv, > struct drm_device *dev, > args->size = args->pitch * args->height; > args->size = roundup(args->size, PAGE_SIZE); > > - ret = nouveau_gem_new(dev, args->size, 0, TTM_PL_FLAG_VRAM, 0, 0, &bo); > + ret = nouveau_gem_new(dev, args->size, 0, NOUVEAU_GEM_DOMAIN_VRAM, 0, > 0, &bo); > if (ret) > return ret; > > -- > 1.7.10.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54877] [bisected] rendering corrupted for windows larger than 2048 pixels in one dimension
https://bugs.freedesktop.org/show_bug.cgi?id=54877 --- Comment #3 from Vadim Girlin 2012-09-14 06:35:08 UTC --- (In reply to comment #2) > Created attachment 67121 [details] [review] > fix > > This fixes it. I need to find out how the quant mode affects the range of > values. My guess is that QUANT_MODE determines the position of fixed point for internal calculations in hw. Quantization precision 1/4096 means 12 bits, and it looks like we have 11 bits before the point in that case, with 23 bits total. So if we need to increase the range, we have to move the point lowering the precision. I've tried 1/256 and other values on evergreen for initial implementation of that patch in hope that it'll be enough, but IIRC 1/4096 fixed more tests (though possibly some test results were simply random). If some tests are really failing due to lower precision, I guess we might want to adjust QUANT_MODE dynamically. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31708] [RADEON:KMS:TTM] kernel oops when loading large images with firefox
https://bugs.freedesktop.org/show_bug.cgi?id=31708 --- Comment #15 from Reiner 2012-09-14 07:08:40 UTC --- I can confirm this bug with the following configuration: - Thinkpad R40 w/ ATI Radeon Mobility M7 (AGP) - XUbuntu 12.04.01 with kernel 3.2.0-30-generic #48-Ubuntu SMP - X.Org X Server 1.11.3 - open radeon driver 6.14.99 - KMS, DRI, EXA (bug does not occur with XAA, but then 2D performance is poor; fiddling with EXA options did not get rid of the bug) full Xorg log: [34.083] X.Org X Server 1.11.3 Release Date: 2011-12-16 [34.083] X Protocol Version 11, Revision 0 [34.083] Build Operating System: Linux 2.6.42-26-generic i686 Ubuntu [34.084] Current Operating System: Linux boris 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:54:40 UTC 2012 i686 [34.084] Kernel command line: BOOT_IMAGE=/vmlinuz-3.2.0-30-generic root=UUID=c29eb28f-af18-48d5-99ff-8f871967d672 ro quiet splash vt.handoff=7 [34.084] Build Date: 04 August 2012 01:51:24AM [34.084] xorg-server 2:1.11.4-0ubuntu10.7 (For technical support please see http://www.ubuntu.com/support) [34.084] Current version of pixman: 0.24.4 [34.084] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [34.084] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [34.084] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Sep 14 07:47:48 2012 [34.107] (==) Using config directory: "/etc/X11/xorg.conf.d" [34.107] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [34.108] (==) No Layout section. Using the first Screen section. [34.108] (==) No screen section available. Using defaults. [34.108] (**) |-->Screen "Default Screen Section" (0) [34.108] (**) | |-->Monitor "" [34.108] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [34.108] (**) | |-->Device "Radeon" [34.108] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [34.108] (==) Automatically adding devices [34.108] (==) Automatically enabling devices [34.108] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [34.108] Entry deleted from font path. [34.108] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [34.108] Entry deleted from font path. [34.109] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [34.109] Entry deleted from font path. [34.109] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [34.109] Entry deleted from font path. [34.109] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [34.109] Entry deleted from font path. [34.109] (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. [34.109] Entry deleted from font path. [34.109] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, built-ins [34.109] (==) ModulePath set to "/usr/lib/i386-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules" [34.109] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [34.109] (II) Loader magic: 0xdea5a0 [34.109] (II) Module ABI versions: [34.109] X.Org ANSI C Emulation: 0.4 [34.109] X.Org Video Driver: 11.0 [34.109] X.Org XInput driver : 16.0 [34.109] X.Org Server Extension : 6.0 [34.110] (--) PCI:*(0:1:0:0) 1002:4c57:1014:0527 rev 0, Mem @ 0xe000/134217728, 0xc010/65536, I/O @ 0x3000/256, BIOS @ 0x/131072 [34.110] (II) Open ACPI successful (/var/run/acpid.socket) [34.110] (II) LoadModule: "extmod" [34.129] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [34.129] (II) Module extmod: vendor="X.Org Foundation" [34.129] compiled for 1.11.3, module version = 1.0.0 [34.129] Module class: X.Org Server Extension [34.129] ABI class: X.Org Server Extension, version 6.0 [34.129] (II) Loading extension MIT-SCREEN-SAVER [34.129] (II) Loading extension XFree86-VidModeExtension [34.129] (II) Loading extension XFree86-DGA [34.129] (II) Loading extension DPMS [34.129] (II) Loading extension XVideo [34.129] (II) Loading extension XVideo-MotionCompensation [34.129] (II) Loading extension X-Resource [34.129] (II) LoadModule: "dbe" [34.130] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [34.130] (II) Module dbe: vendor="X.Org Foundation" [34.130] compiled for 1.11.3, module version = 1.0.0 [34.130] Module class: X.Org Server Extension [34.130] ABI class: X.Org Server Extension, version 6.0 [34.130] (II
[Bug 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #44 from lukenshiro at ngi.it 2012-09-14 07:59:36 UTC --- Sorry, I've managed to resolve my first problem (screen blanking after boot for about 30-40 seconds): it is not related to drm, but it depends on fbcon loaded as a module (instead of it being compiled statically). As explained in /usr/src/linux/Documentation/fb/fbcon.txt if fbcon is compiled as a module (CONFIG_FRAMEBUFFER_CONSOLE=m) it can produce blanking and/or garbage on display if it is not loaded immediately. If "Framebuffer Console support" is compiled statically (CONFIG_FRAMEBUFFER_CONSOLE=y) there is no blanking here. "Works for me" HTH. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] Add 2-level GPUVM pagetables support to radeon driver.
On Don, 2012-09-13 at 18:13 +0400, Dmitry Cherkasov wrote:
> PDE/PTE update code uses CP ring for memory writes.
> All page table entries are preallocated for now in alloc_pt().
>
> It is made as whole because it's hard to divide it to several patches
> that compile and doesn't break anything being applied separately.
>
> Tested on cayman card.
>
> Signed-off-by: Dmitry Cherkasov
> ---
> I couldn't test in on SI card, so would be happy if someone could check it
> there.
[...]
> radeon_ring_write(ring, addr & 0x);
> radeon_ring_write(ring, (addr >> 32) & 0x);
FWIW, masking with 0x is superfluous here, as 64 bit values will
be implicitly truncated to 32 bits. The compiler will hopefully optimize
away the unnecessary & operations, but it might be better not to require
that in the first place.
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 4d67f0f..062896f 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 2f7adea..0df6a55 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1377,6 +1377,7 @@ static struct radeon_asic cayman_asic = {
> .fini = &cayman_vm_fini,
> .pt_ring_index = RADEON_RING_TYPE_GFX_INDEX,
> .set_page = &cayman_vm_set_page,
> + .set_pdes = &cayman_vm_set_pdes,
> },
> .ring = {
> [RADEON_RING_TYPE_GFX_INDEX] = {
This also needs to be added to si_asic and trinity_asic, or it can't
work on SI or Trinity.
With that fixed, it seems to work on SI, but seems to slow things down
significantly. Have you noticed that as well? Any idea what might be the
reason?
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 2f28ff3..f9bda6e 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -576,9 +579,13 @@ retry:
> return r;
> }
>
> - vm->pt = radeon_sa_bo_cpu_addr(vm->sa_bo);
> - vm->pt_gpu_addr = radeon_sa_bo_gpu_addr(vm->sa_bo);
> - memset(vm->pt, 0, RADEON_GPU_PAGE_ALIGN(vm->last_pfn * 8));
> + DRM_INFO("radeon: reserved %d kb pd & pt tables\n",
> + gpuvm_tables_sz/1024);
DRM_INFO() is too noisy here. Make it DRM_DEBUG_DRIVER() or drop it.
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
[PATCH] Add 2-level GPUVM pagetables support to radeon driver.
On 13.09.2012 20:42, Jerome Glisse wrote: > On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher > wrote: >> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote: >>> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov >>> wrote: PDE/PTE update code uses CP ring for memory writes. All page table entries are preallocated for now in alloc_pt(). It is made as whole because it's hard to divide it to several patches that compile and doesn't break anything being applied separately. Tested on cayman card. Signed-off-by: Dmitry Cherkasov --- I couldn't test in on SI card, so would be happy if someone could check it there. >>> I wonder how this could have work as you don't set >>> PAGE_TABLE_BLOCK_SIZE field so each page directory entry cover only 1 >>> page. >> I think PAGE_TABLE_BLOCK_SIZE refers number of 4k pages used for PTE >> entries per PDE. E.g., 1 4k page contains 512 64 bit PTEs. so if >> BLOCK_SIZE is set to 1 page, each PDE points to 1 page (4k) or PTE >> entries. If BLOCK_SIZE is 2, each PDE points to 2 pages (8k) or PTEs, >> etc. >> >> Alex >> > If so then it's ok Yeah, minor nitpick: BLOCK_SIZE seems to be number of 4k pages in a page directory entry minus 1. So with a BLOCK_SIZE of 0 you get one 4K page and with a BLOCK_SIZE of 1 you get 8K, etc... Christian.
[PATCH] Add 2-level GPUVM pagetables support to radeon driver.
On Fre, 2012-09-14 at 13:04 +0400, Dmitry Cherkassov wrote: > > With that fixed, it seems to work on SI, but seems to slow things down > > significantly. Have you noticed that as well? Any idea what might be the > > reason? > > > Thanks I'll put it up to the patch. > > I had everything running slow on cayman when having lots of debugging output, > removing it fixed the slowness. I don't think that was it. The only output was the DRM_INFO printed once for each 3D app. > Could you please tell what benchmark/application you noticed slowness with? E.g. reflect from Mesa Demos wasn't able to sustain 60 fps in fullscreen. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[PATCH] Add 2-level GPUVM pagetables support to radeon driver.
> With that fixed, it seems to work on SI, but seems to slow things down > significantly. Have you noticed that as well? Any idea what might be the > reason? > Thanks I'll put it up to the patch. I had everything running slow on cayman when having lots of debugging output, removing it fixed the slowness. Could you please tell what benchmark/application you noticed slowness with? -- With best regards, Dmitry
[PATCH 3/6] staging: drm/imx: add i.MX IPUv3 base driver
On Fri, Sep 14, 2012 at 11:29:06AM +0200, Dirk Behme wrote:
> On 12.09.2012 12:31, Sascha Hauer wrote:
> >+
> >+ timeout = jiffies + msecs_to_jiffies(1000);
> >+ while (ipu_cm_read(ipu, IPU_MEM_RST) & 0x8000) {
> >+ if (time_after(jiffies, timeout))
> >+ return -ETIME;
> >+ cpu_relax();
> >+ }
> >+
> >+ mdelay(300);
>
>
> >+ return 0;
> >+}
>
> While doing some boot time measurement with i.MX6, we found that the
> above mdelay(300) is hurting regarding boot time. On i.MX6 you have
> two IPU instances, so in the end you get 600ms additional delay.
>
> Looking at the Freescale code, this function looks like
>
> static int ipu_reset(struct ipu_soc *ipu)
> {
> int timeout = 1000;
>
> ipu_cm_write(ipu, 0x807F, IPU_MEM_RST);
>
> while (ipu_cm_read(ipu, IPU_MEM_RST) & 0x8000) {
> if (!timeout--)
>return -ETIME;
> msleep(1);
> }
> return 0;
> }
>
> So there is a msleep() in the loop but no mdelay() outside. Any idea
> why the mdelay() is needed here? Or what could be done regarding
> boot time with this?
I remember we had issues on i.MX51 or 53 without it, but I would have to
recheck it.
In any way, I think this should be reworked. The reset takes quite a
long time and it's not nice to block the boot process for so long.
Some asynchronous reset would be nice here.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #4 from Anisse Astier 2012-09-14 10:16:22 --- I think it is indeed a regression. After many power cycles, I wasn't able to reproduce it with 3.2.16. This is going to take forever to bisect? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[git pull] drm fixes
I realise this a bit bigger than I would want at this point, exynos is a large chunk, I got them to half what they wanted already, and hey its ARM based, so not going to hurt many people, radeon has only two fixes, but the PLL fixes were a bit bigger, but required for a lot of scenarios, the fence fix is really urgent vmwgfx: I've pulled in a dumb ioctl support patch that I was going to shove in later and cc stable, but we need it asap, its mainly to stop mesa growing a really ugly dependency in userspace to run stuff on vmware, and if I don't stick it in the kernel now, everyone will have to ship ugly userspace libs to workaround it. nouveau: single urgent fix found in F18 testing, causes X to not start properly when f18 plymouth is used i915: smattering of fixes and debug quieting gma500: single regression fix so as I said a bit large, but its fairly well scattered and its all stuff I'll be shipping in F18's 3.6 kernel. Dave. The following changes since commit 0bd1189e239c76eb3a50e458548fbe7e4a5dfff1: Merge branch 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq (2012-09-12 07:16:54 +0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 610bd7da160f76f1644ecb4cd7f39511b49a22cc: drm/nouveau: fix booting with plymouth + dumb support (2012-09-14 15:45:01 +1000) Alan Cox (1): gma500: Fix regression on Oaktrail devices Alex Deucher (1): drm/radeon: rework pll selection (v3) Alexander Shishkin (1): drm/i915: initialize dpio_lock spin lock Christian K?nig (1): drm/radeon: make 64bit fences more robust v3 Daniel Vetter (2): drm/i915: set the right gen3 flip_done mode also at resume drm/i915: fix up the IBX transcoder B check Dave Airlie (6): drm/i915/edp: get the panel delay before powering up Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes vmwgfx: add dumb ioctl support Merge branch 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drm/nouveau: fix booting with plymouth + dumb support Inki Dae (2): drm/exynos: fixed page align bug. drm/exynos: remove DRM_FORMAT_NV12M from plane module Jani Nikula (2): drm/i915: only enable sdvo hotplug irq if needed drm/i915: do not expose a dysfunctional backlight interface to userspace Mandeep Singh Baines (1): drm/exynos: fix double call of drm_prime_(init/destroy)_file_private Sachin Kamat (9): drm/exynos: Remove redundant check in exynos_hdmi.c file drm/exynos: Remove redundant check in exynos_drm_fimd.c file drm/exynos: Use devm_kzalloc in exynos_drm_vidi.c file drm/exynos: Use devm_kzalloc in exynos_drm_hdmi.c file drm/exynos: Use devm_* functions in exynos_drm_g2d.c file drm/exynos: Add dependency for G2D in Kconfig drm/exynos: Make g2d_pm_ops static drm/exynos: Add missing braces around sizeof in exynos_hdmi.c drm/exynos: Add missing braces around sizeof in exynos_mixer.c Thomas Meyer (1): drm/exynos: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. [1] Tomasz Stanislawski (1): drm/exynos: add dummy support for dmabuf-mmap Ville Syrj?l? (1): drm: Drop the NV12M and YUV420M formats drivers/gpu/drm/exynos/Kconfig | 2 +- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 7 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c| 2 - drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 - drivers/gpu/drm/exynos/exynos_drm_g2d.c| 52 ++--- drivers/gpu/drm/exynos/exynos_drm_gem.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 - drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 11 +- drivers/gpu/drm/exynos/exynos_mixer.c | 6 +- drivers/gpu/drm/gma500/oaktrail_device.c | 2 + drivers/gpu/drm/i915/i915_dma.c| 1 + drivers/gpu/drm/i915/i915_irq.c| 3 - drivers/gpu/drm/i915/intel_display.c | 6 +- drivers/gpu/drm/i915/intel_dp.c| 11 +- drivers/gpu/drm/i915/intel_panel.c | 31 -- drivers/gpu/drm/i915/intel_pm.c| 3 + drivers/gpu/drm/i915/intel_sdvo.c | 15 ++- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- drivers/gpu/drm/radeon/atombios_crtc.c | 163 +++-- drivers/gpu/drm/radeon/radeon_fence.c | 8 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 5 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 10 ++ drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 73 + include/drm/drm_fourcc.h | 6 +- 26 files changed, 298 insertions
[Bug 31708] [RADEON:KMS:TTM] kernel oops when loading large images with firefox
https://bugs.freedesktop.org/show_bug.cgi?id=31708 --- Comment #16 from Michel D?nzer 2012-09-14 10:49:11 UTC --- (In reply to comment #15) > I can confirm this bug with the following configuration: > - Thinkpad R40 w/ ATI Radeon Mobility M7 (AGP) > - XUbuntu 12.04.01 with kernel 3.2.0-30-generic #48-Ubuntu SMP I doubt it's exactly the same bug (this one should be fixed since 2.6.37?), so it would be better to track your problem in a separate report. Please provide the dmesg output corresponding to your problem, but please attach files instead of pasting them in comments. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Memory eviction in ttm
Hi Maarten! Broadening the audience a bit.. On 9/14/12 9:12 AM, Maarten Lankhorst wrote: > Op 13-09-12 23:00, Thomas Hellstrom schreef: >> On 09/13/2012 07:13 PM, Maarten Lankhorst wrote: >>> Hey >>> >>> Op 13-09-12 18:41, Thomas Hellstrom schreef: On 09/13/2012 05:19 PM, Maarten Lankhorst wrote: > Hey, > > Op 12-09-12 15:28, Thomas Hellstrom schreef: >> On 09/12/2012 02:48 PM, Maarten Lankhorst wrote: >>> Hey Thomas, >>> >>> I'm playing around with moving reservations from ttm to global, but how >>> ttm >>> ttm is handling reservations is getting in the way. The code wants to >>> move >>> the bo from the lru lock at the same time a reservation is made, but >>> that >>> seems to be slightly too strict. It would really help me if that >>> guarantee >>> is removed. >> Hi, Maarten. >> >> Removing that restriction is not really possible at the moment. >> Also the memory accounting code depends on this, and may cause >> reservations >> in the most awkward places. Since these reservations don't have a ticket >> they may and will cause deadlocks. So in short the restriction is there >> to avoid deadlocks caused by ticketless reservations. > I have finished the lockdep annotations now which seems to catch almost > all abuse I threw at it, so I'm feeling slightly more confident about > moving > the locking order and reservations around. Maarten, moving reservations in TTM out of the lru lock is incorrect as the code is written now. If we want to move it out we need something for ticketless reservations I've been thinking of having a global hash table of tickets with the task struct pointer as the key, but even then, we'd need to be able to handle EBUSY errors on every operation that might try to reserve a buffer. The fact that lockdep doesn't complain isn't enough. There *will* be deadlock use-cases when TTM is handed the right data-set. Isn't there a way that a subsystem can register a callback to be performed to remove stuff from LRU and to take a pre-reservation lock? >>> What if multiple subsystems need those? You will end up with a deadlock >>> again. >>> >>> I think it would be easier to change the code in ttm_bo.c to not assume the >>> first >>> item on the lru list is really the least recently used, and assume the >>> first item >>> that can be reserved without blocking IS the least recently used instead. >> So what would happen then is that we'd spin on the first item on the LRU >> list, since >> when reserving we must release the LRU lock, and if reserving fails, we thus >> need to restart LRU traversal. Typically after a schedule(). That's bad. >> >> So let's take a step back and analyze why the LRU lock has become a problem. >> From what I can tell, it's because you want to use per-object lock when >> reserving instead of a >> global reservation lock (that TTM could use as the LRU lock). Is that >> correct? >> and in that case, in what situation do you envision such a global lock being >> contended >> to the extent that it hurts performance? >> > Lockdep WILL complain about trying to use multiple tickets, doing ticketed > and unticketed blocking reservations mixed, etc. > > I want to remove the global fence_lock and make it a per buffer lock, > with some > lockdep annotations it's perfectly legal to grab obj->fence_lock and > obj2->fence_lock > if you have a reservation, but it should complain loudly about trying to > take 2 fence_locks > at the same time without a reservation. Yes, TTM was previously using per buffer fence locks, and that works fine from a deadlock perspective, but it hurts performance. Fencing 200 buffers in a command submission (google-earth for example) will mean 198 unnecessary locks, each discarding the processor pipelines. Locking is a *slow* operation, particularly on systems with many processors, and I don't think it's a good idea to change that back, without analyzing the performance impact. There are reasons people are writing stuff like RCU to avoid locking... >>> So why don't we simply use RCU for fence pointers and get rid of the fence >>> locking? :D >>> danvet originally suggested it as a joke but if you think about it, it >>> would make a lot of sense for this usecase. >> I thought of that before, but the problem is you'd still need a spinlock to >> change the buffer's fence pointer, >> even if reading it becomes quick. > Actually, I changed lockdep annotations a bit to distinguish between the > cases where ttm_bo_wait is called without reservation, and ttm_bo_wait > is called with, as far as I can see there are only 2 places that do it > without, > at least if I converted my git tree properly.. > > http://cgit.freedesktop.org/~mlankhorst/linux/log
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 --- Comment #12 from Andy Furniss 2012-09-14 11:24:08 UTC --- Created attachment 67147 --> https://bugs.freedesktop.org/attachment.cgi?id=67147 before r300g: fix colormask with non-BGRA formats -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 --- Comment #13 from Andy Furniss 2012-09-14 11:25:38 UTC --- Created attachment 67148 --> https://bugs.freedesktop.org/attachment.cgi?id=67148 after r300g: fix colormask with non-BGRA formats -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 --- Comment #14 from Andy Furniss 2012-09-14 11:27:03 UTC --- (In reply to comment #11) > Sorry, I should have written "partially fixes..". It only fixes the crash, not > the playback problems. Decode on a 9600 has just been improved slightly by mesa commit - 1e51d368eb5360378218217ff35731896f48512f r300g: fix colormask with non-BGRA formats See attached r300-vdpau-before.png and after. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PULL] SH Mobile DRM driver for v3.7
Hi Dave, The SH Mobile DRM driver is now (in my opinion) ready for mainline. It requires GEM and KMS/FB helpers that have been reviewed on the list and tested. Sascha is waiting for them to reach your tree to send a pull request for another new driver. The following changes since commit 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: gma500: Remove unused variable (2012-09-13 11:40:05 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/fbdev.git drm-lcdc Lars-Peter Clausen (1): DRM: Add DRM KMS/FB CMA helper Laurent Pinchart (2): drm: Add NV24 and NV42 pixel formats drm: Renesas SH Mobile DRM driver Sascha Hauer (1): DRM: Add DRM GEM CMA helper drivers/gpu/drm/Kconfig| 17 + drivers/gpu/drm/Makefile |3 + drivers/gpu/drm/drm_crtc.c |6 + drivers/gpu/drm/drm_fb_cma_helper.c| 406 + drivers/gpu/drm/drm_gem_cma_helper.c | 251 drivers/gpu/drm/shmobile/Kconfig | 10 + drivers/gpu/drm/shmobile/Makefile |7 + drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 90 +++ drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 23 + drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 763 +++ drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 60 ++ drivers/gpu/drm/shmobile/shmob_drm_drv.c | 361 +++ drivers/gpu/drm/shmobile/shmob_drm_drv.h | 48 ++ drivers/gpu/drm/shmobile/shmob_drm_kms.c | 160 + drivers/gpu/drm/shmobile/shmob_drm_kms.h | 34 + drivers/gpu/drm/shmobile/shmob_drm_plane.c | 268 + drivers/gpu/drm/shmobile/shmob_drm_plane.h | 22 + drivers/gpu/drm/shmobile/shmob_drm_regs.h | 311 ++ include/drm/drm_fb_cma_helper.h| 27 + include/drm/drm_fourcc.h |2 + include/drm/drm_gem_cma_helper.h | 44 ++ include/drm/shmob_drm.h| 99 +++ 22 files changed, 3012 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/drm_fb_cma_helper.c create mode 100644 drivers/gpu/drm/drm_gem_cma_helper.c create mode 100644 drivers/gpu/drm/shmobile/Kconfig create mode 100644 drivers/gpu/drm/shmobile/Makefile create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h create mode 100644 include/drm/drm_fb_cma_helper.h create mode 100644 include/drm/drm_gem_cma_helper.h create mode 100644 include/drm/shmob_drm.h -- Regards, Laurent Pinchart
[Bug 47471] Radeon - NMI: PCI system error (SERR) for reason a1 on CPU 0.
https://bugzilla.kernel.org/show_bug.cgi?id=47471 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||DOCUMENTED -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PULL] SH Mobile DRM driver for v3.7
On Fri, 14 Sep 2012 14:38:10 +0200 Laurent Pinchart wrote: > Hi Dave, > > The SH Mobile DRM driver is now (in my opinion) ready for mainline. It > requires GEM and KMS/FB helpers that have been reviewed on the list and > tested. Sascha is waiting for them to reach your tree to send a pull request > for another new driver. > > The following changes since commit 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > are available in the git repository at: > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc Wrong summary ??
[RFC 0/9] nuclear pageflip
On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote: > On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrj?l? > wrote: > > On Thu, Sep 13, 2012 at 08:39:54AM -0500, Rob Clark wrote: > >> On Thu, Sep 13, 2012 at 3:40 AM, Ville Syrj?l? > >> wrote: > >> > On Wed, Sep 12, 2012 at 02:40:56PM -0500, Rob Clark wrote: > >> >> On Wed, Sep 12, 2012 at 1:58 PM, Ville Syrj?l? > >> >> wrote: > >> >> > On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote: > >> >> >> On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrj?l? > >> >> >> wrote: > >> >> >> > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote: > >> >> >> >> But I think we could still do this w/ one ioctl per crtc for > >> >> >> >> atomic-pageflip. > >> >> >> > > >> >> >> > We could, if we want to sacrifice the synced multi display case. I > >> >> >> > just > >> >> >> > think it might be a real use case at some point. IVI feels like > >> >> >> > the most > >> >> >> > likely short term cadidate to me, but perhaps someone would finally > >> >> >> > introduce some new style phone/tablet thingy. I have seen > >> >> >> > concepts/prototypes of such multi display gadgets in the past, but > >> >> >> > the > >> >> >> > industry apparently got a bit stuck on the rectangular slab with > >> >> >> > touchscreen on one side design. > >> >> >> > >> >> >> I could be wrong, but I think IVI the screens would normally be too > >> >> >> far apart to matter? > >> >> > > >> >> > I was thinking of something like a display on the dash that normally > >> >> > sits low with only a small sliver visible, and extends upwards when > >> >> > you fire up a movie player for example. Internally it could be made > >> >> > up of two displays for power savings purposes. > >> >> > > >> >> >> Anyways, it is really only a problem if you can't do two ioctl()s > >> >> >> within one vblank period. If it actually turns out to be a real > >> >> >> problem, > >> >> > > >> >> > Well exactly that's the problem this whole atomic pageflip stuff is > >> >> > trying to tackle, no? ;) > >> >> > > >> >> >> we could always add later an ioctl that takes an array of > >> >> >> 'struct drm_mode_crtc_atomic_page_flip's. I'm not sure if this is > >> >> >> really useful or not.. but maybe I'm thinking too much about how > >> >> >> weston does it's rendering of different output's independently. > >> >> > > >> >> > I'm just now thinking of surfaceflinger's way of doing things, with > >> >> > its prepare and commit phases. If you need to issue two ioctls to > >> >> > handle > >> >> > cloned displays, then you can end up in a somewhat funky situation. > >> >> > > >> >> > Let's say you have a video overlay in use (one each display > >> >> > naturally), > >> >> > and you increase the downscaling factor enough so that you now have > >> >> > enough memory bandwith to support only one overlay. With independent > >> >> > check ioctls for each display, you never have the full device state > >> >> > available in the kernel, so each check succeeds during the prepare > >> >> > phase. So you decide that you can keep using the video overlays. > >> >> > > >> >> > You then proceed to commit the state, but after the first display has > >> >> > been commited you get an error when trying to commit the second one. > >> >> > What can you do now? The only option is to keep displaying the old > >> >> > frame on the other displays for some time longer, and then on the > >> >> > next frame you can switch to GPU composition. But on the next frame > >> >> > you > >> >> > perhaps no longer need to use GPU composition, but since you can't > >> >> > verify that in the prepare phase, you have no other option but to use > >> >> > GPU composition. > >> >> > > >> >> > So when you run into a configuration that can be supported only > >> >> > partially, you get animation stalls on some displays due to skipped > >> >> > frames, and you always have to fall back to GPU composition for the > >> >> > next frame. > >> >> > > >> >> > If on the other hand you would check the whole state in one ioctl, > >> >> > you'd get the error in the first prepare phase, and could fall back > >> >> > to GPU composition immediately. > >> >> > > >> >> > Am I too much of a perfectionst in considering such things? I don't > >> >> > think so, but perhaps other people disagree. > >> >> > >> >> Ok, if you have a case where the state of the two crtc's are not > >> >> actually independent, then I think you have a valid point. > >> >> > >> >> I'm not quite sure what userspace would do about it, though.. for the > >> >> general case where vsync isn't locked, and you can't even necessarily > >> >> assume vsync period is the same, then I don't really think you want to > >> >> couple rendering to the displays. > >> > > >> > I would say this is going to be the most common use case if you consider > >> > just the number of shipping devices. It's pretty much what every Android > >> > phone/tablet with a HDMI port has to do. > >> > >> bleh, surfaceflinger kinda sucks then.. > > > >
[PATCH] i915: Quirk out disconnected backlight
On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely wrote: > Some platforms (for instance MacbookPros) have custom backlight drivers > and don't use the integrated i915 backlight control. This patch adds a > quirk to disable registering the intel backlight when unused on a > platform. > > Tested on MacbookPro8,3. Without this patch both the intel_backlight and > gmux_backlight devices get registered and userspace doesn't know which > it should use. Userspace is informed throught the backlight/type property. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PULL] SH Mobile DRM driver for v3.7
Hi Alan, On Friday 14 September 2012 13:47:33 Alan Cox wrote: > On Fri, 14 Sep 2012 14:38:10 +0200 Laurent Pinchart wrote: > > Hi Dave, > > > > The SH Mobile DRM driver is now (in my opinion) ready for mainline. It > > requires GEM and KMS/FB helpers that have been reviewed on the list and > > tested. Sascha is waiting for them to reach your tree to send a pull > > request for another new driver. > > > > The following changes since commit 09e7dcf081b1100d1cdff57fa9eb25c3a834c9d6: > > gma500: Remove unused variable (2012-09-13 11:40:05 +1000) > > > > are available in the git repository at: > > git://linuxtv.org/pinchartl/fbdev.git drm-lcdc > > Wrong summary ?? The repository is oddly named because I've initially created it to hold fbdev patches. The drm-lcdc branch contains DRM patches. -- Regards, Laurent Pinchart
[PATCH] Add 2-level GPUVM pagetables support to radeon driver.
> -Original Message- > From: Christian K?nig [mailto:deathsimple at vodafone.de] > Sent: Friday, September 14, 2012 4:49 AM > To: Jerome Glisse > Cc: Alex Deucher; Cherkasov, Dmitrii; linux-kernel at vger.kernel.org; dri- > devel at lists.freedesktop.org; Deucher, Alexander; Dave Airlie; Dmitry > Cherkasov > Subject: Re: [PATCH] Add 2-level GPUVM pagetables support to radeon > driver. > > On 13.09.2012 20:42, Jerome Glisse wrote: > > On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher > wrote: > >> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse > wrote: > >>> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov > >>> wrote: > PDE/PTE update code uses CP ring for memory writes. > All page table entries are preallocated for now in alloc_pt(). > > It is made as whole because it's hard to divide it to several patches > that compile and doesn't break anything being applied separately. > > Tested on cayman card. > > Signed-off-by: Dmitry Cherkasov > --- > I couldn't test in on SI card, so would be happy if someone could check > it there. > >>> I wonder how this could have work as you don't set > >>> PAGE_TABLE_BLOCK_SIZE field so each page directory entry cover only 1 > >>> page. > >> I think PAGE_TABLE_BLOCK_SIZE refers number of 4k pages used for PTE > >> entries per PDE. E.g., 1 4k page contains 512 64 bit PTEs. so if > >> BLOCK_SIZE is set to 1 page, each PDE points to 1 page (4k) or PTE > >> entries. If BLOCK_SIZE is 2, each PDE points to 2 pages (8k) or PTEs, > >> etc. > >> > >> Alex > >> > > If so then it's ok > Yeah, minor nitpick: BLOCK_SIZE seems to be number of 4k pages in a page > directory entry minus 1. > > So with a BLOCK_SIZE of 0 you get one 4K page and with a BLOCK_SIZE of 1 > you get 8K, etc... It's LOG2: PAGE_TABLE_BLOCK_SIZE 27:24 0x0 log2 number of pages in page table block (default = 1 page) > > Christian.
