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] 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] [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] 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 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] 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 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,

[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] [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] 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] 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

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] [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] 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] 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] [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] 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

[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] 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] 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

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 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] 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] 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] [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

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

Re: [Nouveau] libGL error messages

On Tue, Jun 12, 2018 at 9:09 PM, 積丹尼 Dan Jacobson wrote: >>>>>> "IM" == Ilia Mirkin writes: > > IM> OK, well 18.1.0 is completely busted for those GPU's. Either upgrade > IM> or downgrade. But don't use that release. > > I did > [DOWNGRADE] l

Re: [Nouveau] Giving a hand to Nouveau

On Sun, Jun 17, 2018 at 8:50 PM, Yoann LE BARS wrote: > > Hello everybody out there! > > Well, I just subscribed to this mailing list, so I guess I should > introduce myself, at least giving relevant information about me > concerning the development of Nouveau. > > You can call me

Re: [Nouveau] no mouse cursor on nv50

Lyude bisected a similar problem on a much newer GPU to this very same change as well. [Sorry, no useful information beyond that, but thought I'd make the connection.] On Sun, Jun 17, 2018 at 5:46 PM, Adam Borowski wrote: > Hi! > On v4.18-rc1, the mouse cursor is missing on my right monitor. >

Re: [Nouveau] libGL error messages

Are you on mesa 18.1.0 and using a nv3x/nv4x gpu? If so, update to 18.1.1. If not, provide more information. The error is that nouveau_dri.so can't be loaded, which means you're not getting acceleration. You can also make the error go away by sticking LIBGL_ALWAYS_SOFTWARE=1 into your environment

Re: [Nouveau] libGL error messages

On Mon, Jun 11, 2018 at 1:32 PM, 積丹尼 Dan Jacobson wrote: > # lspci | grep ' VGA ' | cut -d" " -f 1 | xargs -i lspci -v -s {} > 00:05.0 VGA compatible controller: NVIDIA Corporation C51G [GeForce 6100] > (rev a2) (prog-if 00 [VGA controller]) That's a NV4C or NV4E (i.e. nv4x). > I.e., no 18.1.1

Re: [Nouveau] can't join the list via email

Where did you see instructions for doing this? Apparently this is disabled on purpose due to spam. Or did you just assume it would work based on other mailman lists? On Mon, Jun 11, 2018 at 1:08 PM, Dan Jacobson wrote: > Can't join the list confirming via email. > Will get: > >

Re: [Nouveau] ERROR:gl_surface_presentation_helper.cc(115)] GetVSyncParametersIfAvailable() failed!

Did you accidentally send this to the nouveau list instead of the chromium one? On Tue, Jun 19, 2018 at 10:09 AM, 積丹尼 Dan Jacobson wrote: > chromium prints thousands of > [1886:1886:0619/220640.036283:ERROR:gl_surface_presentation_helper.cc(115)] > GetVSyncParametersIfAvailable() failed! >

Re: [Nouveau] [PATCH][next] drm/nouveau/disp: avoid potential overflow on shift of int value

On Sun, May 27, 2018 at 5:54 PM, Colin King wrote: > From: Colin Ian King > > The constant values being shifted are 32 bit integers and may potentially > overflow on the shift. Avoid this potential overflow by making them > unsigned long long

Re: [Nouveau] [bug report] drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts

On Tue, Jun 26, 2018, 04:49 Dan Carpenter wrote: > Hello Ben Skeggs, > > The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel > interfaces to control error interrupts" from May 8, 2018, leads to > the following static checker warning: > >

Re: [Nouveau] libva problem?

On Tue, May 1, 2018 at 6:16 PM, James <bjloc...@lockie.ca> wrote: > On 2018-05-01 06:00 PM, Ilia Mirkin wrote: >> On Tue, May 1, 2018 at 5:53 PM, James <bjloc...@lockie.ca> wrote: >>> I am playing videos from my lubuntu computer to my tv through the hdmi

Re: [Nouveau] libva problem?

What GPU do you have? For video acceleration (i.e. va-api and vdpau), did you install the necessary firmware? On Tue, May 1, 2018 at 5:53 PM, James wrote: > I am playing videos from my lubuntu computer to my tv through the hdmi > interface on my video card. > It mostly works.

Re: [Nouveau] Nouveau Digest, Vol 131, Issue 3

On Thu, Mar 8, 2018 at 11:29 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner >> <mario.kleiner...@gmail.com> wrote: >>>

[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]

[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] [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

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

On Sun, Dec 31, 2017 at 2:23 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > Not clear what the depth % 8 was trying to protect against, but it was > breaking 30bpp visuals with DRI3. Erm, actually switching to my test config which doesn't enable dri3 is what "fixed" things

Re: [Nouveau] nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On Tue, Dec 19, 2017 at 8:45 AM, Christian König wrote: > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: >> >> On 2017-12-19 11:37 AM, Michel Dänzer wrote: >>> >>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: On 12/18/17 7:06 PM, Mike Galbraith wrote:

Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

On Thu, Jan 25, 2018 at 8:47 AM, Luís Mendes wrote: > Sorry for alI these individual emails, but I think is more readable > this way, by having each independent information in a separate email. > > I also have these additional cards that I can try: Gefoce GT 1030 and >

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

On Sun, Dec 31, 2017 at 2:35 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Sun, Dec 31, 2017 at 2:23 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> Not clear what the depth % 8 was trying to protect against, but it was >> breaking 30bpp visuals with DRI3. > &

[Nouveau] [PATCH 1/2] 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. Add it in to ensure that bitsPerPixel % 8 is 0, since there is plenty of bpp/8 math in the driver. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/nouveau_dri2.c | 5 -

[Nouveau] [PATCH 2/2] nv50/xv: add support for depth 30 xv output

Ostensibly it should probably be looking at the pixmap format. However it's always the window pixmap, so we can assume it's what we expect. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/nouveau_xv.c | 11 +-- src/nv50_xv.c| 3 ++- src/nvc0_xv.c| 3 ++- 3

[Nouveau] nouveau 30bpp / deep color status

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:

Re: [Nouveau] swiotlb buffer is full

Yeah, a lot of people were getting that, as a result of some drm/ttm hugepage usage. Christian, did a fix ever end up going out? If so, what kernel was it included in? -ilia On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez wrote: > Hello, > > I've noticed

Re: [Nouveau] nouveau 30bpp / deep color status

On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote: >> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote: >> > In case anyone's curious about 30bpp fra

[Nouveau] [PATCH] dri3: don't check permissions on render node

The permission check fails if udev sets the render node to 0666 but leaves the card at 0660, as is done in at least udev-236. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- src/nouveau_dri2.c | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote: >> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: > > NV5 in another PC (secondary card in x86-64) made the systrem crash on > boot, in nvkm_therm_clkgate_fini. Mind booting with nouveau.debug=trace?

Re: [Nouveau] 4.16-rc1: UBSAN warning in nouveau/nvkm/subdev/therm/base.c + oops in nvkm_therm_clkgate_fini

On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos <mr...@linux.ee> wrote: >>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: >> >> NV5 in another PC (secondary ca

Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

Daniel Vetter <dan...@ffwll.ch> > Cc: nouveau@lists.freedesktop.org > Cc: Ben Skeggs <bske...@redhat.com> > Cc: Ilia Mirkin <imir...@alum.mit.edu> > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> s/standarad/standard/ in subject I'd like the oppor

Re: [Nouveau] nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith <efa...@gmx.de> wrote: > On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote: >> On Tue, Dec 19, 2017 at 8:45 AM, Christian König >> <ckoenig.leichtzumer...@gmail.com> wrote: >> > Am 19.12.2017 um 11:39 schrieb M

Re: [Nouveau] Hard lock with 4.14.0-2

Did anything change other than the kernel version? What was the previous kernel version? On Tue, Jan 2, 2018 at 2:43 PM, Daniel Boyd wrote: > I am running Debian testing and updated my system this morning which > included a new kernel: 4.14.0.2-amd64 > > After this

Re: [Nouveau] Hard lock with 4.14.0-2

On Tue, Jan 2, 2018 at 4:26 PM, Daniel Boyd wrote: > Previous kernel was 4.13.0-10.1-liquorix-amd64 > > The updated kernel that I'm having trouble was not liquorix -- was > straight from Debian. > > Here's my apt log: Yeah, unfortunately I'm not sure how to read that. But

Re: [Nouveau] [PATCH v3 5/6] kms/nv50: detect HDMI max MHz correctly

On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst wrote: > v2: clean up left over comments > don't overwrite hdmimhz parameter > cap to 297MHz > > Signed-off-by: Karol Herbst > --- > drm/nouveau/dispnv50/disp.c | 5 + > drm/nouveau/nouveau_connector.c | 15 ++- >

Re: [Nouveau] newbe guidance for Alienware 13

GP106 is supported, you must be using an older kernel (since yours says "unknown chipset"). Note that mobile chips, esp GP10x's, appear to have a ton of issues with runtime pm, so YMMV. On Sat, Aug 4, 2018 at 7:37 PM, don fisher wrote: > I had desire for a light laptop, so purchased an Alienware

Re: [Nouveau] [PATCH v6 3/5] drm/nouveau: Fix deadlock with fb_helper with async RPM requests

On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote: > +bool > +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon) > +{ > + bool hotplug; > + > + if (!fbcon) > + return false; > + > + mutex_lock(>hotplug_lock); > + hotplug =

Re: [Nouveau] [PATCH 5/6] kms/nv50: detect HDMI max MHz correctly

This removes user control to force a hdmimhz. Given the vast variety of hardware and display configurations out there, I don't see how a patch like this won't blow up in our faces. I'm not saying we shouldn't do it -- we should attempt to respect the various maximums in the vbios, but until we

Re: [Nouveau] Questions Conscerning Pascal ISA and IPA Instruction

IPA is to interpolate an input in a fragment shader. Have a look at OP_LINTERP / OP_PINTERP in codegen (https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/). Also feel free to ask specific questions in #nouveau on irc.freenode.net. Cheers, -ilia On Sat, Sep 1,

Re: [Nouveau] TLD instruction usage in non-linked sampler mode

in the entry in slot #0: as I > understand it, the one piece of sampler state that will influence TLD > is sRGBConversion (bit 13). > > I hope that helps, > - Andy > > > On Thu, Mar 01, 2018 at 11:47:18PM -0500, Ilia Mirkin wrote: >> Hello, >> >> This que

Re: [Nouveau] [PATCH] Fix colormap handling at screen depth 30.

NVLoadPalette is pretty hard-coded to 256. I haven't looked at what all xf86HandleColormaps does, but it seems pretty suspicious. Also note that the kernel currently only exposes a 256-sized LUT to userspace, even for 10bpc modes. On Thu, Mar 1, 2018 at 1:31 AM, Mario Kleiner

Re: [Nouveau] nouveau 30bpp / deep color status

On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner <mario.kleiner...@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...@gmail.com>

Re: [Nouveau] Nouveau Digest, Vol 131, Issue 3

On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner > <mario.kleiner...@gmail.com> wrote: >> On 03/03/2018 12:59 AM, Ilia Mirkin wrote: >>> >>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Klei

Re: [Nouveau] nouveau TRAP_M2MF still there on G98

On Wed, Apr 4, 2018 at 6:58 PM, Adam Borowski wrote: > On Wed, Apr 04, 2018 at 03:48:39PM +0300, Māris Nartišs wrote: >> 2018-04-03 23:00 GMT+03:00, Adam Borowski : >> > In commit da5e45e619b3f101420c38b3006a9ae4f3ad19b0 >> > >> > yet it is still

[Nouveau] [PATCH] drm/nouveau: fix temp/pwm visibility, skip hwmon when no sensors exist

A NV34 GPU was seeing temp and pwm entries in hwmon, which would error out when read. These should not have been visible, but also the whole hwmon object should just not have been registered in the first place. Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> --- drivers/gpu/drm/n

Re: [Nouveau] nouveau 30bpp / deep color status

On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner <mario.kleiner...@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: >> >> Kernel: >> >> Ben an

Re: [Nouveau] Nouveau Digest, Vol 131, Issue 3

On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner <mario.kleiner...@gmail.com> wrote: > On 03/03/2018 12:59 AM, Ilia Mirkin wrote: >> >> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner >> <mario.kleiner...@gmail.com> wrote: >>> >>> On 03/02/2018

Re: [Nouveau] Nouveau Digest, Vol 131, Issue 3

On Fri, Mar 2, 2018 at 5:16 PM, Mario Kleiner <mario.kleiner...@gmail.com> wrote: > On 03/01/2018 07:21 PM, nouveau-requ...@lists.freedesktop.org wrote: >> >> >> Message: 1 >> Date: Thu, 1 Mar 2018 08:15:55 -0500 >> From: Ilia Mirkin <imir...@alum.mi

Re: [Nouveau] Nouveau Digest, Vol 131, Issue 3

On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner <mario.kleiner...@gmail.com> wrote: > On 03/02/2018 11:29 PM, Ilia Mirkin wrote: >> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set >> still only gets called with a 256-entry LUT? If so, that

Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala > <ville.syrj...@linux.intel.com> wrote: >> From: Ville Syrjälä <ville.syrj...@linux.intel.com> >> >> Replace the ad-hoc

[Nouveau] TLD instruction usage in non-linked sampler mode

Hello, This question is in the context of Tesla / Fermi generations, which have explicit bindings for textures / samplers. It might also apply to Kepler+, not quite as sure due to the bindless nature. I've been trying to understand how the TLD operation works (which is used to implement

Re: [Nouveau] 8K HEVC decoding with NVIDIA GeForce GTX 1060

On Fri, Oct 19, 2018 at 8:53 AM 孫偉程 wrote: > I can imagine there is a long way to go to fulfill my requirements. But I > know a driver for my NVIDIA card is a must for the hardware decoder to work. > Can somebody shed some lights that if I want to play an 8K HEVC encoded video > on Android-x86

Re: [Nouveau] Question on Render Targets Register: Array Mode

On Sat, Oct 13, 2018 at 5:40 PM Fernando Sahmkow wrote: > > So there's a register in Render Targets called Array Mode: > https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L289 > > We've witnessed values of 1 and 6 (array mode -> layers) but we can't tell > their

Re: [Nouveau] Questions on Blocklinear Mipmaps and auto-sizing

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c#n190 On Thu, Oct 25, 2018 at 6:30 AM Fernando Sahmkow wrote: > > I'm currently implementing mipmaps but I have a set of troubles guessing the > block height and block depth of them. According to >

Re: [Nouveau] Question on IPA on GM107

On Mon, Nov 12, 2018 at 6:11 PM Fernando Sahmkow wrote: > > So I'm trying to track an special value in IPA instruction generation. > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp#L2561 > > Register on 0x14 (20) is set to some source on

Re: [Nouveau] [PATCH] drm/nouveau: tegra: Initialize mode configuration

On Wed, Nov 7, 2018 at 10:34 AM Thierry Reding wrote: > > On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote: > > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > Irrespective of whether or not the device has any usable outputs,

[Nouveau] [PATCH] drmmode: update logic for dynamic connectors, paths, and tiles

This largely copies the code from modesetting with minor adjustments. Signed-off-by: Ilia Mirkin --- I've tested this back and forth with a GTX 960 + 2x U2415 monitors, chained to each other. I turned them on/off. I messed with their DP 1.1/1.2 settings. I pulled plugs a few times. This seems

[Nouveau] [PATCH 4/5] drm/nouveau/disp: add support for setting scdc parameters for high modes

When SCDC is supported, make sure that we configure the GPU and monitor to the same parameters. Signed-off-by: Ilia Mirkin --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 40 - 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau

[Nouveau] [PATCH 2/5] drm/nouveau/disp/gm200-: add scdc parameter setter

Signed-off-by: Ilia Mirkin --- drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 + .../gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 34 ++ drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 2 ++ .../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 1 + .../gpu

[Nouveau] [PATCH 3/5] drm/nouveau/disp: keep track of high-speed state, program into clock

The register programmed by the clock method needs to contain a different setting for the link speed as well as special divider settings. Signed-off-by: Ilia Mirkin --- drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 2 ++ drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 5

[Nouveau] [PATCH 1/5] drm/nouveau/disp: add a way to configure scrambling/tmds for hdmi 2.0

High pixel clocks are required to use a 40 TMDS divider instead of 10, and even low ones may optionally use scrambling depending on device support. Signed-off-by: Ilia Mirkin --- drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 5 - drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h

[Nouveau] [PATCH 0/5] drm/nouveau: add basic HDMI 2.0 support

t at least it works a little bit! Note that I have limited testing equipment, but I did verify that a GM204 trace referred to the same register for controlling scrambling. I may get access to a GM206 later in the week to verify there. Ilia Mirkin (5): drm/nouveau/disp: add a way to configure scram

[Nouveau] [PATCH 5/5] drm/nouveau/disp: take sink support into account for exposing 594mhz

Scrambling is required for supporting any mode over 340MHz. If it's not supported, reject any modes that would require it. Signed-off-by: Ilia Mirkin --- drivers/gpu/drm/nouveau/nouveau_connector.c | 34 +++-- 1 file changed, 22 insertions(+), 12 deletions(-) diff --git

Re: [Nouveau] Textures Twiddling/Swizzling

Swizzling is implemented by the hardware. Nouveau doesn't implement it directly -- we just blit from a linear surface into a swizzled surface. Ideally you should be able to ignore swizzling entirely. However if an application uploads pre-swizzled data, you have to deal with it. This isn't

Re: [Nouveau] Strange monitor behavior on forced DVI-D output

On Sun, Sep 23, 2018 at 12:26 PM, Wolfgang Rißler wrote: > I try to send a friendly ping to my problem. > At the moment I'm running at 1600x1200 (monitor than has 1600x1200 > too), what looks better then 1920x1200 picture on that Monitor with > 960x1200. > I cant get 1920x1200 working, but I'm

Re: [Nouveau] Strange monitor behavior on forced DVI-D output

On Sun, Sep 23, 2018 at 1:48 PM, Wolfgang Rißler wrote: > Am Sonntag, den 23.09.2018, 12:55 -0400 schrieb Ilia Mirkin: >> On Sun, Sep 23, 2018 at 12:26 PM, Wolfgang Rißler >> wrote: > [snip] >> >> That's not extremely surprising ... force-enabling an output I thin

Re: [Nouveau] Nouveau module results in total lockups without any dmesg trace on a NP900X5N Kaby Lake machine

On Tue, Jan 1, 2019 at 4:06 PM Jan Vlietland wrote: > > Hi Ben, David and Daniel , > > First of all happy new year. Based on advice of Greg K-H herewith a mail > about a number of Nouveau issues with my laptop. > > I installed various Kali linux versions up to Linux 4.20.0-rc7 > (downloaded,

Re: [Nouveau] Nouveau module X server not starting on a NP900X5N Kaby Lake machine

On Tue, Jan 1, 2019 at 5:30 PM Jan Vlietland wrote: > > Hi Ilia, many thanks for answering my mail. > > Tonight I tried to see what happens if I generate a xorg.conf file and place > it in /etc/X11/xorg.conf, as described here: >

Re: [Nouveau] [PATCH] drm/nouveau: Don't disable polling in fallback mode

Ben - ping? Just ran into this myself on a NV42. On Wed, Nov 14, 2018 at 11:01 AM Takashi Iwai wrote: > > On Fri, 14 Sep 2018 13:59:25 +0200, > Martin Peres wrote: > > > > On 14/09/2018 10:28, Ben Skeggs wrote: > > > On Wed, 12 Sep 2018 at 20:59, Takashi Iwai wrote: > > >> > > >> When a fan is

Re: [Nouveau] Chromium - Application-level nouveau blacklist

On Sat, Jan 5, 2019 at 10:36 PM K. York wrote: > > > Opinions welcome. > > I have a few ideas on the best way to approach this. > > - First of all, obviously, fix the WebGL CTS problems. (with > --ignore-gpu-blacklist ) > - Fix all other crashing issues and request re-inclusion. (This is >

[Nouveau] Chromium - Application-level nouveau blacklist

It looks like as of Chromium 71, nouveau is completely blacklisted. I don't really see a way back from this, since they don't cite any easily reproducible issues, except that some people had some issues with indeterminate hardware and indeterminate versions of mesa. In the bug that triggered

<    6   7   8   9   10   11   12   13   14   >