Help needed :)

[Johannes Lundberg]

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?

>> 
>> 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?

>> 
>> 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.

>
>> 
>> 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
>>