New and subtle ddraw:dsurface test failure

Hi,

i just noticed some new and subtle failure in ddraw:dsurface
tests. I don't know how closely you watch and study tests
results, so i thought it might be a good idea bring it the
the light. Sorry if not ;-)

Compared WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last
Friday).

Interestingly does not happen on Intel and nVidia 64bit. So
the only affected is nVidia 32bit.


(For my education) Generally, when the test fails in Windows
world, it means that the test is wrongly written or not
supported under the tested Windows version? (not blaming
anyone, just asking how things work;) 

And the last question is about MSI failures and timeouts
which some boxes suffers... In my case the  "powerful"
succeeds and the "weak" timeouts here (and not just mine).
Shouldn't be the timeout prolonged?


Regards,
W.

PS: I probably missed "gratulation time" for v1.2, so at
least i wish all the goodness to 1.3.xx line! And hope i
find another free time for buzilla soon.

[Oldřich Jedlička]

Hi W,

On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote:
> Hi,
>
> i
> just noticed some new and subtle failure in ddraw:dsurface
> tests. I don't
> know how closely you watch and study tests
> results, so i thought it might
> be a good idea bring it the
> the light. Sorry if not ;-)
>
> Compared
> WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last
> Friday).

Interestingly does not happen on Intel and nVidia 64bit. So
> the only
> affected is nVidia 32bit.

Do you mean this problem?

ddraw:dsurface start -
-
dsurface.c:419: Tests skipped: Failed to create surface
dsurface.c:801:
Test failed: IDirectDraw7_QueryInterface returned 80004002
dsurface.c:808:
this is the last test seen before the exception
dsurface: unhandled
exception c0000005 at 00413A29
ddraw:dsurface done (4294967295)

I've seen
this also during my first tests. From my understanding the problem of
unhandled exception is caused by query interface failure. For me it looks
like that DirectDraw7 isn't supported on the system
(E_NOINTERFACE).

Oldřich.
> (For my education) Generally, when the test
> fails in Windows
> world, it means that the test is wrongly written or not

supported under the tested Windows version? (not blaming
> anyone, just
> asking how things work;)
> And the last question is about MSI failures and
> timeouts
> which some boxes suffers... In my case the  "powerful"
> succeeds
> and the "weak" timeouts here (and not just mine).
> Shouldn't be the timeout
> prolonged?
>
> Regards,
> W.
>
> PS: I probably missed "gratulation
> time" for v1.2, so at
> least i wish all the goodness to 1.3.xx line! And
> hope i
> find another free time for buzilla soon.

[Roderick Colenbrander]

2010/8/8 Oldřich Jedlička <oldium.pro(a)seznam.cz>:
> Hi W,
>
> On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote:
> > Hi,
> >
> > i
> > just noticed some new and subtle failure in ddraw:dsurface
> > tests. I don't
> > know how closely you watch and study tests
> > results, so i thought it might
> > be a good idea bring it the
> > the light. Sorry if not ;-)
> >
> > Compared
> > WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last
> > Friday).
>
> Interestingly does not happen on Intel and nVidia 64bit. So
> > the only
> > affected is nVidia 32bit.
>
> Do you mean this problem?
>
> ddraw:dsurface start -
> -
> dsurface.c:419: Tests skipped: Failed to create surface
> dsurface.c:801:
> Test failed: IDirectDraw7_QueryInterface returned 80004002
> dsurface.c:808:
> this is the last test seen before the exception
> dsurface: unhandled
> exception c0000005 at 00413A29
> ddraw:dsurface done (4294967295)
>
> I've seen
> this also during my first tests. From my understanding the problem of
> unhandled exception is caused by query interface failure. For me it looks
> like that DirectDraw7 isn't supported on the system
> (E_NOINTERFACE).
>
> Oldřich.

I'm not sure how usable 64-bit DirectDraw is. At the time XP64 came
out, DirectDraw was already deprecated and Direct3D9 was the standard.
I'm not sure how much effort Microsoft put in 64-bit DirectDraw (it
wouldn't make sense to use it). Perhaps some IE plugins (or IE itself)
use DirectDraw and that could be why there is some support.

More investigation is needed on what is supported in 64-bit
DirectDraw. The DirectDraw 3D tests seem to fail correctly, so at
least 3D is not around. There is likely some limited 2D support
though. It shouldn't be that hard to fix the tests.

Roderick

[Reece Dunn]

