Re: [Nouveau] "enable dri3 support without glamor" causes gnome-shell regression on nv4x
Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example https://bugs.freedesktop.org/show_bug.cgi?id=91445 My suspicion is that this is due to the lack of PUSH_KICK in the *Done exa handlers -- works fine with DRI2, but DRI3 has no synchronization and so the commands never get flushed out. Easily verified by sticking PUSH_KICK's everywhere. I do not believe that that is the problem, in my case it clearly seems to be a pitch / swizzle problem rather then a synchronizarion problem, here is what my desktop with gnome shell looks like when using DRI2: https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg And this is what it looks like when using DRI3: https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg The DRI2 screenshot is made with Mario's 2 patches on top of current master: http://lists.freedesktop.org/archives/nouveau/2015-July/021740.html http://lists.freedesktop.org/archives/nouveau/2015-July/021741.html And then adding Option "DRI" "2" to xorg.conf. I've also tried disabling EXA using Option "AccelMethod" "none", but that seems to also automatically disable all DRI, leading to software rendering. I discussed this with Ben this morning and he suggested that this is likely a Mesa issue since with DRI3 mesa rather then the ddx allocs the surfaces. I've tried disabling swizzling in the mesa code by forcing nv30_miptree_create() to always take the code path for linear textures, but that leads to the exact same result as before that change. Regards, Hans ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] "enable dri3 support without glamor" causes gnome-shell regression on nv4x
On 03.08.2015 15:02, Hans de Goede wrote: > Hi, > > On 30-07-15 16:09, Ilia Mirkin wrote: >> FWIW this is a fail on nv50+ as well. See for example >> https://bugs.freedesktop.org/show_bug.cgi?id=91445 >> >> My suspicion is that this is due to the lack of PUSH_KICK in the *Done >> exa handlers -- works fine with DRI2, but DRI3 has no synchronization >> and so the commands never get flushed out. Easily verified by sticking >> PUSH_KICK's everywhere. > > I do not believe that that is the problem, in my case it clearly > seems to be a pitch / swizzle problem rather then a synchronizarion > problem, here is what my desktop with gnome shell looks like when > using DRI2: > > https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg > > And this is what it looks like when using DRI3: > > https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg > You can tell, just by looking at garbled pattern, what is the actually problem!? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] "enable dri3 support without glamor" causes gnome-shell regression on nv4x
On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede wrote: > Hi, > > On 30-07-15 16:09, Ilia Mirkin wrote: >> >> FWIW this is a fail on nv50+ as well. See for example >> https://bugs.freedesktop.org/show_bug.cgi?id=91445 >> >> My suspicion is that this is due to the lack of PUSH_KICK in the *Done >> exa handlers -- works fine with DRI2, but DRI3 has no synchronization >> and so the commands never get flushed out. Easily verified by sticking >> PUSH_KICK's everywhere. > > > I do not believe that that is the problem, in my case it clearly > seems to be a pitch / swizzle problem rather then a synchronizarion > problem, here is what my desktop with gnome shell looks like when > using DRI2: > > https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg > > And this is what it looks like when using DRI3: > > https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg > > The DRI2 screenshot is made with Mario's 2 patches on top of > current master: > > http://lists.freedesktop.org/archives/nouveau/2015-July/021740.html > http://lists.freedesktop.org/archives/nouveau/2015-July/021741.html > > And then adding Option "DRI" "2" to xorg.conf. His patches should have defaulted it to DRI 2 I think, so this is unnecessary. In fact you should have had to say "DRI" "3" to get DRI3 with his patches. -- > > I've also tried disabling EXA using Option "AccelMethod" "none", > but that seems to also automatically disable all DRI, leading to > software rendering. > > I discussed this with Ben this morning and he suggested that this > is likely a Mesa issue since with DRI3 mesa rather then the ddx > allocs the surfaces. I've tried disabling swizzling in the > mesa code by forcing nv30_miptree_create() to always take > the code path for linear textures, but that leads to the exact > same result as before that change. Ah yes. Very different problem indeed. I actually suspect it has to do with swizzling. Look at the white pattern of the moon -- it's all in a line. That means that it expected some locality and instead it got drawn all on a line. If it were merely a stride problem, I'd expect to see strips of the moon below and offset from one another. So... take a look at nv30_miptree_from_handle -- I wonder if it can now receive swizzled textures where it couldn't before. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90871] NV30: Xfwm4 use_compositing - garbled display
https://bugs.freedesktop.org/show_bug.cgi?id=90871 --- Comment #16 from poma --- Created attachment 117490 --> https://bugs.freedesktop.org/attachment.cgi?id=117490&action=edit lovelock.png OK - no comps -- 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 90871] NV30: Xfwm4 use_compositing - garbled display
https://bugs.freedesktop.org/show_bug.cgi?id=90871 --- Comment #17 from poma --- Created attachment 117491 --> https://bugs.freedesktop.org/attachment.cgi?id=117491&action=edit lovelock.png KO/garbled - comps GLX -- 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 90871] NV30: Xfwm4 use_compositing - garbled display
https://bugs.freedesktop.org/show_bug.cgi?id=90871 --- Comment #18 from poma --- Olivier, can you tell, just by looking at garbled pattern, what the actual problem is, the same as Hans de and Ilia do in http://lists.freedesktop.org/archives/nouveau/2015-August/021767.html "Look at the white pattern of the moon". -- 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
Re: [Nouveau] "enable dri3 support without glamor" causes gnome-shell regression on nv4x
Hi, On 03-08-15 17:36, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede wrote: Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example https://bugs.freedesktop.org/show_bug.cgi?id=91445 My suspicion is that this is due to the lack of PUSH_KICK in the *Done exa handlers -- works fine with DRI2, but DRI3 has no synchronization and so the commands never get flushed out. Easily verified by sticking PUSH_KICK's everywhere. I do not believe that that is the problem, in my case it clearly seems to be a pitch / swizzle problem rather then a synchronizarion problem, here is what my desktop with gnome shell looks like when using DRI2: https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg And this is what it looks like when using DRI3: https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg The DRI2 screenshot is made with Mario's 2 patches on top of current master: http://lists.freedesktop.org/archives/nouveau/2015-July/021740.html http://lists.freedesktop.org/archives/nouveau/2015-July/021741.html And then adding Option "DRI" "2" to xorg.conf. His patches should have defaulted it to DRI 2 I think, so this is unnecessary. In fact you should have had to say "DRI" "3" to get DRI3 with his patches. -- I've also tried disabling EXA using Option "AccelMethod" "none", but that seems to also automatically disable all DRI, leading to software rendering. I discussed this with Ben this morning and he suggested that this is likely a Mesa issue since with DRI3 mesa rather then the ddx allocs the surfaces. I've tried disabling swizzling in the mesa code by forcing nv30_miptree_create() to always take the code path for linear textures, but that leads to the exact same result as before that change. Ah yes. Very different problem indeed. I actually suspect it has to do with swizzling. Look at the white pattern of the moon -- it's all in a line. That means that it expected some locality and instead it got drawn all on a line. If it were merely a stride problem, I'd expect to see strips of the moon below and offset from one another. So... take a look at nv30_miptree_from_handle -- I wonder if it can now receive swizzled textures where it couldn't before. Ok, that does go in the direction I am expecting the problem to be, but I'm afraid I'm going to need a bit more guidance, what exactly am I looking for in that function / which "knobs" should I try to vary / play with to maybe fix this ? Regards, Hans ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] "enable dri3 support without glamor" causes gnome-shell regression on nv4x
On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede wrote: > Hi, > > > On 03-08-15 17:36, Ilia Mirkin wrote: >> >> On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede wrote: >>> >>> Hi, >>> >>> On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example https://bugs.freedesktop.org/show_bug.cgi?id=91445 My suspicion is that this is due to the lack of PUSH_KICK in the *Done exa handlers -- works fine with DRI2, but DRI3 has no synchronization and so the commands never get flushed out. Easily verified by sticking PUSH_KICK's everywhere. >>> >>> >>> >>> I do not believe that that is the problem, in my case it clearly >>> seems to be a pitch / swizzle problem rather then a synchronizarion >>> problem, here is what my desktop with gnome shell looks like when >>> using DRI2: >>> >>> https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg >>> >>> And this is what it looks like when using DRI3: >>> >>> https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg >>> >>> The DRI2 screenshot is made with Mario's 2 patches on top of >>> current master: >>> >>> http://lists.freedesktop.org/archives/nouveau/2015-July/021740.html >>> http://lists.freedesktop.org/archives/nouveau/2015-July/021741.html >>> >>> And then adding Option "DRI" "2" to xorg.conf. >> >> >> His patches should have defaulted it to DRI 2 I think, so this is >> unnecessary. In fact you should have had to say "DRI" "3" to get DRI3 >> with his patches. >> -- >>> >>> >>> I've also tried disabling EXA using Option "AccelMethod" "none", >>> but that seems to also automatically disable all DRI, leading to >>> software rendering. >>> >>> I discussed this with Ben this morning and he suggested that this >>> is likely a Mesa issue since with DRI3 mesa rather then the ddx >>> allocs the surfaces. I've tried disabling swizzling in the >>> mesa code by forcing nv30_miptree_create() to always take >>> the code path for linear textures, but that leads to the exact >>> same result as before that change. >> >> >> Ah yes. Very different problem indeed. I actually suspect it has to do >> with swizzling. Look at the white pattern of the moon -- it's all in a >> line. That means that it expected some locality and instead it got >> drawn all on a line. If it were merely a stride problem, I'd expect to >> see strips of the moon below and offset from one another. >> >> So... take a look at nv30_miptree_from_handle -- I wonder if it can >> now receive swizzled textures where it couldn't before. > > > Ok, that does go in the direction I am expecting the problem to be, > but I'm afraid I'm going to need a bit more guidance, what exactly > am I looking for in that function / which "knobs" should I try to > vary / play with to maybe fix this ? Unfortunately this is playing near (or past) the limits of my knowledge as well. My understanding is that DRI3 passes pixmaps around with dma-buf, aka "bo_from_handle". DRI2 uses some other mechanism which is not that (I think it just copies stuff around). Now on nv50+, bo's have "tile flags" (and memtype and probably other annoyances). The tile flags indicate the specific tiling mechanism used on that bo (i.e. do you do 32x32 tiles? 32x64? etc). Take a look at the nouveau_bo_new() call in nv50_miptree.c -- note how it takes a "bo config" argument. This bo config can then later be retrieved using some other syscall. However on nv30 there appears to not be any such thing. The nouveau_bo_new call just passes in NULL for creating the bo, which means that there's no way to recover the "are you swizzled" information after-the-fact. Presumably you should create a "nv04" bo config section in the union, and just pass the single "swizzled" bit through. I'm not sure what, if anything, is required on the kernel side for that. I don't think there's any optionality in how the swizzling is done for pre-nv50. Note that in the nv30_miptree logic, mt->swizzled implies that mt->uniform_pitch = 0, but the level pitch is set "properly" (again, see nv30_miptree_create). Hope this sheds some light and doesn't cause you to go in the wrong direction -- please take everything I say with a grain of salt -- I'm often a bit off on some of the details. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90871] NV30: Xfwm4 use_compositing - garbled display
https://bugs.freedesktop.org/show_bug.cgi?id=90871 --- Comment #19 from Ilia Mirkin --- Harder to tell, but I think one of two things is happening: (a) You have the inverse problem. You're getting a linear texture that's being interpreted as if it were swizzled. (b) Uninitialized video ram which happened to be some (set of) textures in a former life. I'm tending a bit more towards (b) but not 100% sure. I don't know how you could end up with linear texture data but think it's swizzled, but I'm also not extremely well-versed in nv30 driver specifics. -- 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 69827] [NVC1] Uneven, jerky mouse movement, increasing CPU usage
https://bugs.freedesktop.org/show_bug.cgi?id=69827 James Moe changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 --- Comment #10 from James Moe --- opensuse 13.2 linux 3.16.7-21-desktop x86_64 nvidia GF108 [GeForce GT 730] gnome 3.14.5 xf86-video-nouveau 1.0.11 The increasing CPU usage is still an issue. Apparently I am the only person to have this problem. :-( I have been using Xfce; I switched back to Gnome for a while because I prefer it. It was disappointing that this has not been resolved. It seems to be a nvidia-related (or nouveau?) problem. None of the other linux systems exhibit the CPU usage; the other computers have ATI (built-in or addon) video controllers. -- 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
