RE: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

[Stefan Dösinger]

I never saw this crashing on any of my systems, so it is probably driver dependent. Which Windows driver are you using?

If the test crashes on either ATI, Nvidia or Intel it is a good idea to remove it. I don't think we should remove it if it crashes on something like VMWare or other 'noname' cards.

d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

[Henri Verbeet]

2008/12/23 Stefan Dösinger :
> I never saw this crashing on any of my systems, so it is probably driver dependent. Which Windows driver are you using?
>
> If the test crashes on either ATI, Nvidia or Intel it is a good idea to remove it. I don't think we should remove it if it crashes on something like VMWare or other 'noname' cards.

The patch is already applied, but I think removing the test is the
right thing to do. I only added the test to test what error d3d9
returns when a NULL shader is passed. If it depends on the driver, I
doubt we care.

d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

[Stefan Dösinger]

> The patch is already applied, but I think removing the test is the
> right thing to do. I only added the test to test what error d3d9
> returns when a NULL shader is passed. If it depends on the driver, I
> doubt we care.

This patch was a good idea, yes

I'm only afraid of this hypothetical scenario:

1) We remove a test because it breaks on $NONSTANDARDWINDRV
2) $BUGGYGAME depends on the tested behavior, and is broken on above driver on Windows too
3) Some future patch changes this behavior
4) The test doesn't warn us because it was removed
5) $BUGGYGAME is now broken on Wine
???) The test removed in (1) is added again because $BUGGYGAME depends on it and the developer who fixes the regression doesn't know about $NONSTANDARDWINDRV

IMHO it is better to use broken() wherever possible, although with a crash that is hard to do.

d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

[Detlef Riekenberg]

On Di, 2008-12-23 at 14:24 +0100, Stefan Dösinger wrote:
> I'm only afraid of this hypothetical scenario:
> - We remove a test because it breaks on $NONSTANDARDWINDRV

We disable the test with:
    if (0) {
        /* that crash on $NONSTANDARDWINDRV */
        <full test here>
    }
> - Some future patch changes this behavior
> - The test doesn't warn us because it was removed

Of course, the disabled test does not protect us from the scenario
above,
but the test is still available for documentation.
> IMHO it is better to use broken() wherever possible, although with a crash that is hard to do.

using broken() on a crashing test will not prevent the crash

d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

[Rico Schüller]

Stefan Dösinger schrieb:
> I never saw this crashing on any of my systems, so it is probably driver dependent. Which Windows driver are you using?
>
> If the test crashes on either ATI, Nvidia or Intel it is a good idea to remove it. I don't think we should remove it if it crashes on something like VMWare or other 'noname' cards.

I checked this on 4 different machines with the following cards all on XP
- Ati 9700M
- Geforce 5700FX
- Geforce 8800GTS
- Geforce 8800GT

Just check the test page to see the d3d9 shader test crashes on all 
machines which didn't skip the complete test! ( 
http://test.winehq.org/data/0b3b6e67ea663e853cc6bb93f4da447ab934e50d/#group_... 
)

Cheers
Rico