`setupapi` patch from staging

[Donat Enikeev]

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

[Nikolay Sivov]

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.

[Donat Enikeev]

> 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 ([e-mail])?

Best regards,
Donnie

On Вс, янв 8, 2017 at 5:42 , Nikolay Sivov  
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.

[Sebastian Lackner]

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 ([e-mail])?
>
> 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]

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 
 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 ([e-mail])?
> >
> > 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]

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  
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
>  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 ([e-mail])?
> > >
> > > 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]

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" :
> 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 
> 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
> >   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 ([e-mail])?
> >  >>
> >  >> 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
> >  >