Help needed :)

[Ben Widawsky]

On 18-05-23 08:46:10, Johannes Lundberg wrote:
> 
> Ben Widawsky writes:
> 
> > 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).
> >
> 
> That's unfortunate. Are you (still) with Intel?
> 

Yes. Just paid to work on different stuff now :-)

> >> 
> >> 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.
> >
> 
> I have myself never seen the render bug with glxgears, only the vaapi
> rendering issue. I've added a comment here:
> https://github.com/FreeBSDDesktop/kms-drm/issues/32
> 
> There's also a link to Google Drive with a movie recording of a
> playback.
> 
> modesetting, intel uxa/sna, all the same. The only factor that has any
> effect is drm-4.9 to drm-4.11 update.
> 
> >> 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.
> >
> 
> Yes, except for vaapi, 4.15 seem pretty solid except for a couple of things we need to fix
> in linuxkpi. 
> 
> Is there any specific part of the code (source file) to look for vaapi
> decoding stuff? Do you have any recommendation for a starting point?
> 

As you may or may not be aware, Intel has recently switched the vaapi driver for
newer platforms:
https://github.com/intel/media-driver

I know nothing about the new media-driver. It was developed by another part of
Intel.

> >> 
> >> 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
> 
> This message: Failed to submit rendering commands (Bad address),
> disabling acceleration?
> 
> Not sure. I think this happens sometimes with intel ddx and is not
> related to the vaapi rendering bug. I can try reproduce it and post a full log.
> 

Sure. This is only printed in SNA. It's a result of a failed execbuf command,
which definitely isn't normal. There should be kernel error messages as a result
of this.

> >
> >> 
> >> 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.
> >
> 
> We are very grateful for every bit :)
> 
> >> Thanks
> >> /Johannes
> >> 
>