Re: `setupapi` patch from staging

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