[Nouveau] [PATCH] dri3: remove bogus condition for creating pixmap

Not clear what the depth % 8 was trying to protect against, but it was breaking 30bpp visuals with DRI3. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/nouveau_dri2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c

[Nouveau] [PATCH 1/2] kms/nv50-gf119: use "low res" lut for indexed mode

systems, which can occur with some IGP-based configurations with little "stolen" vram. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- There's more to be done here I think since the first modeset ends up skipping

[Nouveau] [PATCH 2/2] kms/gf119-: always use a 256-entry lut for now

Unfortunately the ABI is a little annoying around almost requiring a 256-entry lut. While that is being worked out, allow proper mapping of colors in 30bpp framebuffers. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- If I bump the gamma size to 1024, then all existing software will

[Nouveau] LUT update skipped on first modeset?

Hi Ben, I was looking into some of the LUT-related modesetting issues. I've noticed the following... after I load nouveau, one of my secondary GPUs shows this on first modeset (with drm.debug=4): [ 2368.081307] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:44:DVI-I-1]

Re: [Nouveau] [PATCH] gm107/ir: use lane 0 for manual textureGrad handling

On Tue, Dec 19, 2017 at 11:41 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > This is parallel to the pre-SM50 change which does this. Adjusts the > shuffles / quadops to make the values correct relative to lane 0, and > then splat the results to all lanes for the final move

[Nouveau] [PATCH] gm107/ir: use lane 0 for manual textureGrad handling

This is parallel to the pre-SM50 change which does this. Adjusts the shuffles / quadops to make the values correct relative to lane 0, and then splat the results to all lanes for the final move into the target register. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- Entirely un

Re: [Nouveau] Nouveau and VESA Adptive Sync (FreeSync)?

NVIDIA has been releasing some very partial documentation about their display hw. You can see the latest iteration of those efforts at http://download.nvidia.com/open-gpu-doc/Display-Class-Methods/2/ . I don't know which, if any, NVIDIA chips support FreeSync (as opposed to G-SYNC). Perhaps the

Re: [Nouveau] Addressing the problem of noisy GPUs under Nouveau

On Tue, Nov 21, 2017 at 8:29 PM, Andy Ritger wrote: > Hi Martin, Martin should have complete answers, > > I was asked to clarify a few things: > > (1) Are all the user reports of loud fans on Fermi-era GPUs? Yes. Although I believe some GK208 users are also having trouble,

Re: [Nouveau] GP10B regression

On Tue, Nov 21, 2017 at 1:07 PM, Mikko Perttunen wrote: > Thanks to Thierry for finding this - applying > > index e14643615698..00eeaaffeae5 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c > @@ -2369,7

