I can't actually reproduce this. Tested both Experimental and 8.0 (albeit with current dxvk master, but it's not like there have been any significant D3D11 changes) and the video plays back fine, and I do eventually get to the 3D-rendered gameplay section. Also tried with different in-game settings and it works just fine here.
@besentv Are you still seeing this issue to this day?
Yes, maybe it's bound to AMD iGPUs?
Still does the same (I assumed a black screen but I can't say it isn't the first frame of the video) Both wine (with quite recent dxvk) and Steam with Proton 10. But on two Intel GPU systems, on my desktop with Nvidia GTX1650 the videos do play. Stand by and I'll post up some kind of diff to see what relevant differences there are in the wine/dxvk/vkd3d output between the two.
I think I found something -- I'll attach these full logs, which are probably far more info than you need but they're also not THAT big (I stopped the game as soon as it played or didn't play the video at the beginning of chapter 1.)
new-york has a GTX1650, and an integrated Coffee Lake GPU (which the vast majority of games do successfully ignore, this one included); the notebook is a Tiger Lake. I also have a surface (2017 era) with a Kaby Lake, which behaved identically to the Tiger Lake (but probably at lower FPS.) (I do have that cut to 1440x900, I'm not trying to make that poor integrated GPU run games at 2736x1824 LOL.). I haven't updated my home desktop in a few days so it's on Mesa 26.0.0 versus the other 26.0.1; but, the Nvidia driver doesn't use Mesa anyway so I doubt this affects anything.
I will point to line 627 in inspiron-log.txt and line 953 in new-york-log.txt (which is the same point, new-york is much more verbose due to having discrete & integrated GPU, and the nvidia driver resulting in more verbose output from dxvk & vkd3d on initialization...) That is about where they started playing (or attempting to play) the video.
There's a swapchain made right there, the nvidia shows Image count: 5 while the Intel shows Image count: 4
I think the relevant part, the Nvidia then shows
** (wine:2026565): CRITICAL **: 18:41:50.520: _dma_fmt_to_dma_drm_fmts: assertion 'fmt != GST_VIDEO_FORMAT_UNKNOWN' failed
while the Intel doesn't. I did exit both with "wineserver -k" so they probably just kind of abort at the end.
Could that _dma_fmt_to_dma_drm_fmts failing yield some fallback on Nvidia (which works) while having it succeed on Intel (and AMD) yields a faulty code path? This is the only significant difference I could see between the two logs. But here they are to puruse!
Well, I'm glad I've got someting to play on I guess and I can "Steam Remote Play" into it. Let me know if you want more info on this, I have no trouble futzing with mesa test builds or some environment variables or whatever to nail this down if you wish.
Thanks!
--Henry
Nothing extracted yet.
Software information
Poppy Playtime (1721470) default config.
System information
15.0.7 DRM 3.52 6.4.9-1-MANJARO)
Apitrace file(s)
Log files
steam-1721470.zip