similar to: Noveau Driver NVIDIA wake from standby display activation issues

https://bugs.freedesktop.org/show_bug.cgi?id=93778 Bug ID: 93778 Summary: Noveau GeForce GT 640M vbios error Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=96952 Bug ID: 96952 Summary: Noveau driver doesn't working well when in Kdenlive Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee:

On Thu, 17 Jul 2008 15:49:42 +0200 Micha? Wi?niewski <brylozketrzyn at gmail.com> wrote: > Hi > > I'm writing to you cause I want to help with noveau. I have GF 5200 card and I > can dump any data you need from it's registers, of course, avalaible to dump > with nvclock. Just write what test you want me to perform (if possible, with > explanations; I'll set

Hey Attila, I CC'd the nouveau mailing list. Although if you want help, you should probably provide more details (what version of mesa, etc.). St?phane On Sat, Feb 8, 2014 at 11:23 PM, Attila T?th <tothsoft at gmail.com> wrote: > Hi, > sorry, i have not better email adress of noveau team. Please send email - > mail feedback, that by moving on time in the movie, vdpau

Adding back the nouveau list... On Sun, Feb 9, 2014 at 8:28 AM, Attila T?th <tothsoft at gmail.com> wrote: > Linux mint 16 (64bit) > > Repo: Ubuntu X-SWAT <ubuntu-x at lists.ubuntu.com><ubuntu-x at lists.ubuntu.com> > Mesa: 10.2.0~git20140205.44338cd8-0ubuntu0sarvatt~saucy > libdrm: 2.4.52+git20140121.46d451c9-0ubuntu0sarvatt~saucy > libg3dvl-mesa:

Context switching = very slow on NVIDIA. Don't do it if you can avoid it. Each context is like a megabyte of data, if not more. Each time it has to get saved off and restored. On Wed, Feb 8, 2017 at 1:38 PM, Sampsa Riikonen <sampsa.riikonen at iki.fi> wrote: > Dear Devs, > > (I hope this question is not that much OT for this list..) > > My question is about fast OpenGL

On Sat, 2020-06-13 at 20:29 -0500, Aditya Pakki wrote: > nv50_disp_atomic_commit() calls calls pm_runtime_get_sync and in turn > increments the reference count. In case of failure, decrement the > ref count before returning the error. > > Signed-off-by: Aditya Pakki <pakki001 at umn.edu> > --- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++- > 1 file changed, 3

https://bugs.freedesktop.org/show_bug.cgi?id=45752 Bug #: 45752 Summary: Debian Wheezy with xfce4-power-manager and noveau fails to resume from hibernate Classification: Unclassified Product: xorg Version: 7.7 (2011) Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity:

Hi, Thanks for your advice..! I have a few follow-up questions (tagged below Q1, Q2 and Q3). Any help highly/extremely appreciated. Regarding to "reverse prime", etc. I have read the following page: https://nouveau.freedesktop.org/wiki/Optimus/ So, if we want a single "macro" xscreen that spans two cards, for example: Card 0, connected to monitor 0 Card 1, connected to

Dear Devs, (I hope this question is not that much OT for this list..) My question is about fast OpenGL context switching, i.e. when there are several processes using the same nvidia card, each one with their own OpenGL context. In my specific case, I am trying to dump 720p video simultaneously to multiple windows using OpenGL textures. So, to begin with, I have a process that spans child

https://bugs.freedesktop.org/show_bug.cgi?id=106391 Bug ID: 106391 Summary: Noveau fails to compile when using meson and LLVM without RTTI Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component:

For details see my presentation on day 3 of XDC2016. TL;DW: A context switch on average takes ~25 microseconds, but depending on the display resolution and the load on the card times up to 130 microseconds have been observed. The average does not appear to differ much between cards as the (growing) size of the context is in balance with the increased DRAM bandwidth. Measured worst cases

The dragonegg-2.9.tgz tarball is failing to build against either patched gcc 4.5.2 or gcc 4.5.3svn on x86_64-apple-darwin10. The build fails as... GCC=/sw/lib/gcc4.5/bin/gcc-4 LLVM_CONFIG=/sw/bin/llvm-config make CPPFLAGS="-DENABLE_LTO -I/sw/include" Compiling utils/TargetInfo.cpp <command-line>: warning: "__STDC_LIMIT_MACROS" redefined <command-line>: warning:

https://bugs.freedesktop.org/show_bug.cgi?id=103217 Bug ID: 103217 Summary: Recent noveau causes errors with scilab 5.5.2 on NVIDIA G84GL [Quadro FX 570] Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component:

nv50_disp_atomic_commit() calls calls pm_runtime_get_sync and in turn increments the reference count. In case of failure, decrement the ref count before returning the error. Signed-off-by: Aditya Pakki <pakki001 at umn.edu> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c

Thanks for the pointer. But I don't like this patch. If you find a bug, make a bug report or just fix it if you know the fix already. Or write something in IRC. Or write on the Mailing list as a general question or something else But I really don't agree on doing it this way. You would have needed like the same amount of time to actual fix the problem. Anyway, for adding a printk:

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith <efault at gmx.de> wrote: > On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: >> Some details that may be useful in analysis of the bug: >> >> 1. lspci -nn -d 10de: > > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1) > 01:00.1 Audio device [0403]: NVIDIA

On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: >> > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not >> > too much trouble, a bisect would be pretty useful. >> >> Bisection

On 7/12/17 7:19 PM, Mike Galbraith wrote: > On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: >> On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: >>> On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: >>>> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: >>>>> Some display stuff did change for 4.13 for

On 7/14/17 3:41 PM, Mike Galbraith wrote: > On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote: >>  All DRM did was to slip a >> WARN_ON_ONCE() that nouveau triggers into a kernel module where such >> things no longer warn, they blow the box out of the water. > BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c > into a WARN_ONCE(), and all is