2010/8/9 Roderick Colenbrander <thunderbird2k(a)gmail.com>:
> 2010/8/8 Oldřich Jedlička <oldium.pro(a)seznam.cz>:
> > Hi W,
> >
> > On Sunday 08 August 2010 11:21:35 wylda(a)volny.cz wrote:
> > > Hi,
> > >
> > > i
> > > just noticed some new and subtle failure in ddraw:dsurface
> > > tests. I don't
> > > know how closely you watch and study tests
> > > results, so i thought it might
> > > be a good idea bring it the
> > > the light. Sorry if not ;-)
> > >
> > > Compared
> > > WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last
> > > Friday).
> >
> > Interestingly does not happen on Intel and nVidia 64bit. So
> > > the only
> > > affected is nVidia 32bit.
> >
> > Do you mean this problem?
> >
> > ddraw:dsurface start -
> > -
> > dsurface.c:419: Tests skipped: Failed to create surface
> > dsurface.c:801:
> > Test failed: IDirectDraw7_QueryInterface returned 80004002
> > dsurface.c:808:
> > this is the last test seen before the exception
> > dsurface: unhandled
> > exception c0000005 at 00413A29
> > ddraw:dsurface done (4294967295)
> >
> > I've seen
> > this also during my first tests. From my understanding the problem of
> > unhandled exception is caused by query interface failure. For me it looks
> > like that DirectDraw7 isn't supported on the system
> > (E_NOINTERFACE).
> >
> > Oldřich.
>
> I'm not sure how usable 64-bit DirectDraw is. At the time XP64 came
> out, DirectDraw was already deprecated and Direct3D9 was the standard.
> I'm not sure how much effort Microsoft put in 64-bit DirectDraw (it
> wouldn't make sense to use it). Perhaps some IE plugins (or IE itself)
> use DirectDraw and that could be why there is some support.
>
> More investigation is needed on what is supported in 64-bit
> DirectDraw. The DirectDraw 3D tests seem to fail correctly, so at
> least 3D is not around. There is likely some limited 2D support
> though. It shouldn't be that hard to fix the tests.

Something like this -- I haven't tested this on affected Win64 systems.

- Reece

Hi,
> Do you mean this problem?
> ddraw:dsurface start ...

Nope and nothing about 64bit (there was no change). I was initially
talking about changed result from last Friday. To be precise this
new information showed up under WinXP 32bit on nvidia 8600GT:


dsurface.c:3511: Test failed: IDirectDrawSurface_Flip returned
0x00000003
dsurface.c:3528: Test failed: IDirectDrawSurface_Flip returned
0x00000003


And i had a slight feeling, that i saw you, Oldrich, doing some
changes in this are. Thus decided to substitute "paranoid android"
aka testbot(a)testbot.winehq.org.

Last note, intel card i915gm does not fail on this "Surface_Flip"
and thus i decided to pinpoint this issue for nvidia.


Regards,
W.

[Oldřich Jedlička]

Hi W,

On Monday 09 August 2010 12:31:45 wylda(a)volny.cz wrote:
> Hi,
> >
>
> Do you mean this problem?
> > ddraw:dsurface start ...
>
> Nope and nothing
> about 64bit (there was no change). I was initially
> talking about changed
> result from last Friday. To be precise this
> new information showed up
> under WinXP 32bit on nvidia 8600GT:
>
> dsurface.c:3511: Test failed:
> IDirectDrawSurface_Flip returned
> 0x00000003
> dsurface.c:3528: Test
> failed: IDirectDrawSurface_Flip returned
> 0x00000003
>
> And i had a slight
> feeling, that i saw you, Oldrich, doing some
> changes in this are. Thus
> decided to substitute "paranoid android"
> aka testbot(a)testbot.winehq.org.

> Last note, intel card i915gm does not fail on this "Surface_Flip"
> and
> thus i decided to pinpoint this issue for nvidia.

Ah, now I see (just
describe the full problem the first time, I don't have a witch ball :-)).
The nvidia driver doesn't return DD_OK like it should (see
http://msdn.microsoft.com/en-us/library/aa915446.aspx), but other non-error
code. I cannot say if this is somehow/totally wrong, but for the test
purposes this can be work-around by changing the mentioned "ok" line to
something like

  ok(hr==DD_OK || broken(hr != DD_OK && SUCCEEDED(hr)),
"text...")

This tells the wine to be correct (hr==DD_OK), but allows
windows tests to fail with the alternative result code.

Could you please
try it/test it?

Thanks,
Oldřich.
> Regards,
> W.

[Stefan Dösinger]

Am Montag 09 August 2010, 21:41:18 schrieb Oldřich Jedlička:
> ok(hr==DD_OK || broken(hr != DD_OK && SUCCEEDED(hr)),
> "text...")
> I think as long as no native app is found that depends on DD_OK it's ok just 
> use ok(SUCCEEDED(hr)) for the sake of readability.