similar to: [Bug 107729] Nouveau gr BUG

https://bugs.freedesktop.org/show_bug.cgi?id=107729 Martin Peres <martin.peres at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #3 from Martin Peres

https://bugs.freedesktop.org/show_bug.cgi?id=94844 Bug ID: 94844 Summary: Ditching xf86-video-nouveau in favor of xf86-video-modesetting? Product: xorg Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

On Tue, Jul 7, 2015 at 5:05 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 8 July 2015 at 06:06, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> Ben, >> >> Looks like the reality is that glamor is just not hooked up properly >> in the nouveau DDX. Mainly it's missing DRI2, which in turn means no >> core GL contexts, and probably lots of other

You need these ports for LVDS? Because i know these ports are correct for dvi and friends. So if you changed them for lvds, we need to seperate port 4 and 5 into lvds and non-lvds. Maarten. On Fri, Apr 3, 2009 at 6:26 AM, Ben Skeggs <darktama at kemper.freedesktop.org> wrote: > ?src/nv50reg.h | ? ?4 ++-- > ?1 file changed, 2 insertions(+), 2 deletions(-) > > New commits: >

Hello Ben, You can find below my results; there is a slight over-representation of 1st gen Tesla cards, but… that’s what I have. :-D No regressions observed, apart from: * screen rotation on G80, MCP79 * resuming on G86 I’ll retest those cards with your linux-4.10 branch but without the atomic + DP serie. Pierre Tested: linux-4.10 (HEAD at b27add13f "drm/nouveau/fifo/gf100-: protect

https://bugs.freedesktop.org/show_bug.cgi?id=107729 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Product|DRI |xorg Version|XOrg git |unspecified Assignee|dri-devel at

On 3 September 2015 at 17:11, Alexandre Courbot <gnurou at gmail.com> wrote: > On Thu, Sep 3, 2015 at 4:08 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 3 September 2015 at 16:32, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Some devices may not have a PMU. Avoid a NULL pointer dereference in >>> such cases. >>> >>>

http://bugs.freedesktop.org/show_bug.cgi?id=23672 Summary: Nouveau KMS fails with error: Failed to fence channel 0 Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach <dev at lynxeye.de> wrote: > Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs: >> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> >> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin

On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs <skeggsb at gmail.com> wrote: >>>> On Thu, Aug 29, 2013 at

On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: > In case anyone's curious about 30bpp framebuffer support, here's the > current status: > > Kernel: > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > and I've also written a patch to cause the addfb ioctl to use the > proper format. You can pick this up at: > >

Allow fecs to potentially set both methods: - 0x38 STOP_CTXSW - 0x39 START_CTXSW At present the code only ever starts context swap, and never pauses it as appears to be the intent of one caller of gf100_gr_fecs_ctrl_ctxs(). Cc: Ben Skeggs <bskeggs at redhat.com> Fixes: 2642e0b5 ("gr/gf100-: expose fecs methods for pausing ctxsw") Signed-off-by: Rhys Kidd <rhyskidd at

On Sun, 13 Sep 2009 20:06:59 -0700 (PDT) darktama at kemper.freedesktop.org (Ben Skeggs) wrote: > src/drmmode_display.c | 6 ++++++ > src/nv_driver.c | 2 ++ > 2 files changed, 8 insertions(+) > > New commits: > commit 6c045fc44783454180d7b3d00b5f25436bd5544e > Author: Ben Skeggs <bskeggs at redhat.com> > Date: Mon Sep 14 13:04:12 2009 +1000 >

On 02/05/2018 12:50 AM, Ilia Mirkin wrote: > In case anyone's curious about 30bpp framebuffer support, here's the > current status: > > Kernel: > > Ben and I have switched the code to using a 256-based LUT for Kepler+, > and I've also written a patch to cause the addfb ioctl to use the > proper format. You can pick this up at: > >

On 09/03/2013 09:45 PM, Ben Skeggs wrote: > On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach <dev at lynxeye.de> wrote: >> Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs: >>> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >>>> On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs <skeggsb at gmail.com> wrote:

Cc'ing mesa-dev, which was left out. On 03/05/2018 01:40 PM, Ilia Mirkin wrote: > On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner > <mario.kleiner.de at gmail.com> wrote: >> On 02/05/2018 12:50 AM, Ilia Mirkin wrote: >>> >>> In case anyone's curious about 30bpp framebuffer support, here's the >>> current status: >>> >>>

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by: