March 2014 - Wine-Devel - list.winehq.org

Re: Wine GPU decoding

by Michael Müller

Hi Stefan, > I did some introductory interface reading. If I understand it correctly, > the dxva implementation / driver can control the pool of the input > surface. Not only that, it actually creates the surface. Is that correct? > > Afaics the output surface is either a dxva-created surface or a render > target, is that correct? All surfaces which are used in conjunction with the dxvapi are created through the CreateSurface command of the IDirectXVideoAccelerationService interface. > If you are in system memory, is there an issue with using the d3d > surface's memory as the vaapi input buffer? Also take note of user > pointer surfaces / textures in d3d9ex. The surfaces are only used for storing the output image and they may have a different size than the buffers used in the vaapi. MPEG2 for example uses macro blocks which have a size of 16x16 Pixel and the size of a frame must therefore be dividable by 16. I noticed that VLC creates the surfaces with the size of the actual video while it initializes the decoders with a multiple of 16. Moreover I can not specify the address to which the output data should be copied I can only map the buffer at an address defined by vaapi and copy it manually. > I do not know of any windows driver that supports YUV render targets > (see above). Are dxva-created output surfaces video memory surfaces (or > textures) or system memory surfaces? If they are sysmem surfaces you > don't have a problem - the app either has to read back to sysmem or put > up with an RGB surface / texture. DXVA supports both: direct rendering (called native mode) and reading it back to system memory ( see http://en.wikipedia.org/wiki/DirectX_Video_Acceleration#DXVA2_implementatio… ) > But even if you're copying to an RGB surface you have to get the GL > texture from the IDirect3DSurface9 somehow. There may not even be one, > if the surface is just the GL backbuffer. This is just a wine-internal > problem though and should be solvable one way or another. > > The vaapi-glx interface is also missing options for the mipmap level and > cube map face. I guess you can ignore that until you find an application > that wants a video decoded to the negative z face, mipmap level 2, of a > rendertarget-capable d3d cube texture. > > You may also want a way to make wined3d activate the device's WGL > context. Right now that's not much of an issue if your code is called > from the thread that created the device. The command stream will make > this more difficult though. We implemented some hack to get the opengl texture id of an D3D9 surface and to make the OpenGL context current by calling acquire_context(). As mentioned in the first email, the screenshot was created by using the copy-back approach. > If the vaapi buffer has a constant address you can create a user memory > d3d surface. I wouldn't be surprised if dxva was a motivation for user > memory surfaces. > > On a related note, we don't want any GLX code in wined3d, and probably > not in any dxva.dll. The vaapi-glx.h header seems simple enough to use > through WGL as it just says a context needs to be active. If not, you'll > have to export a WGL version of vaapi from winex11.drv. > > At some point we should think about equivalent interfaces on OSX and how > to abstract between that and vaapi, but not today. We actually thought about a better solution on how to get around the problems. We could introduce a new surface type which uses the vaapi buffers as backend. If the users wants to read the memory back to system memory we can simply use the map function of vaapi and if the user wants to actually present the surface we could use the vaapi commands to convert it into a rgb texture with stuff like deinterlacing. This would allows us to implement native and copy back without doing unnecessary conversations or memory copies. Do you think it would be okay if we try to add such a new type of surface? I think we would need to put the Vaapi commands into the x11 driver and export some functions which can be called d3d. I also uploaded the patches in their current state so that you guys can take a look at what is actually needed to implement dxva2, but it is not yet in a state in which it could get upstream (we use a separate x11 connection, link statically against libva, inefficient algorithms for copying frames, ...) You can find it here: https://github.com/compholio/wine-compholio-daily/tree/dxva2/patches/11-DXV… on the dxva2 branch. To test it with VLC you need: 1. 32 bit version of libav-dev 1.2.1 On Ubuntu you can get this version of libav-dev from my PPA: https://launchpad.net/~pipelight/+archive/libva (except for Trusty Thar which already provides this version) 2. Install the vaapi driver, for nvidia you need vdpau-va-driver Make sure that vainfo (apt-get install vainfo) shows the MPEG2 VLD decoder. 3. You also need to apply this nasty hack to get around a problem with VLC and Direct3D: http://ix.io/bo5 4. Set the wine prefix to Vista as DXVA2 is only available in >= Vista 5. Install the current git version of VLC (the stable version has a bug in the DXVA2 code which breaks the decoding of P and B Frames). You can grab it here: http://nightlies.videolan.org/build/win32/last/ ( See https://trac.videolan.org/vlc/ticket/10868 for more information about the bug. It took me quite some time to figure out that this bug is in VLC, and not in my code... ) 6. Start VLC and enable DXVA2 in the Input/Codecs options. Test it :-) I did not try it on anything else than nvidia yet and there is some untested code in the patches which is not supported by the vdpau wrapper, so that it may break on other graphic cards. For other users that want to try out the patchset and expect a huge performance boost: I have to disappoint you! During my tests it was still slower than CPU decoded video data, but I expect a better performance after all the copy-overhead has been removed, and especially for other codecs like H264 the performance boost should be easier to notice. ;-) Michael

March 31, 2014

Re: Wine GPU decoding

by Stefan Dösinger

If this mail only contains this line my android client screwed up and I'll resend it tomorrow. Am 31.03.2014 21:16 schrieb "Michael Müller" <michael(a)fds-team.de>: > This is actually the windows version of VLC playing a MPEG2 movie with > GPU acceleration using DXVA2. My implementation of dxva2 uses the VAAPI > on Linux to do the actual gpu decoding and should support AMD, Intel and > NVIDIA cards. Cool :-) > The most difficult part is that DXVA2 is completely based on > Direct3D9Device and Direct3DSurface9. The DXVA2 places the output images > into a Surface and the applications locks the surface to get the output > data or simply presents it to the screen. I did some introductory interface reading. If I understand it correctly, the dxva implementation / driver can control the pool of the input surface. Not only that, it actually creates the surface. Is that correct? Afaics the output surface is either a dxva-created surface or a render target, is that correct? > Currently i lock both kind of buffers after rendering a frame and do the > synchronization in system memory, which is kind of inefficient depending > on the surface type. If you are in system memory, is there an issue with using the d3d surface's memory as the vaapi input buffer? Also take note of user pointer surfaces / textures in d3d9ex. > My original idea was to do the copy in the graphic > card as I can copy the image to a texture after decoding, but after > Sebastian implemented this part we found out that the VAAPI implies a > format conversion to RGB when copying data to a texture. I do not know of any windows driver that supports YUV render targets (see above). Are dxva-created output surfaces video memory surfaces (or textures) or system memory surfaces? If they are sysmem surfaces you don't have a problem - the app either has to read back to sysmem or put up with an RGB surface / texture. But even if you're copying to an RGB surface you have to get the GL texture from the IDirect3DSurface9 somehow. There may not even be one, if the surface is just the GL backbuffer. This is just a wine-internal problem though and should be solvable one way or another. The vaapi-glx interface is also missing options for the mipmap level and cube map face. I guess you can ignore that until you find an application that wants a video decoded to the negative z face, mipmap level 2, of a rendertarget-capable d3d cube texture. You may also want a way to make wined3d activate the device's WGL context. Right now that's not much of an issue if your code is called from the thread that created the device. The command stream will make this more difficult though. > Anyway, if other applications continue to copy the data back to system > memory it might be better to instead wrap the VAAPI buffers as Direct3D9 > surfaces so that we can directly map the VAAPI buffers when LockRect() > is called instead of copying the data. Though this would imply problems > when the applications tries to pass this interface to Present(). d3ddevice::present does not accept surfaces, but the problem remains for IDirect3DDevice9::UpdateSurface. If the vaapi buffer has a constant address you can create a user memory d3d surface. I wouldn't be surprised if dxva was a motivation for user memory surfaces. On a related note, we don't want any GLX code in wined3d, and probably not in any dxva.dll. The vaapi-glx.h header seems simple enough to use through WGL as it just says a context needs to be active. If not, you'll have to export a WGL version of vaapi from winex11.drv. At some point we should think about equivalent interfaces on OSX and how to abstract between that and vaapi, but not today.

March 31, 2014

Re: [PATCH 6/6] user32: Implement EnumDisplayDevicesW() based on EnumDisplayMonitors() and GetMonitorInfoW().

by Ken Thomases

On Mar 31, 2014, at 1:38 PM, Ken Thomases wrote: > I'm not certain, but I suspect that what you suggest also doesn't match what Direct3D does on Windows. My impression is that when an app uses D3D to enter exclusive full-screen mode, that other apps aren't informed about the mode change. (If I'm right, then Wine behaves incorrectly currently.) I was wrong about this part. I ran Guild Wars in full-screen mode and a test program did receive WM_DISPLAYCHANGE and saw the new values for monitor rects, etc. -Ken

