[Nouveau] [Bug 91319] Nouveau driver cannot extract FCODE ROM / DCB Block from OpenFirmware Device tree
https://bugs.freedesktop.org/show_bug.cgi?id=91319 Peter Saisanas psaisa...@gmail.com changed: What|Removed |Added CC||psaisa...@gmail.com --- Comment #1 from Peter Saisanas psaisa...@gmail.com --- Created attachment 117085 -- https://bugs.freedesktop.org/attachment.cgi?id=117085action=edit dmesg log with nouveau.debug=debug,VBIOS=trace booting kernel 4.1.2 with nouveau.debug=debug,VBIOS=trace appended on kernel command line. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91333] Connecting second of two monitors to a Lenovo W520 causes displays to go crazy
https://bugs.freedesktop.org/show_bug.cgi?id=91333 --- Comment #2 from Ilia Mirkin imir...@alum.mit.edu --- While going crazy is rarely the right thing to do, I'd like to point out that a GF108 only has 2 CRTC's and thus can only ever power 2 different screens at a time. (There might be a way to drive 2 identical screens at once from a single CRTC, not sure.) I suspect a negative interactions with gnome which might get confused about such a restriction. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91333] Connecting second of two monitors to a Lenovo W520 causes displays to go crazy
https://bugs.freedesktop.org/show_bug.cgi?id=91333 --- Comment #3 from Corey Ashford cjash...@us.ibm.com --- (In reply to Ilia Mirkin from comment #2) While going crazy is rarely the right thing to do, I'd like to point out that a GF108 only has 2 CRTC's and thus can only ever power 2 different screens at a time. (There might be a way to drive 2 identical screens at once from a single CRTC, not sure.) Yeah, I realize that. Just as a reference point, two external monitors works fine with Windows 7, even with just the Nvidia chip enabled (discrete graphics). With Optimus enabled, I can actually drive all three monitors simultaneously. I suspect a negative interactions with gnome which might get confused about such a restriction. Maybe so. Thanks for your input :) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91333] Connecting second of two monitors to a Lenovo W520 causes displays to go crazy
https://bugs.freedesktop.org/show_bug.cgi?id=91333 --- Comment #6 from Corey Ashford cjash...@us.ibm.com --- Created attachment 117105 -- https://bugs.freedesktop.org/attachment.cgi?id=117105action=edit Similar as first log, but this time I disable the laptop's display before adding the second monitor -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91333] Connecting second of two monitors to a Lenovo W520 causes displays to go crazy
https://bugs.freedesktop.org/show_bug.cgi?id=91333 --- Comment #4 from Ilia Mirkin imir...@alum.mit.edu --- I bet it works if you first disable one of the screens before plugging a third one in. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Add Option DRI3 to allow to disable DRI3 under EXA.
On 07/07/2015 09:51 PM, Ilia Mirkin wrote: Lastly, from some discussions with ajax on IRC, it appears that DRI3 is half-baked at best wrt sync between server and client. I think we should just disable it by default for now, until issues are ironed out. (Rather than what this patch has, which is default-on for Xorg some version.) What are the remaining known trouble spots wrt. sync? It seems to work pretty well at least for single gpu + unredirected fullscreen windows (== kms page flipping can be used for Presents. That's the use case i usually test very obsessively, as it matters very much for my type of applications, but other than that i only lightly test it via regular desktop use, so maybe that's were problems remain? We can disable it by default on exa - intel and amd/radeon drivers also disable by default. However, on gpus = maxwell only glamor accel is supported and glamor on nouveau is either dri3/present or no hw accel at all afaics. Btw. there are also a few patches made by Chris Wilson floating on the mailing list since around january, some are reviewed and tested by myself, but not included in xorg master. Might be good for people to have a look at them and maybe get them into xorg 1.18? On Sat, Jul 4, 2015 at 3:03 PM, Emil Velikov emil.l.veli...@gmail.com wrote: The DRI option with the intel ddx can be used to indicate the following - whether dri is disabled - the dri version - dri1, dri2, dri3 - the dri module name - doo_dri.so bar_dri.so I'm not sure how exactly it's supposed to work/works, and I believe most of that is due to legacy reasons. I'm just saying let's not do the whole thing - just the dri version would be great (as you suggested). I can change that to allow selection between 2 and 3 - at least for exa, on glamor the parameter 2 would either need to get ignored or it would completely disable hw acceleration. I went for consistency with the ati ddx because i found the intel variant too confusing. I think it changed multiple times during the last year. thanks, -mario -Emil On 4 July 2015 at 19:28, Ilia Mirkin imir...@alum.mit.edu wrote: Erm, that's nuts. I also don't really understand what they're talking about there... i915g vs i915? Anyways, I just meant the version numbers :) On Sat, Jul 4, 2015 at 2:23 PM, Emil Velikov emil.l.veli...@gmail.com wrote: That would be great, as long as it does only that and does not go into the drivername territory. As the said driver ;-) A driver name to use can be provided instead of simple boolean value, which will be passed to the GL implementation for it to load the appropriate backend. -Emil On 4 July 2015 at 18:17, Ilia Mirkin imir...@alum.mit.edu wrote: IMO it'd be nice to keep this compatible with the intel driver, which has a DRI option, which can take the values 1, 2, 3. Obviously for nouveau, 1 makes no sense as that was dropped quite some time ago. See http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/man/intel.man#n68 On Mon, Jun 29, 2015 at 11:30 PM, Mario Kleiner mario.kleiner...@gmail.com wrote: X-Server versions older than 1.16.3 have bugs in their DRI3/Present implementation which impair nouveau, so it is better to stick to good old DRI2 by default on such servers. E.g., page flipping doesn't work at all under DRI3/Present with older servers, and use of extensions like OML_sync_control, SGI_video_sync or INTEL_swap_events also causes failure of Present. nouveau's glamor accel backend currently doesn't work under DRI2, so continue to use DRI3 whenever it is supported. Under the exa accel backend, DRI2 works just fine, so disable DRI3 and choose DRI2 by default when nouveau is built for X-Server 1.16.3, and enable DRI3 if building on later X-Servers which work reasonably well under DRI3/Present. A new boolean xorg.conf Option DRI3 allows to enforce or prevent use of DRI3/Present under EXA acceleration for testing. Also add a bit more output about status of Present and DRI3 to aid debugging. Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com --- man/nouveau.man| 6 ++ src/nouveau_dri2.c | 11 ++- src/nv_const.h | 2 ++ src/nv_driver.c| 17 +++-- 4 files changed, 33 insertions(+), 3 deletions(-) diff --git a/man/nouveau.man b/man/nouveau.man index 129bb7f..12cfbc0 100644 --- a/man/nouveau.man +++ b/man/nouveau.man @@ -125,6 +125,12 @@ that relies on correct presentation timing behaviour as defined in that specification. .br Default: 1. +.TP +.BI Option \*qDRI3\*q \*q boolean \*q +Enable the DRI3 extension under exa acceleration if supported by server. +A setting of off will only use DRI2 instead. Under glamor acceleration, +DRI3 is always enabled if supported. Default: on for XOrg = 1.16.3, off for +earlier versions. .SH SEE ALSO __xservername__(__appmansuffix__), __xconfigfile__(__filemansuffix__), Xserver(__appmansuffix__), X(__miscmansuffix__) .SH AUTHORS diff --git a/src/nouveau_dri2.c
[Nouveau] [Bug 91333] Connecting second of two monitors to a Lenovo W520 causes displays to go crazy
https://bugs.freedesktop.org/show_bug.cgi?id=91333 --- Comment #7 from Corey Ashford cjash...@us.ibm.com --- In both of these log files is a line like the following: 48.693955] nouveau E[ PDISP][:01:00.0] INVALID_STATE [UNK05] chid 0 mthd 0x0080 data 0x Followed by a dump of what appears to be internal Nouveau driver state: [ 48.693960] nouveau E[ PDISP][:01:00.0] Core: [ 48.693966] nouveau E[ PDISP][:01:00.0] 0x0084: 0x019e02e2 - 0x [ 48.693972] nouveau E[ PDISP][:01:00.0] 0x0088: 0xf000 [ 48.693973] nouveau E[ PDISP][:01:00.0] Core - DAC 0: [ 48.693978] nouveau E[ PDISP][:01:00.0] 0x0400: 0x [ 48.693984] nouveau E[ PDISP][:01:00.0] 0x0404: 0x [ 48.693989] nouveau E[ PDISP][:01:00.0] 0x0420: 0x0001 [ 48.693990] nouveau E[ PDISP][:01:00.0] Core - DAC 1: [ 48.693995] nouveau E[ PDISP][:01:00.0] 0x0480: 0x Is this normal behavior? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91319] Nouveau driver cannot extract FCODE ROM / DCB Block from OpenFirmware Device tree
https://bugs.freedesktop.org/show_bug.cgi?id=91319 --- Comment #2 from Ilia Mirkin imir...@alum.mit.edu --- Aha, looks like the issue is that your VBIOS in OF does not have a PCIR section, and the nouveau VBIOS parser has come to expect that. Going to have to read more code to work out a proper solution to that. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91333] Connecting second of two monitors to a Lenovo W520 causes displays to go crazy
https://bugs.freedesktop.org/show_bug.cgi?id=91333 --- Comment #5 from Corey Ashford cjash...@us.ibm.com --- (In reply to Ilia Mirkin from comment #4) I bet it works if you first disable one of the screens before plugging a third one in. I had tried that experiment before, but I just now tried it again. Same bad result. Here are the steps I took. 1) Boot laptop with no external monitors connected. 2) Attach Displayport-connected monitor. All is well. 3) Disable internal monitor. All is still well... now using only the external monitor. 4) Plug in VGA monitor. 5) Nothing happens. 6) I bring up the Gnome Displays setting (not clicking anything yet), then the system starts with its display resetting (or whatever it's doing), and becomes unresponsive to keyboard input. 7) The only way to get back to a usable system is to disconnect the VGA display, which after 5-10 seconds gets me back to the Gnome login, and after logging in I was able to capture the dmesg output (will attach). -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91333] Connecting second of two monitors to a Lenovo W520 causes displays to go crazy
https://bugs.freedesktop.org/show_bug.cgi?id=91333 --- Comment #1 from Corey Ashford cjash...@us.ibm.com --- xorg-x11-drv-nouveau-1.0.11-2.fc22.x86_64 is what I have installed -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] [PATCH] nvc0: fix geometry program revalidation of clipping params
Any one which, after using a geometry shader, enables an extra clip distance. i.e. none. On Mon, Jul 13, 2015 at 4:16 AM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: What piglit test does this fix? On Sat, Jul 11, 2015 at 7:13 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: mesa-sta...@lists.freedesktop.org --- Even though in practice a geometry program will never be using UCP's, we still were revalidating (aka recompiling) the program when more clip planes became enabled (which also are used for regular clip distances). This seems like it should have led to massive fail, but I guess you don't change the number of clip planes when using geometry shaders. But I'm going to put this through a full piglit run just in case there's something I'm missing. src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c index 785e52e..11f2b10 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c @@ -339,7 +339,7 @@ nvc0_check_program_ucps(struct nvc0_context *nvc0, nvc0_vertprog_validate(nvc0); else if (likely(vp == nvc0-gmtyprog)) - nvc0_vertprog_validate(nvc0); + nvc0_gmtyprog_validate(nvc0); else nvc0_tevlprog_validate(nvc0); } -- 2.3.6 ___ mesa-dev mailing list mesa-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Best regards, Samuel Pitoiset. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] CUDA fixed VA allocations and sparse mappings
I apologize for my ignorance. In digging through nouveau, I've become a bit confused regarding the relationship between virtual address allocations and nouveau bo's. From my reading of the code, it seems that a nouveau_bo really encapsulates a buffer (whether imported, or allocated within nouveau like, say, pushbuffers). So I'm confused about an earlier statement that to allocate a chunk of address space, I have to create a nouveau_bo for it. What I really want to do is reserve some space in the address allocator (the stuff in nvkm/subdev/mmu/base.c). Note that there are no buffers at this time. This is just blocking out some chunk of the address space so that normal address space allocations (for, say, bo's) avoid this region. At some point after that, I'd like to import a buffer, and map it to certain regions of my pre-allocated address space. This is why I can't go through the normal path of importing a buffer...that path assumes there is no address for this buffer, and tries to allocate one. In our case, we already have an address in mind. Naively, at this point, I'd like to create a nouveau_bo for this imported buffer, but not have it go through the address allocator and instead just take a fixed address. Can someone clear up some of my confusion? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] [PATCH] nvc0: fix geometry program revalidation of clipping params
This was, btw, introduced in commit 3a8ae6ac243b (nvc0: adapt to new clip state). Back then there was no real geometry support yet. On Mon, Jul 13, 2015 at 2:05 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Any one which, after using a geometry shader, enables an extra clip distance. i.e. none. On Mon, Jul 13, 2015 at 4:16 AM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: What piglit test does this fix? On Sat, Jul 11, 2015 at 7:13 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: mesa-sta...@lists.freedesktop.org --- Even though in practice a geometry program will never be using UCP's, we still were revalidating (aka recompiling) the program when more clip planes became enabled (which also are used for regular clip distances). This seems like it should have led to massive fail, but I guess you don't change the number of clip planes when using geometry shaders. But I'm going to put this through a full piglit run just in case there's something I'm missing. src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c index 785e52e..11f2b10 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c @@ -339,7 +339,7 @@ nvc0_check_program_ucps(struct nvc0_context *nvc0, nvc0_vertprog_validate(nvc0); else if (likely(vp == nvc0-gmtyprog)) - nvc0_vertprog_validate(nvc0); + nvc0_gmtyprog_validate(nvc0); else nvc0_tevlprog_validate(nvc0); } -- 2.3.6 ___ mesa-dev mailing list mesa-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Best regards, Samuel Pitoiset. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90513] Odd gray and red flicker in The Talos Principle on GK104
https://bugs.freedesktop.org/show_bug.cgi?id=90513 --- Comment #9 from Karol Herbst freedesk...@karolherbst.de --- yeah I can confirm this. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91333] New: Connecting second of two monitors to a Lenovo W520 causes displays to go crazy
https://bugs.freedesktop.org/show_bug.cgi?id=91333 Bug ID: 91333 Summary: Connecting second of two monitors to a Lenovo W520 causes displays to go crazy Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: cjash...@us.ibm.com QA Contact: xorg-t...@lists.x.org Created attachment 117104 -- https://bugs.freedesktop.org/attachment.cgi?id=117104action=edit dmesg output from start to connecting the two monitors, then disconnecting the VGA monitor I am using a Lenovo W520 on Fedora 22. What I'd like to be able to do is close the laptop's display and use two external monitors. I know that Optimus is troublesome in Linux, so I have disabled it, and am using discrete graphics only (Nvidia Quadro 1000M, 108GLM). When I plug in the first of the two external monitors via the Displayport (converted to HDMI), everything works fine; I am able to use the laptop's internal display and the external monitor. When I plug in a second display via the VGA port, all of the screens go blank for a time, and then only the Displayport-connected monitor comes up. It is usable for about 10 seconds, and then the internal display shows some boot up messages, and the displayport-connected monitor shows the desktop, but I cannot type anything. About every three seconds, all screens blank out, and then the process repeats. My next step is to then disconnect the VGA monitor, and after about 10 seconds, it puts me back at the Gnome desktop login. From there I was able to log back in and get the dmesg output (attached). Looking at the dmesg output, there is a segfault in libmutter. Perhaps this is what is causing the problem. I don't know. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] [PATCH] nvc0: fix geometry program revalidation of clipping params
What piglit test does this fix? On Sat, Jul 11, 2015 at 7:13 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: mesa-sta...@lists.freedesktop.org --- Even though in practice a geometry program will never be using UCP's, we still were revalidating (aka recompiling) the program when more clip planes became enabled (which also are used for regular clip distances). This seems like it should have led to massive fail, but I guess you don't change the number of clip planes when using geometry shaders. But I'm going to put this through a full piglit run just in case there's something I'm missing. src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c index 785e52e..11f2b10 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c @@ -339,7 +339,7 @@ nvc0_check_program_ucps(struct nvc0_context *nvc0, nvc0_vertprog_validate(nvc0); else if (likely(vp == nvc0-gmtyprog)) - nvc0_vertprog_validate(nvc0); + nvc0_gmtyprog_validate(nvc0); else nvc0_tevlprog_validate(nvc0); } -- 2.3.6 ___ mesa-dev mailing list mesa-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Best regards, Samuel Pitoiset. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
