Re: wined3d: Use backup swapchain DC for devices created with desktop window. (try 2)
Am Montag, 3. September 2012, 04:06:01 schrieb Adam Jakubek:
Previous version failed on test bots. Added test case skipping when no device can be created with normal (non-desktop) window. I skimmed bug #18490, and I'm wondering about two things: Does the app create a D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF device? Once the device is created, what does it to with it? A +d3d log would provide some answers.
This is some guesswork: I don't think the game creates a _REF device because REF devices require the user to install the reference rasterizer dll, as Matteo already mentioned. If it's a NULLREF device I wonder what the game is able to do with it. The bug report has a link which promises some clues, but the link is dead. Stefan
On Mon, Sep 3, 2012 at 6:29 PM, Stefan Dösinger <stefandoesinger(a)gmx.at>wrote:
I skimmed bug #18490, and I'm wondering about two things: Does the app create a D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF device? Once the device is created, what does it to with it? A +d3d log would provide some answers.
Ok, this needs a little correction on my part. The game actually creates D3DEVTYPE_HAL (I somehow previously concluded it wouldn't work, since on my test machine it required software vertex processing). Here is the relevant log line: trace:d3d:wined3d_device_create wined3d 0x235ce558, adapter_idx 0, device_type 0x1, focus_window 0x20026, flags 0x22, device_parent 0x2284cc0c, device 0x2284cc14. Focus window is the desktop handle. Presentation parameters specify windowed mode and hDeviceWindow=NULL, so in the end it uses the desktop window. It seems to be some kind of short-lived auxiliary device for texture operations. It's not used for rendering at all. The only operations on that device I could find is a series of CreateTexture calls: trace:d3d9:d3d9_device_CreateTexture iface 0x2284cc08, width 2048, height 2048, levels 1, usage 0, format 0x15, pool 0x2, texture 0x33be40, shared_handle (nil). They are followed by several LockRect/UnlockRect calls, after which the textures are released. The device is released immediately after that. Originally I suspected this might be used to generate mip-maps or load textures with d3dx, but the presence of D3DPOOL_SYSTEMMEM excludes both. I admit that it's a very non-standard way of creating a D3D device, since it can't render anything. However it seems to work for this particular use case. Regards, Adam Jakubek
Hello Is there a status update on this patch? I am curious to know if it will be merged, and if not, what correction is needed to make it mergeable. Thanks Jeff On Mon, Sep 3, 2012 at 1:51 PM, Adam Jakubek <ajakubek(a)gmail.com> wrote:
On Mon, Sep 3, 2012 at 6:29 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
I skimmed bug #18490, and I'm wondering about two things: Does the app create a D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF device? Once the device is created, what does it to with it? A +d3d log would provide some answers.
Ok, this needs a little correction on my part. The game actually creates D3DEVTYPE_HAL (I somehow previously concluded it wouldn't work, since on my test machine it required software vertex processing). Here is the relevant log line: trace:d3d:wined3d_device_create wined3d 0x235ce558, adapter_idx 0, device_type 0x1, focus_window 0x20026, flags 0x22, device_parent 0x2284cc0c, device 0x2284cc14.
Focus window is the desktop handle. Presentation parameters specify windowed mode and hDeviceWindow=NULL, so in the end it uses the desktop window.
It seems to be some kind of short-lived auxiliary device for texture operations. It's not used for rendering at all. The only operations on that device I could find is a series of CreateTexture calls: trace:d3d9:d3d9_device_CreateTexture iface 0x2284cc08, width 2048, height 2048, levels 1, usage 0, format 0x15, pool 0x2, texture 0x33be40, shared_handle (nil).
They are followed by several LockRect/UnlockRect calls, after which the textures are released. The device is released immediately after that.
Originally I suspected this might be used to generate mip-maps or load textures with d3dx, but the presence of D3DPOOL_SYSTEMMEM excludes both.
I admit that it's a very non-standard way of creating a D3D device, since it can't render anything. However it seems to work for this particular use case.
Regards, Adam Jakubek
participants (3)
-
Adam Jakubek -
Jeff Cook -
Stefan Dösinger