Re: [Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Sat, Nov 18, 2017 at 12:23 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> >> wrote: >>> On Friday 1

Re: [Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> > wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, O

Re: [Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> > wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, O

Re: [Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <li...@rainbow-software.org> wrote: > On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >> >> <li...@rainbow-software.org> wrote: >> > @@ -483,8 +483,8 @@

Re: [Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary wrote: > @@ -483,8 +483,8 @@ > nouveau :02:00.0: disp:0860: -> 0500 > nouveau :02:00.0: disp:0864: > nouveau :02:00.0: disp:0868: -> 04000500 > -nouveau

Re: [Nouveau] Blank console but X11 works on MCP79 - old regression since 3.8

With a new kernel, mind grabbing a dmesg with drm.debug=0x1e nouveau.debug=debug (or maybe even =trace)? Maybe also see if fbcon/fbdev have any debug things that can be turned on? Sounds like things are generally working, just the fbcon -> nouveaufb path seems somehow buggered. Another thing to

Re: [Nouveau] [PATCH] pmu/fuc: don't use movw directly anymore

On Wed, Nov 1, 2017 at 12:51 PM, Karol Herbst wrote: > fixes compilation issues with recent envytools, because movw was removed > from fuc5, because it doesn't exist there anymore. The current code is > most likely broken for fuc5 hardware as well and might have triggered all

[Nouveau] [PATCH] bios: add 8.1Gbps DP link rate

This was already done in dcb.c inside nvkm, but the other parser did not get the update. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- Entirely untested. Why do we have two DCB parsers again? Also the other one sets link_bw to a totally different set of units for link_bw... drm/n

[Nouveau] [PATCH] bsp/g92: disable by default

-enable the bsp engine if they want to play around with it, but makes it harder for the card to hang by default. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nvkm/engine/bsp/g84.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/engi

Re: [Nouveau] FERMI clocking status and help

On Fri, Sep 22, 2017 at 10:32 PM, Brock York wrote: > Where is the current FERMI clocking code? My base kernel just gives me > failed to write when I echo to /sys/kernel/debug/dri/0/pstate. I've > downloaded the nouveau linux tree from skeggsb/nouveau and built the > 4.14

Re: [Nouveau] nVidia GT218M [GeForce 315M] issues on kUbuntu 17.04 x86-64.

y drivers. > So the question is whether this hardware is supported or not. > > > On 2017-09-18 21:31, Ilia Mirkin wrote: >> >> What seems to be the problem? I think you forgot to include a >> description of the issues you're seeing. >> >> On Sep 18, 2017 11:23 PM,

Re: [Nouveau] nVidia GT218M [GeForce 315M] issues on kUbuntu 17.04 x86-64.

What seems to be the problem? I think you forgot to include a description of the issues you're seeing. On Sep 18, 2017 11:23 PM, wrote: Hello looks like the device is not supported, the logs are as follows: --- # dmesg | grep nouve [2.789899] fb: switching to

Re: [Nouveau] nvidia geforce 1050 on xps 9560 crashing - howto debug

I believe a number of people are hitting this issue (all with the Dell XPS 9560 - not sure if it's popular or if there's something special about it). Have a look at https://bugs.freedesktop.org/show_bug.cgi?id=100228 https://bugs.freedesktop.org/show_bug.cgi?id=101220 Cheers, -ilia On Fri,

Re: [Nouveau] trouble connecting to Panduit VGA adapter

wrote: > I'm running 4.9.43-1-MANJARO > > Ilia Mirkin <imir...@alum.mit.edu> writes: > >> Are you running a v4.12-based kernel? If so, update to v4.13-rcN or >> integrate >> https://github.com/skeggsb/linux/commit/13a86519202c5d119d83640d6f781f3181205d2c >> i

[Nouveau] v4.12 backport request: 13a86519202 (drm/nouveau/i2c/gf119-: add support for address-only transactions)

Commit df8dc97cd17 (drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm) switched things over to the drm algo. Unfortunately it generates address-only transactions. Prior to GF119, the hardware had no support for such things, and GF119+ the nouveau code did not handle these properly. The

Re: [Nouveau] trouble connecting to Panduit VGA adapter

Are you running a v4.12-based kernel? If so, update to v4.13-rcN or integrate https://github.com/skeggsb/linux/commit/13a86519202c5d119d83640d6f781f3181205d2c into your kernel build. On Fri, Sep 1, 2017 at 12:50 PM, Marko Schuetz-Schmuck wrote: > I want to connect to an

Re: [Nouveau] [RFC PATCH] drm/nouveau/therm: initial implementation of new gp1xx temperature sensor

On Wed, Aug 30, 2017 at 10:55 PM, Rhys Kidd wrote: > Signed-off-by: Rhys Kidd > --- > .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 1 + > drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +++ >

Re: [Nouveau] glx error with nouveau

BTW, note that mesa-based drivers don't support above GL 3.0 for compatibility contexts on any hardware. Most reasonable software that requires advanced functionality uses core contexts though. On Sat, Aug 26, 2017 at 10:38 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > Depends on the

Re: [Nouveau] glx error with nouveau

the distro released more recently than Dec 2009 support OPENGL 3.3 ? > > > Best, > > Yunde > > > From: ibmir...@gmail.com <ibmir...@gmail.com> on behalf of Ilia Mirkin > <imir...@alum.mit.edu> > Sent: Friday, August 25, 2017 6:27:4

Re: [Nouveau] glx error with nouveau

Nouveau was merged upstream into the kernel in 2.6.35 or so. The 2.6.32-based system you have is a franken-kernel maintained by RedHat. You should go to them for support. I'd recommend trying a distro based on a kernel that was released more recently than Dec 2009. On Thu, Aug 24, 2017 at 1:29

Re: [Nouveau] [Mesa-dev] VDPAU issues in 17.2 and master, and a test request

On Mon, Aug 21, 2017 at 5:54 PM, Andy Furniss <adf.li...@gmail.com> wrote: > Ilia Mirkin wrote: > >> As I don't have the hardware myself, I was hoping someone could >> confirm that this is a nouveau issue and not a more general one. >> Ideally this would be done by

[Nouveau] VDPAU issues in 17.2 and master, and a test request

. Please use mplayer for this, not mpv or mplayer2 or anything else -- all those have various differences in how the rendering is done from mplayer, which could account for a different final result. Thanks, Ilia Mirkin imir...@alum.mit.edu ___ Nouveau

Re: [Nouveau] [PATCH] nv50/ra: Only increment DefValue counter if we are going to spill

On Sat, Aug 19, 2017 at 12:50 PM, Tobias Klausmann wrote: > This is in preparation of an upcoming patch changing how we keep track of the > defs. > > Signed-off-by: Tobias Klausmann > --- >

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote: > From: Colin Ian King > > The null check on the array msto is incorrect since msto is never > null. The null check should be instead on msto[i] since this is > being dereferenced in the call

Re: [Nouveau] [PATCH] nvc0: fix handling of inverted render condition

So ... how do you handle the case of a query that hasn't completed yet and one of the no-wait enums is passed in? On Thu, Aug 17, 2017 at 4:43 PM, Tobias Klausmann wrote: > Wether we wait on an inverted rendering condition or not, we should not render > on a

Re: [Nouveau] nouveau driver locks up with 4.11 kernel

On Mon, Aug 14, 2017 at 3:18 PM, Michal Hocko wrote: > Hi, > I am having issues with nouveau driver in 4.11 Debian distribution > kernel. I can start X session but the screen locks up e.g. when I try to > exit mplayer fullscreen mode. The lock is swamped with tons of > nouveau

Re: [Nouveau] [PATCH] nvc0/ir: propagate immediates to CALL input MOVs

On Sat, Aug 12, 2017 at 3:33 PM, Tobias Klausmann wrote: > On using builtin functions we have to move the input to registers $0 and $1, > if > one of the input value is an immediate, we fail to propagate the immediate: > > ... > mov u32 $r477 0x0003 (0)

[Nouveau] [PATCH] pci/msi: disable MSI on big-endian platforms by default

=NvMSI=1 on load. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> Cc: sta...@vger.kernel.org --- drm/nouveau/nvkm/subdev/pci/base.c | 4 1 file changed, 4 insertions(+) diff --git a/drm/nouveau/nvkm/subdev/pci/base.c b/drm/nouveau/nvkm/subdev/pci/base.c index eb9b2781..a4cb8249

[Nouveau] [PATCH 4/4] drm/nouveau/dispnv04: fix exposed format list

, as tested with modetest. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 36 - 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/di

[Nouveau] [PATCH 3/4] drm/nouveau/overlay: add NV21 support

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c b/drivers/gpu/drm/nouveau/dispnv04/overlay.c index 5bd63c2f14a6..c8c233

[Nouveau] [PATCH 2/4] drm/nouveau/overlay: improve error detection, fix pitch setting

. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 62 -- 1 file changed, 34 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c b/drivers/gpu/drm/nouveau/dispnv04/overlay.c

[Nouveau] [PATCH 1/4] drm/nouveau/display: prevent undisplayable framebuffers from creation

Pre-nv50 YUV overlays have stringent requirements for working with the internal machinery. Instead of rejecting these at update_plane time, we should instead prevent the framebuffers from being created in the first place. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/g

[Nouveau] [PATCH 0/4] Overlay / format improvements

modest modetest testing on NV5, NV17, NV34, and NV4A. I noticed some odd issues on NV5 with certain scaling factors, but I'm somewhat sure that those issues were there before - either the hw can't keep up or we're not twiddling some clocks. Ilia Mirkin (4): drm/nouveau/display: prevent

[Nouveau] [PATCH] drm/nouveau/mpeg: print more debug info when rejecting dma objects

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- This was helpful when debugging our earlier mpeg woes. May as well have it upstream. drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c | 7 ++- drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv40.c | 7 ++- 2 files changed, 12 inse

Re: [Nouveau] [RFC PATCH 12/13] clk: parse thermal policies for throttling thresholds

On Fri, Jul 21, 2017 at 5:55 PM, Karol Herbst wrote: > Signed-off-by: Karol Herbst > --- > drm/nouveau/include/nvkm/subdev/clk.h | 2 ++ > drm/nouveau/nvkm/subdev/clk/base.c| 42 > +++ > 2 files changed, 44

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

I believe the solution is to not call drm_crtc_vblank_off for atomic modesetting in nouveau_display_fini. I think Ben's working on it. On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann wrote: > mimic the behavior of vblank_disable_fn(), another caller of >

Re: [Nouveau] [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote: > Greetings, > > box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside > kernel: master.today (v4.12-11690-gccd5d1b91f22) > > lspci -nn -d 10de: > 01:00.0 VGA compatible controller [0300]: NVIDIA

Re: [Nouveau] [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

On Sat, Jul 15, 2017 at 12:14 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith <efa...@gmx.de> wrote: >> Greetings, >> >> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside >> kernel:

Re: [Nouveau] [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote: > Greetings, > > box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside > kernel: master.today (v4.12-11690-gccd5d1b91f22) > > lspci -nn -d 10de: > 01:00.0 VGA compatible controller [0300]: NVIDIA

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann wrote: > The conversion is a nice catch, but i'd like to have a bit more context, see > below! > > With a better description: > > Tobias Klausmann I don't think it was

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith wrote: > On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote: >> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE >> usage we could convert to WARN_ONCE? > > Shooting the messenger is generally considered uncool

Re: [Nouveau] [PATCH xf86-video-amdgpu] Adapt to PixmapDirtyUpdateRec::src being a DrawablePtr

On Thu, Jul 13, 2017 at 10:14 PM, Michel Dänzer <mic...@daenzer.net> wrote: > On 13/07/17 09:31 PM, Ilia Mirkin wrote: >> On Thu, Jul 13, 2017 at 4:27 AM, Michel Dänzer <mic...@daenzer.net> wrote: >>> On 18/04/17 07:07 PM, Michel Dänzer wrote: >>>> F

Re: [Nouveau] [PATCH xf86-video-amdgpu] Adapt to PixmapDirtyUpdateRec::src being a DrawablePtr

On Thu, Jul 13, 2017 at 4:27 AM, Michel Dänzer wrote: > On 18/04/17 07:07 PM, Michel Dänzer wrote: >> From: Michel Dänzer >> >> Signed-off-by: Michel Dänzer >> --- >> >> Chris / Ilia / Ben, this should be manageable for the

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efa...@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 no

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith <efa...@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]:

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Some details that may be useful in analysis of the bug: 1. lspci -nn -d 10de: 2. What displays, if any, you have plugged into the NVIDIA board when this happens? 3. Any boot parameters, esp relating to ACPI, PM, or related? Cheers, -ilia On Tue, Jul 11, 2017 at 1:32 PM, Mike Galbraith

Re: [Nouveau] [PATCH] disp/gf119-: avoid creating non-existent heads

On Mon, Jul 3, 2017 at 6:02 PM, Ben Skeggs <skeg...@gmail.com> wrote: > On 07/04/2017 03:06 AM, Ilia Mirkin wrote: >> We assume that each board has 4 heads for GF119+. However this is not >> necessarily true - in the case of a GP108 board, the register indicated >

[Nouveau] [PATCH] initial support (display-only) for GP108

Forked from GP107 implementation. Secboot/gr left out as we don't have signed blobs from NVIDIA in linux-firmware. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nouveau/nvkm/engine/device/base.

[Nouveau] [PATCH] disp/gf119-: avoid creating non-existent heads

We assume that each board has 4 heads for GF119+. However this is not necessarily true - in the case of a GP108 board, the register indicated that there were only 2. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101601 Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --

[Nouveau] [PATCH] disp/nv50-: bump max chans to 21

GP102's cursors go from chan 17..20. Increase the array size to hold their data properly. Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices") Cc: sta...@vger.kernel.org # v4.10+ Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drm/nou

Re: [Nouveau] [PATCH v4] nv110/exa: update sched codes

BTW, you can drop those explicit "depbar" ops. I think they're only needed when you're doing something weird with barriers. Blob doesn't use them (anymore) On Tue, Jun 27, 2017 at 11:16 AM, Aaryaman Vasishta wrote: > v4: Updated the wait dependancy bars based on tex

Re: [Nouveau] [Bug 99900] nouveau: freeze / crash after kernel update to 4.10

On Tue, Jun 20, 2017 at 12:54 PM, Olof Johansson wrote: > Hey, > > This was reported back in February and it seems nobody's given a shit? > Apparently not -- including you. Someone who was interested in seeing this issue fixed would certainly have provided a kernel bisection

Re: [Nouveau] speed of card?

On Mon, Jun 19, 2017 at 1:32 PM, James <bjloc...@lockie.ca> wrote: > On 2017-06-19 01:18 PM, Ilia Mirkin wrote: >> cat /sys/kernel/debug/dri/0/pstate >> >> AC (or DC) line shows the current state. >> >> On Mon, Jun 19, 2017 at 1:00 PM, James <bjloc...@

Re: [Nouveau] speed of card?

cat /sys/kernel/debug/dri/0/pstate AC (or DC) line shows the current state. On Mon, Jun 19, 2017 at 1:00 PM, James wrote: > I have a NVE7 (GK107). > How do I see the current memory/CPU speed? > > > > ___ > Nouveau mailing list >

Re: [Nouveau] [PATCH v3] nv110/exa: update sched codes

On Mon, Jun 19, 2017 at 11:22 AM, Aaryaman Vasishta <jem456.vasis...@gmail.com> wrote: > Sorry for the late response, been busy with some personal stuff + work... > > On Tue, Jun 13, 2017 at 6:52 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> >> On Mon, Jun 12,

Re: [Nouveau] [Mesa-dev] [RFC 0/9] Add precise/invariant semantics to TGSI

On Mon, Jun 12, 2017 at 7:57 PM, Roland Scheidegger wrote: > FWIW surely on nv50 you could keep a single mad instruction for umad > (sad maybe too?). (I'm actually wondering if the hw really can't do > unfused float multiply+add as a single instruction but I know next to >

Re: [Nouveau] [PATCH v3] nv110/exa: update sched codes

On Mon, Jun 12, 2017 at 5:46 PM, Samuel Pitoiset wrote: > > > On 06/10/2017 09:14 AM, Aaryaman Vasishta wrote: >> >> See the 'wt' on the first fmul in exacanv110.fp, exacmnv110.fp and >> exasanv110.fp. Any ideas on what could be causing the first fmul to require >> $r0

Re: [Nouveau] k2000m and only one setting for core ?

What kernel are you using? On Mon, Jun 12, 2017 at 1:02 PM, Attila Tóth wrote: > dmesg > > > [ 9007.285922] nouveau :01:00.0: volt: couldn't set 887500uv > [ 9007.285930] nouveau :01:00.0: clk: failed to raise voltage: -22 > [ 9007.285933] nouveau :01:00.0: clk:

Re: [Nouveau] Rendering issues with KDE (GeForce 7150M/nForce 630M)

On Wed, May 31, 2017 at 10:00 AM, adlo <adloco...@gmail.com> wrote: > On Wed, May 31, 2017 at 12:46 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> >> I think all the common distros have pretty much stopped caring (if >> they ever did) about allowing users to re

Re: [Nouveau] Rendering issues with KDE (GeForce 7150M/nForce 630M)

I think all the common distros have pretty much stopped caring (if they ever did) about allowing users to reasonably operate their default environments with hardware that has imperfect 3D drivers. Please use environments that don't require 3D for regular operation on such boards. -ilia On

Re: [Nouveau] GTX 1080 Ti (NV132/GP102)

On Thu, May 25, 2017 at 12:08 PM, Shahar Or wrote: > Thanks for the info. Two issues: > > If I don't set `nomodeset` in the Linux args I get a freeze at boot. Know > anything about that? "nomodeset" is another way of saying "disable all graphics stuff". Since

Re: [Nouveau] GTX 1080 Ti (NV132/GP102)

, Shahar Or <mightyiamprese...@gmail.com> wrote: > "should be supported" sounds promising. Do you know since what version of > what things it "should be supported", please? > > On Wed, May 24, 2017 at 6:04 PM Ilia Mirkin <imir...@alum.mit.edu> wrote: >&g

Re: [Nouveau] GTX 1080 Ti (NV132/GP102)

GP102 should be supported. Depending on what you're looking for to be supported, your distribution may not be shipping the required versions of various software. On Wed, May 24, 2017 at 5:52 AM, Shahar Or wrote: > Hey, I am experiencing some issues in Ubuntu 17.10

[Nouveau] [RFC PATCH 3/3] drm/nouveau/dispnv04: fix exposed format list

, as tested with modetest. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 36 - 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/di

[Nouveau] [RFC PATCH 1/3] drm/nouveau/overlay: improve error detection, fix pitch setting

. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 80 +++--- 1 file changed, 52 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c b/drivers/gpu/drm/nouveau/dispnv04/overlay.c

[Nouveau] [RFC PATCH 3/3] drm/nouveau/dispnv04: fix exposed format list

, as tested with modetest. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 36 - 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/di

[Nouveau] [RFC PATCH 2/3] drm/nouveau/overlay: add NV21 support

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c b/drivers/gpu/drm/nouveau/dispnv04/overlay.c index ee7df9ef2695..96354a

[Nouveau] [RFC PATCH 0/3] drm/nouveau/dispnv04 overlay and primary fb format fixes

n't at all tested on my NV05 or NV1x hardware. Should probably do that before we push this out. But since I've already been sitting on these patches for a few weeks, thought I'd get them out there. Ilia Mirkin (3): drm/nouveau/overlay: improve error detection, fix pitch setting drm/nouveau/overlay

[Nouveau] [RFC PATCH 0/3] drm/nouveau/dispnv04 overlay and primary fb format fixes

n't at all tested on my NV05 or NV1x hardware. Should probably do that before we push this out. But since I've already been sitting on these patches for a few weeks, thought I'd get them out there. Ilia Mirkin (3): drm/nouveau/overlay: improve error detection, fix pitch setting drm/nouveau/overlay

[Nouveau] [RFC PATCH 2/3] drm/nouveau/overlay: add NV21 support

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c b/drivers/gpu/drm/nouveau/dispnv04/overlay.c index ee7df9ef2695..96354a

[Nouveau] [RFC PATCH 1/3] drm/nouveau/overlay: improve error detection, fix pitch setting

. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 80 +++--- 1 file changed, 52 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c b/drivers/gpu/drm/nouveau/dispnv04/overlay.c

Re: [Nouveau] regression? no more separate xscreens

On Wed, May 10, 2017 at 4:20 AM, Sampsa Riikonen wrote: > Dear Devs, > > The support for multiple xscreens (i.e. no xinerama, just separate :0.0 and > :0.1 displays) in nouveau is broken. Here's a free piece of advice - before declaring things as broken, consider the

Re: [Nouveau] multiple cards and monitors with xrandr and opengl

On Tue, May 9, 2017 at 11:43 AM, Sampsa Riikonen wrote: > I am a bit confused that the name is not "Intel" and/or "nouveau".. > and "modesetting" is a kernel module that finds display modes, right? > > (Q2) Am I doing something wrong here? No. You are using a distribution

Re: [Nouveau] GM206 [GeForce GTX 960] with 4k display

Would be nice if you could "bisect" those, i.e. which one matters? Or do they both have to be there to have the desired effect? On Mon, May 8, 2017 at 11:52 PM, Karl Schmidt wrote: > I was getting a glicthy checkerboard mess at the cursor in some programs > (konsol+) with > #

Re: [Nouveau] GT 730 freeze : how do diagnose / debug ?

On Mon, May 8, 2017 at 7:50 AM, Vincent Vanackere wrote: > Alternatively if you know of a fanless graphic card model that would be able > to drive 2 monitors at 2560x1440 with proper linux support, I'm interested ;-) Anything made by AMD will likely work well on

Re: [Nouveau] GT 730 freeze : how do diagnose / debug ?

You have two issues: (a) nouveau's GL driver messed something up, causing a read fault error (b) nouveau's kernel driver tried to recover. It failed. Solution to #1: None, really. You can try updating mesa, and hope it helps. Not sure what version you're on. Solution to #2: Ben Skeggs will

Re: [Nouveau] multiple cards and monitors with xrandr and opengl

On Sun, May 7, 2017 at 7:17 AM, Sampsa Riikonen wrote: > Dear Devs, > > We have achieved a desktop of up to six monitors, with openGL running > succesfully on the desktop, with the following setup/features: > > * Ubuntu 16+ > * Xrandr > * Noveau driver > * Two gtx750

Re: [Nouveau] NV130 - gtx 1050 ti

On Sat, May 6, 2017 at 5:32 PM, Karl Schmidt wrote: > So I'm guessing that nouveau computes the modelines from the combination of > what the card and edid claim they support. With some limitations, it will take the list of modelines in the EDID (which, mind you, might be just

Re: [Nouveau] NV130 - gtx 1050 ti

First things first -- I've alluded to this before, but let me be clear -- there is no global database that contains monitor-specific information which is used by any linux drivers. Please forget any notions you had of such a thing existing or being used. The information comes from the EDID blob

Re: [Nouveau] NV130 - gtx 1050 ti

On May 4, 2017 6:44 PM, "Karl Schmidt" wrote: On 05/04/2017 04:00 AM, Pierre Moreau wrote: > Hello, > > Acceleration for Pascal cards is coming in Linux 4.12, support for Pascal > cards > in xorg-video-nouveau is in 1.0.15, and if I remember correctly, on the > Mesa-side, you

Re: [Nouveau] [PATCH v2] nv50/ir: optimize shl(a, 0) to a

On Apr 30, 2017 8:14 AM, "Karol Herbst" <karolher...@gmail.com> wrote: 2017-04-30 2:28 GMT+02:00 Ilia Mirkin <imir...@alum.mit.edu>: > Maybe in a separate change. I'd want to double check on all gens. I think > the thing I suggested is sufficient. > well, if I ju

Re: [Nouveau] [PATCH v2] nv50/ir: optimize shl(a, 0) to a

Maybe in a separate change. I'd want to double check on all gens. I think the thing I suggested is sufficient. On Apr 29, 2017 8:09 PM, "Karol Herbst" <karolher...@gmail.com> wrote: 2017-04-30 0:28 GMT+02:00 Ilia Mirkin <imir...@alum.mit.edu>: > On Sat, Apr 29, 2017

Re: [Nouveau] [PATCH v2] nv50/ir: optimize shl(a, 0) to a

0 0 0 > > v2: handle potential mods on src0 > > Signed-off-by: Karol Herbst <karolher...@gmail.com> > Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> > Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu> > --- > src/gal

Re: [Nouveau] [PATCH] nv50/ir: optimmize shl(a, 0) to a

r(0)) > break; Interesting. This suggests that src(0) may have modifiers, although I can't imagine what that'd be. Perhaps it can take a neg? In that case, you need to fix the OP_MOV above -- should probably do it anyways, i.e. i->op = i->src(0).mod.getOp() or something. With

Re: [Nouveau] [PATCH] nv50/ir: we can't replace 0x0 with zero reg for SHLADD

On Sat, Apr 29, 2017 at 10:41 AM, Karol Herbst wrote: > fixes a crash in Alien Isolation What crash? How did the zero get there? Does this only happen if you do your optimization loop thing? In either case, we still want the replaceZero() logic. However that logic should

Re: [Nouveau] [PATCH v2 4/5] nouveau_hwmon: Add support for auto_point attributes

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > This patch creates a special group attributes for attrs like "*auto_point*". > We check if we have support for them, and if we do, we gather them all in > an attribute_group's structure which is the parameter

Re: [Nouveau] [PATCH v2 2/5] nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string

On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > +static char *input_label = "GPU core"; This needs to be static const char input_label[] = "GPU core"; or at least static const char *const input_label = "GPU core"; -ilia

Re: [Nouveau] [PATCH v2 1/5] nouveau_hwmon: Add config for all sensors and their settings

All kernel patches must have a Signed-off-by: $user. See https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador wrote: > This is a preparation for

Re: [Nouveau] [PATCH v3 10/10] drm/nouveau: Enable stereoscopic 3D output over HDMI

On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater wrote: > Enable stereoscopic output for HDMI and DisplayPort connectors on > NV50+ (G80+) hardware. We do not enable stereoscopy on older > hardware in case there is some older board that still has HDMI >

Re: [Nouveau] [PATCH v2 2/3] nv50/ir: handle logops with NOT in AlgebraicOpt

On Mon, Apr 3, 2017 at 11:58 AM, Karol Herbst wrote: > Signed-off-by: Karol Herbst > --- > src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git

Re: [Nouveau] [PATCH v2 1/3] nv50/ir: fix AlgebraicOpt for slcts with mods

On Mon, Apr 3, 2017 at 11:58 AM, Karol Herbst wrote: > Signed-off-by: Karol Herbst > --- > src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git

<    1   2   3   4   5   6   7   8   9   10   >