Re: [Pixman] [BUG] SIGSEGV in sse2_fill
continued from pixman@, original thread here: https://lists.freedesktop.org/archives/pixman/2018-August/004759.html On Wed, 2018-08-29 at 18:14 +0200, Frédéric Fauberteau wrote: > Le 2018-08-29 16:33, Adam Jackson a écrit : > > This is a curious backtrace though. You're crashing while trying to > > draw the black solid fill for the initial map of the root window. Fine, > > but you're doing so in software, even though you have glamor enabled, > > and glamor surely can usually accelerate solid fills. So you're hitting > > a software fallback for some reason, and if I had to guess... > > The area to fill is 2960x1050 but actually, I have two screens: > - - > > | | | > > | | | > > 1680x1050 | | 1280x1024 | > > | | | > > | |---| > > - > > Do you think it could be a reason to write in an unmapped region...? Probably not? Typically the allocation for the root window is a rectangle big enough to bound all the outputs within it, so actually 2960x1050 in your case. The missing corner below the 1280x1024 display still has memory behind it. > It is a RS780/RS880 (Radeon HD 3200). If the bug comes from the Mesa > driver, it's a big issue since we are totally late with the update (we > are on MesaLib 11.2.2) That should be new enough to not have the problem I was describing. Unfortunately, that means I'm out of ideas. I think there are probably at least two bugs here: the fallback shouldn't crash, but neither should the fallback occur. Probably the second one is a bit easier to figure out. I'd start by rebuilding xserver with some printf-debugging in the body of glamor_poly_fill_rect_gl(), to see which 'goto bail' path is getting hit. (xserver spells printf ErrorF, which will print into both the X log and stdout.) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [V2] modesetting: code refactor for PRIME sync
On 2018-08-29 4:53 a.m., jimqu wrote: > On 2018年08月29日 09:20, Alex Goins wrote: >> I'm still having issues with my local setup for testing it with >> modesetting<->modesetting PRIME, but I think it looks good by >> inspection, and >> would expect it to work. It does work with NVIDIA<->modesetting PRIME. >> >> It would be a good idea to test modesetting<->modesetting PRIME Sync >> with this >> patch before merging it, but I don't have any further objections. >> >> Reviewed-by: Alex Goins >> >> Thanks! >> Alex > > Thanks very much! Alex. > > I tested it on Intel(modesetting) + AMD(modesetting/amdgpu) and > Intel(modesetting)+NV(modesetting/nouveau), PRIME, reverse PRIME and > also PRIME offloading cases. > For the NV card, I don't know what issue you encountered, In my side , > at first, I found a GTX690, but PRIME can not work duo to there were two > DRM device nodes from NV card, so there are totally three screens(one > master and two GPUs) on the system. then I found a GTX500, it had only > one device node. > > Did you encounter the same issue? > > BTW, could you do me a favor to help me push the patch to the master or > other proper branch? I do not familiar with the processes that push the > patch to Xorg. Pushed to master, thanks guys. To ssh://gitlab.freedesktop.org/xorg/xserver 8a3ae555e..f79e53685 master -> master -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
