Date: Tue, 22 May 2018 16:30:17 -0700 From: Ben Widawsky <ben@bwidawsk.net> To: Johannes Lundberg <johalun0@gmail.com> Cc: x11-list freebsd <freebsd-x11@freebsd.org> Subject: Re: Help needed :) Message-ID: <20180522233017.zj7u3w42ytd3rnky@mail.bwidawsk.net> In-Reply-To: <CAECmPwsgy_TUODVxvpFdJvvdAgmkjjK=Zir7SvwvahQwNDoQDQ@mail.gmail.com> References: <CAECmPwsgy_TUODVxvpFdJvvdAgmkjjK=Zir7SvwvahQwNDoQDQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18-05-22 15:33:33, Johannes Lundberg wrote: > Hi Ben (and welcome to FreeBSD) (cc: graphics ml) > Thank you very much. > You said in an earlier email that you are a long time developer in drm/i915 and > I was hoping you could help us zone in on one particular issue. I have recently stepped down from graphics to move into FreeBSD (unfortunately, for me the choice was mutually exclusive). > > Our drm-stable-kmod package is based on Linux 4.9 and is running without > issues. > > drm-next-kmod is based on 4.11 and we have some vaapi rendering regression. > > Between 4.9 and 4.11 we restructured a lot, moving drm bits out of the kernel > tree into it's own repo so bisecting to find where the problem was introduced > is very difficult. > > The issue is here (with screenshots): https://github.com/FreeBSDDesktop/kms-drm > /issues/32 > > Maybe you are familiar with what could be the reason behind the rendering > issues with vaapi? > The two issues look different to me. First one looks like csc fail, and the second looks like I have no clue. On the first one, given the fact that the top of the frame looks correct, I'd actually guess there is some synchronization issue. I'd expect that to generate an error message from either libva, or the DDX. The second one is 84 pixels of corruptions which makes zero sense to me. Maybe a context leak? Something like: https://bugs.freedesktop.org/show_bug.cgi?id=102774 Can you reproduce this with modesetting driver as well, or only SNA? Most Linux distributions have switched to either Wayland, or modesetting driver by default. > Since then we have continued to merge updates from upstream and we're now > almost ready to release our drm drivers based on 4.15. > > https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v4.15 > > The vaapi rendering issue still remains unchanged but we're hoping to fix that > for this release. So GL is okay with the update to 4.15, just not VAAPI? It looks like you always require more than 1 GPU client to reproduce? Context leaking is the first guest. > > Latest driver code: > https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v4.15/drivers/gpu/drm/i915 > > Our drm drivers depends on linuxkpi which is split in two parts, gplv2 and > non-gplv2. > > Latest version of non-gplv2 linuxkpi for 4.15 has not yet been merged into > upstream freebsd and can be found here: https://github.com/FreeBSDDesktop/ > freebsd-base-graphics/tree/drm-v4.15-WIP/sys/compat/linuxkpi/common > > gplv2 parts are here: > https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v4.15/linuxkpi > > We are grateful for any clues you might have. Are there any messages from DRM subsystem other than this one? https://github.com/FreeBSDDesktop/kms-drm/issues/32#issuecomment-370277555 > > PS. If you're interested in FreeBSD and would like to join/help us, we'd be > happy to have someone from upstream i915 onboard :) > I would have loved for my employer to fund me to do this, but it was sadly not meant to be. I'd be happy to help out here though even though my knowledge grows more stale by the day. > Thanks > /Johannes >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180522233017.zj7u3w42ytd3rnky>