March 31, 2014

Wine GPU decoding

by Michael Müller

Hi, it is probably still a bit early, but nevertheless I would like to announce a feature I am currently working on and present you the first results. As some of you have already noticed (http://bugs.winehq.org/show_bug.cgi?id=35868) I've recently submitted some simple stub patches to add the dxva2 dll. The original purposes was to get a browser plugin working, which expects that this library is available, and otherwise refuses to run. The library exports some functions which are used by several applications (like VLC, Flash, Silverlight, ...) for GPU decoding. I started to work to on these functions and I want to present you a first result which you can see here: https://dl.dropboxusercontent.com/u/61413222/dxva2.png This is actually the windows version of VLC playing a MPEG2 movie with GPU acceleration using DXVA2. My implementation of dxva2 uses the VAAPI on Linux to do the actual gpu decoding and should support AMD, Intel and NVIDIA cards. Currently only MPEG2 decoding is supported as it is one of the easier codecs and other ones like H264 needs a lot more of buffers, which need be translated from the DXVA format to VAAPI. The second easiest codec to implement would be mpeg4 but as none of my graphic cards support mpeg4, I will most probably continue with VC-1. Anyway, I need to clean up the patches a bit as they add about 3000 new lines of code and test it with some other graphic cards before I can provide them, but there are also some problems, mostly d3d9 related, for which I would like to get your opinion. The most difficult part is that DXVA2 is completely based on Direct3D9Device and Direct3DSurface9. The DXVA2 places the output images into a Surface and the applications locks the surface to get the output data or simply presents it to the screen. Although it would be much more efficient to directly blit the data in the graphic card at least VLC reads it back into system memory as the decoding and output pipeline are separated. The problem is that I actually need to allocate twice the amount of memory for decoding. since I need to provide the Direct3D Surfaces to the application and I also need to provide buffers to VAAPI. This is not a big problem for mpeg2 since it only uses 3 output images as a B Frame can only reference the last and the next frame. Anyway, for H264 this is getting insane as it requires to store up to 16 output images so that i would need to allocate 16 VAAPI buffers and 16 Direct3D surfaces. Currently i lock both kind of buffers after rendering a frame and do the synchronization in system memory, which is kind of inefficient depending on the surface type. My original idea was to do the copy in the graphic card as I can copy the image to a texture after decoding, but after Sebastian implemented this part we found out that the VAAPI implies a format conversion to RGB when copying data to a texture. This is actually a no go since VLC will refuse to use hardware acceleration when the output format is RGB. I also think it is kind of stupid to convert the RGB data back to YUV so that we end up with 3 color coder conversion (YUV->RGB->YUV->RGB). Some Intel developer wrote (see vaCopySurfaceGLX() at http://markmail.org/message/a3sav6q3dm5qvmat) that it would be possible to implement a copy in NV12 format for NVIDIA and Intel but not AMD. We could try to ask them to implement it, so that we can at least do it efficient for these two vendors. Anyway, if other applications continue to copy the data back to system memory it might be better to instead wrap the VAAPI buffers as Direct3D9 surfaces so that we can directly map the VAAPI buffers when LockRect() is called instead of copying the data. Though this would imply problems when the applications tries to pass this interface to Present(). So what do the wined3d guys think? Is it better to convince the Intel developers to allow a copy in YUV format and copy the data directly into the texture of an Direct3D9 surface or wrap the VAAPI buffers as Direct3D9Surface and add some glue code when an applications tries to render it? Or do you have any better ideas? Regards, Michael

March 31, 2014

Re: regsvr32: Replace printf calls with WriteConsole function (try 2)

by Austin English

On Mon, Mar 31, 2014 at 7:16 AM, Lauri Kenttä <lauri.kentta(a)gmail.com>wrote: > On 2014-03-31 03:14, Hugh McMaster wrote: > >> Fair point. Using your examples as a starting point, what do you >> think of the following options: >> (1) Call DllInstall, passing an optional [cmdline]. When used with >> [/u], passes an uninstall flag to DllInstall. >> (2) Call DllInstall, passing an optional [cmdline]. When used with >> [/u], an uninstall flag is passed to DllInstall. >> (3) Call DllInstall, passing an optional [cmdline]. When used with >> [/u], uses DllInstall to uninstall the DLL. >> (4) Call DllInstall, passing an optional [cmdline]. When used with >> [/u], the bInstall parameter of DllInstall is set to FALSE. >> >> For the record, I'm favouring options (3) and (4). >> > > I'd go with (1) or (3), optionally replacing "uses" with "calls". (3) is > probably the easiest to translate. > > -- > Lauri Kenttä > > > (3) is the easiest to understand (to me as a native English speaker), FWIW. -- -Austin

March 31, 2014

Re: [PATCH 6/6] user32: Implement EnumDisplayDevicesW() based on EnumDisplayMonitors() and GetMonitorInfoW().

by Ken Thomases

On Mar 31, 2014, at 5:20 AM, Alexandre Julliard wrote: > Yes, display settings/modes, adding/removing monitors, managing work > area, restoring resolution on process exit, etc. There would be parts > in user32, parts in the driver, but it should all run in the context of > the explorer process. Normal processes should retrieve the info from > explorer instead of using graphics driver calls. That can't work with the Mac driver. In order to be a good citizen, the Mac driver captures the display before changing the display mode. As a consequence, only the process which actually changed the mode can display anything until the mode is reset. Furthermore, the reason for capturing the display is to prevent other processes from receiving notification that the desktop has changed size, so they don't re-layout their windows or, in the case of the Finder, desktop icons. So, it's not even possible for the explorer to observe the change without the process that made the change telling it directly. I'm not certain, but I suspect that what you suggest also doesn't match what Direct3D does on Windows. My impression is that when an app uses D3D to enter exclusive full-screen mode, that other apps aren't informed about the mode change. (If I'm right, then Wine behaves incorrectly currently.) -Ken

March 31, 2014

Re: how to use ced1401 linux driver from wine application ?

by Vincent Povirk

http://wiki.winehq.org/USB is about running Windows USB drivers in Wine. If you were able to make this work, it would mean that the native Linux driver isn't involved at all, similar to what would happen if you connected a USB device to a virtual machine. Devices with Linux native drivers can work in Wine without needing to run a Windows driver, as long as the device is accessed through a standard and generic Windows API that Wine provides, such as DirectInput for joysticks. If you have a specialized device for which no generic API exists, there's no way for Wine to provide access to that device to Windows programs in a generic way. It can, however, be done in a device-specific way based on the respective API's for accessing that device on Linux and Windows. How would a Windows software developer access the device you're trying to use? Is there a specific API (it doesn't have to be included in Windows) that would allow a Windows developer to target a range of similar devices? If so, providing an implementation of that API in Wine is probably the best approach. If not, you'll need to either run the Windows driver somehow (very difficult, I would guess) or create a replacement for it (may be much easier, depending on how similar the Linux and Windows API's are, and how complex they are). If you can find some documentation for those interfaces, then we can talk more specifically about how to provide them in Wine.

March 31, 2014

Re: mshtml: Added IHTMLTable::width property implementation.

by Jacek Caban

Hi Zhenbo, On 03/31/14 16:26, Zhenbo Li wrote: > As my test case shows, windows would truncate float numbers. > I considered VarInt() in oleaut32.dll, but I think to declare > var2str_length() is more clear. +static HRESULT var2str_length(nsAString *nsstr, const VARIANT *p) +{ + static WCHAR buf[64]; + static const WCHAR formatW[] = {'%','d',0}; + LONG width; + + switch(V_VT(p)) { + case VT_BSTR: + return nsAString_Init(nsstr, V_BSTR(p)); + case VT_R8: + width = (LONG)(V_R8(p)); + break; + case VT_R4: + width = (LONG)(V_R4(p)); + break; + case VT_I4: + width = V_I4(p); + break; + default: + FIXME("unsupported arg %s\n", debugstr_variant(p)); + return E_NOTIMPL; + } + sprintfW(buf, formatW, width); + return nsAString_Init(nsstr, buf); +} I would like to see this more generic. How about having var_to_nsstr? It seems to me that we don't really have to convert floats here. Gecko and/or getter may do that instead. If we really have to it here, then some sort of flags controlling helper behaviour on floats may be cleaner. + nsAString val; + HRESULT nsres; nsresult and HRESULT, although are very similar, are two different things and should not be mixed. + DOUBLE width; + + TRACE("(%p)->(%p)\n", This, p); + nsAString_Init(&val, NULL); + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); + + V_VT(p) = VT_BSTR; + nsres = return_nsstr(nsres, &val, &V_BSTR(p)); Please don't use return_nsstr this way. It's a strange helper with unusual behaviour in terms of freeing input parameters to make common Gecko wrapping functions cleaner. Using this for string conversion looks bad. Esp in this case, where it adds unneeded BSTR allocation in cases where the string is converted to int later. However, see bellow first. + if (nsres != S_OK) + return nsres; + + nsres = VarR8FromStr(V_BSTR(p), 0, 0, &width); + if (nsres == S_OK){ + VariantClear(p); + V_VT(p) = VT_I4; + V_I4(p) = (LONG)width; + } + return S_OK; +#define cmp_length(a,b) _cmp_length(__LINE__,a,b) +static void _cmp_length(unsigned line, VARIANT got, const char * exstr) +{ + static char buf[64]; + ok_(__FILE__,line) (V_VT(&got)==VT_BSTR || V_VT(&got)==VT_I4, + "V_VT is %hu, expected VT_BSTR(%hu) or VT_I4(%hu)\n", + V_VT(&got), VT_BSTR, VT_I4); + + if (V_VT(&got) == VT_BSTR){ + ok_(__FILE__,line) (!strcmp_wa(V_BSTR(&got), exstr), + "Expected %s, got %s\n", exstr, wine_dbgstr_w(V_BSTR(&got))); + } + else { + sprintf(buf, "%d", V_I4(&got)); + ok_(__FILE__,line) (!strcmp(buf, exstr), + "Expected %s, got %d\n", exstr, V_I4(&got)); + } +} This test should be stricter. You decide on the way to compare based on the value you received. This means that if the implementation always returns VT_BSTR, this will success as well. In fact, my quick testing suggests that native IE always returns string in this case. Also, please consider using more targeted helper so that test would look like: test_table_width(table, "11"); Thanks, Jacek

March 31, 2014

RE: regsvr32: Replace printf calls with WriteConsole function (try 2)

by Lauri Kenttä

On 2014-03-31 03:14, Hugh McMaster wrote: > Fair point. Using your examples as a starting point, what do you > think of the following options: > (1) Call DllInstall, passing an optional [cmdline]. When used with > [/u], passes an uninstall flag to DllInstall. > (2) Call DllInstall, passing an optional [cmdline]. When used with > [/u], an uninstall flag is passed to DllInstall. > (3) Call DllInstall, passing an optional [cmdline]. When used with > [/u], uses DllInstall to uninstall the DLL. > (4) Call DllInstall, passing an optional [cmdline]. When used with > [/u], the bInstall parameter of DllInstall is set to FALSE. > > For the record, I'm favouring options (3) and (4). I'd go with (1) or (3), optionally replacing "uses" with "calls". (3) is probably the easiest to translate. -- Lauri Kenttä

March 31, 2014

Re: [PATCH 1/2] docobj.idl: Added some new OLDCMDID values.

by Dmitry Timoshkov

Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > include/docobj.idl | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) A typo in the commit message: OLD -> OLE. -- Dmitry.

March 31, 2014