Hi Guys,
Number of recent well-known games are based on Starling game engine (Adobe Air+Stage3D for gpu rendering), such as: The Banner Saga 2, Samorost 3, The Inner World, Angry Birds. They are are falling into Software rendering mode on plain Wine and thus barely playable (bug #41635)
Thanks to Béla Gyebrószki finding @ bug #41653, Wine makes these games consider d3d9 rendering with the following single patch from wine-staging
https://github.com/wine-compholio/wine-staging/blob/master/patches/setupapi-...
This patch implements support of the case when a full driver path is passed to SetupDiGetClassDevs (trace successfully reaching AddDeviceToSet for a game below [1]).
I was unable to find @wine-devel discussion around this patch, I would be grateful if one could kindly remind why it was staged, probably it just requires refactoring around the change or additional tests?
I am asking this, because Adobe stopped Linux support for the Air years ago and we could never see such games ported, and therefore plain Wine's support of gpu acceleration for such games looks important.
Thanks in advance
Best regards, Donnie
[1] 0009:trace:setupapi:SetupDiGetClassDevsExW {4d36e968-e325-11ce-bfc1-08002be10318} L"PCI\VEN_0000&DEV_0000" (nil) 0x0000000a (nil) (null) (nil) 0009:warn:setupapi:SetupDiGetClassDevsExW unsupported flags 0000000a 0009:trace:setupapi:SetupDiCreateDeviceInfoListExW {4d36e968-e325-11ce-bfc1-08002be10318} (nil) (null) (nil) 0009:trace:setupapi:SETUPDI_EnumerateDevices 0x464ac90, {4d36e968-e325-11ce-bfc1-08002be10318}, L"PCI\VEN_0000&DEV_0000", 0000000a 0009:trace:setupapi:SETUPDI_EnumerateMatchingDeviceInstances L"PCI" L"VEN_0000&DEV_0000" 0009:trace:setupapi:SETUPDI_AddDeviceToSet 0x464ac90, {4d36e968-e325-11ce-bfc1-08002be10318}, 0, L"PCI\VEN_0000&DEV_0000\13&12345&0", 0
On 08.01.2017 17:26, Donat Enikeev wrote:
I was unable to find @wine-devel discussion around this patch, I would be grateful if one could kindly remind why it was staged, probably it just requires refactoring around the change or additional tests?
It was probably never sent to patch list, so there was nothing to discuss.
It was probably never sent to patch list, so there was nothing to
discuss.
Hm, so, do you think it is worth re-submitting for a formal review in current state and if so, who is eligible to do that on behalf of Michael Muller ([email protected])?
Best regards, Donnie
On Вс, янв 8, 2017 at 5:42 , Nikolay Sivov [email protected] wrote:
On 08.01.2017 17:26, Donat Enikeev wrote:
I was unable to find @wine-devel discussion around this patch, I would be grateful if one could kindly remind why it was staged, probably it just requires refactoring around the change or additional tests?
It was probably never sent to patch list, so there was nothing to discuss.
On 08.01.2017 15:52, Donat Enikeev wrote:
It was probably never sent to patch list, so there was nothing to discuss.
Hm, so, do you think it is worth re-submitting for a formal review in current state and if so, who is eligible to do that on behalf of Michael Muller ([email protected])?
Best regards, Donnie
Hi Donnie,
the patch you are asking about is most likely responsible for the following regression: https://bugs.winehq.org/show_bug.cgi?id=41653#c11 This means it is not suitable for the development branch yet (especially during the feature freeze).
Best regards, Sebastian
Hi Sebastian,
the patch you are asking about is most likely responsible for the following regression: https://bugs.winehq.org/show_bug.cgi?id=41653#c11
Yes, I has been following this bug, and was able to confirm flickering with 2.0-rc4 without StrictDrawOrdering Wine option. But not sure this is a true regression (as plain Wine seems affected as well)
Adobe Air Stage3D applications use multiple rendering Direct3D9 threads and seems Wine can't handle the commands order exactly as in Windows (at least for these games and/or some environments), despite all the syncing between threads.
So, I believe this is not a regression, the bug is just hidden per forced software rendering; and the trade off is between unplayability because of performance (see gameplay video attached https://bugs.winehq.org/attachment.cgi?id=56048) or flickering without StrictDrawOrdering on some systems
What do you think?
Best, Donnie
On Вс, янв 8, 2017 at 5:57 , Sebastian Lackner [email protected] wrote:
On 08.01.2017 15:52, Donat Enikeev wrote:
It was probably never sent to patch list, so there was nothing to discuss.
Hm, so, do you think it is worth re-submitting for a formal review in current state and if so, who is eligible to do that on behalf of Michael Muller ([email protected])?
Best regards, Donnie
Hi Donnie,
the patch you are asking about is most likely responsible for the following regression: https://bugs.winehq.org/show_bug.cgi?id=41653#c11 This means it is not suitable for the development branch yet (especially during the feature freeze).
Best regards, Sebastian
Hi all,
These games tested with Intel and nouveau drivers run smoothly on wine-staging without any additional features enabled: neither CSMT, nor StrictDrawOrdering (and I would suppose with this `setupapi` patch on plain Wine too, as it does nothing in rendering order materially, just making GPU rendering available). Confirmed independently on two distributions within the same bug #41653 (extract below)
So, as it appears, only environments with NVIDIA blob driver are affected. Noteworthy, that with CSMT enabled all is fine with blob as well (another vote for the mainline CSMT support), I believe that is because of single-rendering thread design.
Hope this information will help considering this setupapi patch reviewed. I fired a request to Nvidia support (Incident #170110-000314) around all of these, but wouldn't expect it to get enough attention due to specifics.
P.s. It would be interesting to check how AMD drivers behaves in this context
--- Comment #13 from Béla Gyebrószki--- nouveau/mesa 13.0.3, Wine 2.0-rc4: poor performance, no flickering Nvidia 375.26, Wine 2.0-rc4: poor performance, no flickering
nouveau/mesa 13.0.3, Wine Staging 2.0-rc4 (CSMT=off): good performance, no flickering Nvidia 375.26, Wine Staging 2.0-rc4 (CSMT=off): good performance, *flickering* nouveau/mesa 13.0.3, Wine Staging 2.0-rc4 (CSMT=on): good performance, no flickering Nvidia 375.26, Wine Staging 2.0-rc4 (CSMT=on): good performance, no flickering
Best, Donnie
On Вс, янв 8, 2017 at 6:16 , Donat Enikeev [email protected] wrote:
Hi Sebastian,
the patch you are asking about is most likely responsible for the following regression: https://bugs.winehq.org/show_bug.cgi?id=41653#c11
Yes, I has been following this bug, and was able to confirm flickering with 2.0-rc4 without StrictDrawOrdering Wine option. But not sure this is a true regression (as plain Wine seems affected as well)
Adobe Air Stage3D applications use multiple rendering Direct3D9 threads and seems Wine can't handle the commands order exactly as in Windows (at least for these games and/or some environments), despite all the syncing between threads.
So, I believe this is not a regression, the bug is just hidden per forced software rendering; and the trade off is between unplayability because of performance (see gameplay video attached https://bugs.winehq.org/attachment.cgi?id=56048) or flickering without StrictDrawOrdering on some systems
What do you think?
Best, Donnie
On Вс, янв 8, 2017 at 5:57 , Sebastian Lackner [email protected] wrote:
On 08.01.2017 15:52, Donat Enikeev wrote:
It was probably never sent to patch list, so there was nothing to discuss.
Hm, so, do you think it is worth re-submitting for a formal review in current state and if so, who is eligible to do that on behalf of Michael Muller ([email protected])?
Best regards, Donnie
Hi Donnie,
the patch you are asking about is most likely responsible for the following regression: https://bugs.winehq.org/show_bug.cgi?id=41653#c11 This means it is not suitable for the development branch yet (especially during the feature freeze).
Best regards, Sebastian
Hi Guys,
Since CSMT has been merged in a volume that StrictDrawOrdering is no more needed (confirmed) with certain applications, would it be a good idea to add few other patches from staging so the main apps based on Adobe Stage3D would run smoothly out of the box in the next stable release? These patches are 1-3 years old, so could be considered stable in a sense.
I believe the patches were not submitted primarily because of time required for polishing, adjusting per review, and further supporting to fix early bugs. Therefore, I will submit them either as is or with small enhancements and tests (details below) - to start formal review process and gather thoughts -- I will have some time in mid-May to sort out all comments/suggestions and/or polish patches. Not sure though how to mention initial authors properly, so will put kudos right in a patch comment (e.g. "based on", "inspired by"), if there is more proper way, please let me know.
So far, following is required to run those games with 2.6:
[Ken Thomases, ~2014]
Proper EnumDisplayDevices() + relaxing gdi driver lookup checks
There was a discussion around this back in 2014 resulted in suggestion to move this into drivers. I am going to do sort of that, but mostly as the migration for the first step. Still one hard-coded monitor will be assumed per device, will make applications work. There will be something similar in cocoa driver, but in a manner of placeholder as I don't have macos anywhere near to test this out.
[Michael Muller, Sebastian Lackner, early 2016]
1. Registry keys (e.g. HKLM\Control\Enum) for actual Display devices to allow `setupapi` enumerate properties and have same ground with user32 & driver. 2. Support for enumeration by device id (i.e. PCI\VEN0000&DEV0000) in SetupDiGteClassDevs()
These properties will be created based on data from EnumDisplayDevices(), so all Stage3D applications going this way within their initialization: EnumDisplayDevices -> SetupDiGetClassDevs -> Device Info Properties -> driver checks -- are not confused. I am going to slightly modify the patches so the keys are volatile and add some tests. Worth thinking probably whether it should be moved somewhere closer to driver, but I am not sure that many applications use this API.
Please share your thoughts,
Donnie
10.01.2017, 21:41, "Donat Enikeev" [email protected]:
Hi all,
These games tested with Intel and nouveau drivers run smoothly on wine-staging without any additional features enabled: neither CSMT, nor StrictDrawOrdering (and I would suppose with this `setupapi` patch on plain Wine too, as it does nothing in rendering order materially, just making GPU rendering available). Confirmed independently on two distributions within the same bug #41653 (extract below)
So, as it appears, only environments with NVIDIA blob driver are affected. Noteworthy, that with CSMT enabled all is fine with blob as well (another vote for the mainline CSMT support), I believe that is because of single-rendering thread design.
Hope this information will help considering this setupapi patch reviewed. I fired a request to Nvidia support (Incident #170110-000314) around all of these, but wouldn't expect it to get enough attention due to specifics.
P.s. It would be interesting to check how AMD drivers behaves in this context
--- Comment #13 from Béla Gyebrószki--- nouveau/mesa 13.0.3, Wine 2.0-rc4: poor performance, no flickering Nvidia 375.26, Wine 2.0-rc4: poor performance, no flickering
nouveau/mesa 13.0.3, Wine Staging 2.0-rc4 (CSMT=off): good performance, no flickering Nvidia 375.26, Wine Staging 2.0-rc4 (CSMT=off): good performance, *flickering* nouveau/mesa 13.0.3, Wine Staging 2.0-rc4 (CSMT=on): good performance, no flickering Nvidia 375.26, Wine Staging 2.0-rc4 (CSMT=on): good performance, no flickering
Best, Donnie
On Вс, янв 8, 2017 at 6:16 , Donat Enikeev [email protected] wrote:
Hi Sebastian,
> the patch you are asking about is most likely responsible for the > following regression: > https://bugs.winehq.org/show_bug.cgi?id=41653#c11
Yes, I has been following this bug, and was able to confirm flickering with 2.0-rc4 without StrictDrawOrdering Wine option. But not sure this is a true regression (as plain Wine seems affected as well)
Adobe Air Stage3D applications use multiple rendering Direct3D9 threads and seems Wine can't handle the commands order exactly as in Windows (at least for these games and/or some environments), despite all the syncing between threads.
So, I believe this is not a regression, the bug is just hidden per forced software rendering; and the trade off is between unplayability because of performance (see gameplay video attached https://bugs.winehq.org/attachment.cgi?id=56048) or flickering without StrictDrawOrdering on some systems
What do you think?
Best, Donnie
On Вс, янв 8, 2017 at 5:57 , Sebastian Lackner [email protected] wrote: > On 08.01.2017 15:52, Donat Enikeev wrote: >>> It was probably never sent to patch list, so there was nothing to >>> discuss. >> >> Hm, so, do you think it is worth re-submitting for a formal review >> in current state and if so, who is eligible to do that on behalf of >> Michael Muller ([email protected])? >> >> Best regards, >> Donnie >> > > Hi Donnie, > > the patch you are asking about is most likely responsible for the > following regression: > https://bugs.winehq.org/show_bug.cgi?id=41653#c11 > This means it is not suitable for the development branch yet > (especially during the feature freeze). > > Best regards, > Sebastian >
-
Donat Enikeev -
Nikolay Sivov -
Sebastian Lackner