Check for D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES capability during initi...

- Check for D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES capability during initialization to fail on DirectX8 drivers.
- Fail in GetDeviceCaps loop after one second.

[apatrick1, 2010-10-06 22:34:13]

Hi Daniel,

I have been getting crash reports that I suspect, though cannot be sure of, are
caused by running DirectX 9 on top of a DirectX 8 driver. I discovered a
limitation of DirectX 8 that will prevent ANGLE from converting a texture to a
render target. Rather than try and figure out a workaround if this capability is
not present, I think it's best just to give up for DirectX 8 drivers. I'm sure
there are other limitations that will cause problems. I don't know of a more
direct way to detect DirectX 8, except maybe through IDxDiagContainer, but that
is probably overkill.

I also put a limit on the amount of time that is spent in the GetDeviceCaps loop
in case it fails for some other reason. I chose one second because the Chrome
GPU watchdog thread will terminate the process after two seconds anyway.

By the way, --disable-gpu-watchdog will be useful for debugging Chrome when the
GPU watchdog thread reaches the official channel.

Thanks,

Al

[dgkoch, 2010-10-07 00:25:12]

LGTM.

Good call on the D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES cap -- I hadn't
considered that.  I believe the implementation of  Surface::swap also relies on
that capability, so I think it would be very hard to work around not having that
feature. Hard to believe there might be DX8-type drivers out there, but who
knows what might be on old crusty WinXP systems.

[apatrick1, 2010-10-08 21:57:48]

Daniel, some feedback on this patch. This patch did not make it into the
7.0.544.0 canary build. However my GPU watchdog thread, which terminates the GPU
process after a timeout, did. From reports from the wild, the GetDeviceCaps loop
that I modified in this patch did appear to hang in some cases. This was the
call stack of the main thread when the watchdog kicked in:

0x7c7d2454 	[kernel32.dll 	+ 0x00002454] 	Sleep
0x01a61df3 	[libegl.dll 	- display.cpp:106] 	egl::Display::initialize()
0x01a65412 	[libegl.dll 	- libegl.cpp:135] 	eglInitialize
0x020dfa4c 	[chrome.dll 	- gl_context_egl.cc:43]
	gfx::BaseEGLContext::InitializeOneOff()
0x020dc426 	[chrome.dll 	- gl_context_win.cc:302]
	gfx::GLContext::InitializeOneOff()

I think it is possible that GetDeviceCaps will return D3DERR_NOTAVAILABLE in
cases where we do not want to retry. Maybe a box with D3D9 installed but no D3D9
capable graphics adapter would be such a case. Or possibly Chrome being run
through remote desktop would trigger it.

The change I made in this patch will prevent it from looping forever but it will
still lock up for about a second. Is there a better way of determining whether
GetDeviceCaps should be retried?

The good news is that's the only hang I found in ANGLE. The only other one I
have found was somewhere in the depths of an ATI driver.

Thanks,

Al

[dgkoch, 2010-10-09 04:09:11]

(+nicolas to see if he has anything to add)

I've also found some references to devices always returning D3DERR_NOTAVAILABLE
in some google searches.  They seemed to occur due to things like 
 - running in a vm that doesn't support d3d
 - running on windows server 2003 which has d3d disabled by default, etc
I'd imagine the ones you pointed out are also plausible. 

Unfortunately I don't see how one would be able to distinguish between a
permanent D3DERR_NOTAVAILABLE message from a transient one (due to screen saver,
locked screen, or what have you).  

A couple of possible options I can think of:
 1) don't do any looping on startup.  If it fails, error out right away so that
the browser starts up more quickly.  This would potentially result in weird
cases where peoples browsers don't get accelerated when they normally would
though.  Perhaps the browser could try a few times after startup and enable it
later if it failed initially?
 2) try to do more exotic detection to determine if there is a valid d3d9 driver
on the system. Not sure what this would be at the moment, but maybe look for
signatures of known drivers (ati, nv, intel, etc) or using dxdiag.  I'd expect
this is something that would need to be done at the browser level (install time?
-- probably not something you'd want to run on every startup), and not
necessarily in ANGLE itself.

[apatrick, 2010-10-11 18:06:52]

I think making ANGLE fail right away is the way to go. It's not ANGLE's
fault if GetDeviceCaps fails. This is a bit of a hack but I can make the
Chrome GPU process intermittently call GetDeviceCaps until it succeeds,
while still pumping its message loop, and only then call eglInitialize. If
GetDeviceCaps fails in ANGLE code it's then a legit failure. Patch on its
way if you agree.

Al

On Fri, Oct 8, 2010 at 9:09 PM, <daniel@transgaming.com> wrote:

> (+nicolas to see if he has anything to add)
>
> I've also found some references to devices always returning
> D3DERR_NOTAVAILABLE in some google searches.  They seemed to occur due
> to things like
>  - running in a vm that doesn't support d3d
>  - running on windows server 2003 which has d3d disabled by default, etc
> I'd imagine the ones you pointed out are also plausible.
>
> Unfortunately I don't see how one would be able to distinguish between a
> permanent D3DERR_NOTAVAILABLE message from a transient one (due to
> screen saver, locked screen, or what have you).
>
> A couple of possible options I can think of:
>  1) don't do any looping on startup.  If it fails, error out right away
> so that the browser starts up more quickly.  This would potentially
> result in weird cases where peoples browsers don't get accelerated when
> they normally would though.  Perhaps the browser could try a few times
> after startup and enable it later if it failed initially?
>  2) try to do more exotic detection to determine if there is a valid
> d3d9 driver on the system. Not sure what this would be at the moment,
> but maybe look for signatures of known drivers (ati, nv, intel, etc) or
> using dxdiag.  I'd expect this is something that would need to be done
> at the browser level (install time? -- probably not something you'd want
> to run on every startup), and not necessarily in ANGLE itself.
>
>
>
>
> http://codereview.appspot.com/2354042/
>

[dgkoch, 2010-10-12 15:39:37]

On 2010/10/11 18:06:52, apatrick wrote:
> I think making ANGLE fail right away is the way to go. It's not ANGLE's
> fault if GetDeviceCaps fails. This is a bit of a hack but I can make the
> Chrome GPU process intermittently call GetDeviceCaps until it succeeds,
> while still pumping its message loop, and only then call eglInitialize. If
> GetDeviceCaps fails in ANGLE code it's then a legit failure. Patch on its
> way if you agree.
> 

Agreed.  I don't think there should normally be cases where one would hit
D3DERR_NOTAVAILABLE right on startup anyhow.

Daniel