Game road to 1.0

[Stefan Dösinger]

Hi,
In another thread Alexandre has mentioned to wait for game stuff to stabilize 
before the 1.0 freeze. I think its time for another brainstorm of what 
features are still missing which we want in 1.0. The DirectX Todo has a long 
list but it tends to be useless to me. And I see that it can use some more 
cleanup( /me blames Tom-W for not nagging me enough :-) ) It also sounds like 
AJ takes games as an excuse to delay the freeze for the display driver 
cleanup, and I was tempted to take the display driver cleanup as an excuse to 
get more dx stuff in.

So which of the following things do we want for 1.0?

Direct3D:
* Some SM 3.0 features are still missing. Instancing is now in, vertex 
textures and some other stuff still missing. Not widely used among games yet.

* Multithreading. OpenGL part done(except of 3 patches which I'll NOT send for 
now (*) ), but needs synchronisation. Will take a lot of time.

* OpenGL ddraw. Render target locking improvements, multithreading.

* Many games to not run yet, problems on MacOS drivers and fglrx. For the D3D 
part I see that as bugfixes which can happen after the freeze as far as I 
understand things.

* Direct3D10. Will see if someone applies for my SoC proposal.

(*) The patches that do the context selection. I won't send them because with 
my testing patches people started hunting phantom bugs which were the result 
of missing synchronisation.

DirectSound: Maarten plans to work on that for SoC I think. Freezing now would 
make that difficult. Would mean to delay the freeze until September / October 
most at least. I'd personally really apprechiate dsound and alsa working 
better in 1.0.

OpenGL: I don't really know of the windowed opengl state, and the wined3d -> 
wgl move. Still planned?

DirectPlay: Kai works on the protocol, but I think he doesn't plan to 
implement it anytime soon. It seems the current idea is to improve our 
networking libs to get native dplay working.

[H. Verbeet]

On 25/03/07, Stefan Dösinger  wrote:
> So which of the following things do we want for 1.0?

While nice to have, I don't think d3d10 or some of the more advanced
SM 3.0 features should block 1.0. You already know my opinion on
broken drivers.

Things that aren't there, but IMO should be:
- Make GLSL default
- Make FBOs default
- Support HDR / float textures

There are various cleanups that should be done as well (eg, getting
rid of FVFs completely), but I'm not sure if those should block 1.0 or
not.

[Tom Wickline]

On 3/25/07, H. Verbeet  wrote:
> On 25/03/07, Stefan Dösinger  wrote:
> > So which of the following things do we want for 1.0?
>
> While nice to have, I don't think d3d10 or some of the more advanced
> SM 3.0 features should block 1.0. You already know my opinion on
> broken drivers.
>
> Things that aren't there, but IMO should be:
> - Make GLSL default

Well from my test GLSL is just about on par with ARB's performance at this time.

http://wiki.winehq.org/BenchMark-0.9.33
and
http://wiki.winehq.org/BenchMark-0.9.6

I still need to run PCMark04 and file a bug report and 0.9.33 will be complete.

I am aware there are a couple remaining task that need completed
before GLSL is set as default, just thought I would share the
performance state at this time.

Tom

[Scott Ritchie]

On Sun, 2007-03-25 at 10:17 -0400, Tom Wickline wrote:
> On 3/25/07, H. Verbeet  wrote:
> > On 25/03/07, Stefan Dösinger  wrote:
> > > So which of the following things do we want for 1.0?
> >
> > While nice to have, I don't think d3d10 or some of the more advanced
> > SM 3.0 features should block 1.0. You already know my opinion on
> > broken drivers.
> >
> > Things that aren't there, but IMO should be:
> > - Make GLSL default
>
> Well from my test GLSL is just about on par with ARB's performance at this time.
>
> http://wiki.winehq.org/BenchMark-0.9.33
> and
> http://wiki.winehq.org/BenchMark-0.9.6
>
> I still need to run PCMark04 and file a bug report and 0.9.33 will be complete.
>
> I am aware there are a couple remaining task that need completed
> before GLSL is set as default, just thought I would share the
> performance state at this time.
>
> Tom

Does anyone here know if the NVIDIA Windows drivers are still rigged
with regards to the various 3DMark suite of benchmarks?  There was a
scandal a while back, and the company claimed to pull their special
hacks out, but then they were caught again later doing the same thing.
It'd be a shame if we were testing rigged Windows drivers vs unrigged
Linux ones.

Thanks,
Scott Ritchie

[Stefan Dösinger]

> Does anyone here know if the NVIDIA Windows drivers are still rigged
> with regards to the various 3DMark suite of benchmarks?  There was a
> scandal a while back, and the company claimed to pull their special
> hacks out, but then they were caught again later doing the same thing.
> It'd be a shame if we were testing rigged Windows drivers vs unrigged
> Linux ones.

I think the windows driver has a huge game Database with per game 
optimizations. I think I saw it in their control applet, you can even change 
the settings. (I don't have a access to a Windows nvidia machine atm).

Last I knew the Linux driver allows similar tuning. And if someone wants to he 
can write a specialized wine patch and put a per game hack collection 
somewhere. I personally don't think theres anything wrong if nvidia provides 
me with fine-tuned per game settings. Honestly I wouldn't put hundreds of 
hacks into my own code, but if nvidia thinks they can manage that, ok with 
me :-)

[EA Durbin]

> From: Stefan Dösinger 
> To: Scott Ritchie 
> CC: Tom Wickline , [e-mail]
> Subject: Re: Game road to 1.0
> Date: Sun, 25 Mar 2007 18:43:06 +0200
> > Does anyone here know if the NVIDIA Windows drivers are still rigged
> > with regards to the various 3DMark suite of benchmarks?  There was a
> > scandal a while back, and the company claimed to pull their special
> > hacks out, but then they were caught again later doing the same thing.
> > It'd be a shame if we were testing rigged Windows drivers vs unrigged
> > Linux ones.
>
> I think the windows driver has a huge game Database with per game
> optimizations. I think I saw it in their control applet, you can even 
> change
> the settings. (I don't have a access to a Windows nvidia machine atm).
>
> Last I knew the Linux driver allows similar tuning. And if someone wants to 
> he
> can write a specialized wine patch and put a per game hack collection
> somewhere. I personally don't think theres anything wrong if nvidia 
> provides
> me with fine-tuned per game settings. Honestly I wouldn't put hundreds of
> hacks into my own code, but if nvidia thinks they can manage that, ok with
> me :-)

I haven't seen those settings in the linux driver on a per application 
basis. The windows driver does offer per game/application settings, mostly 
for how it is handled if you have a SLI enabled system, whether you want the 
application to be rendered by one video card, or vertical sync SLI etc. It 
also has options to enable/disable anti-aliasing and anisotropic filtering. 
As far as I know you can only specify a global SLI setting in xorg.conf 
under linux.

[Scott Ritchie]

On Sun, 2007-03-25 at 18:43 +0200, Stefan Dösinger wrote:
> > Does anyone here know if the NVIDIA Windows drivers are still rigged
> > with regards to the various 3DMark suite of benchmarks?  There was a
> > scandal a while back, and the company claimed to pull their special
> > hacks out, but then they were caught again later doing the same thing.
> > It'd be a shame if we were testing rigged Windows drivers vs unrigged
> > Linux ones.
>
> I think the windows driver has a huge game Database with per game 
> optimizations. I think I saw it in their control applet, you can even change 
> the settings. (I don't have a access to a Windows nvidia machine atm).
>
> Last I knew the Linux driver allows similar tuning. And if someone wants to he 
> can write a specialized wine patch and put a per game hack collection 
> somewhere. I personally don't think theres anything wrong if nvidia provides 
> me with fine-tuned per game settings. Honestly I wouldn't put hundreds of 
> hacks into my own code, but if nvidia thinks they can manage that, ok with 
> me :-)

"Optimizations" aren't the issue here - hacks that break the application
but still make the benchmark appear to render fine are.

Here is an article discussing the issue:
http://www.extremetech.com/article2/0,3973,1086025,00.asp

Essentially, they completely broke the rendering engine by hard-coding
assumptions about where the camera would be into the driver.  Move the
camera slightly (such as in the developer version of 3D Mark), and
everything is a garbled mess.

This defeats the entire purpose of a benchmark as a real-application
performance test, since the benchmark is converted from a simulation of
real game rendering calculations to instead be a glorified movie.

Thanks,
Scott Ritchie

[Stefan Dösinger]

> Essentially, they completely broke the rendering engine by hard-coding
> assumptions about where the camera would be into the driver.  Move the
> camera slightly (such as in the developer version of 3D Mark), and
> everything is a garbled mess.

OK, I take the optimizations back, I didn't know what exactly they were doing.

What I was thinking about when I talked about a performance slider a few days 
ago was playing around with some glHint parameters, or the worst thing, 
giving the user the ability to force drawStridedFast instead of 
drawStridedSlow, but that would be close to what nvidia was doing here(if the 
story is true).

[Stefan Dösinger]

Am Sonntag 25 März 2007 15:13 schrieb H. Verbeet:
> On 25/03/07, Stefan Dösinger  wrote:
> > So which of the following things do we want for 1.0?
>
> While nice to have, I don't think d3d10 or some of the more advanced
> SM 3.0 features should block 1.0.

Agreed. Those features won't be really relevant for a long time(Except 
Microsoft's exclusive Vista games). My concern is that with SoC we may get 
some extra boost in that area which we would kill prematurely if we freeze at 
an unfortune moment. Getting new developers is more important than shipping 
1.0 IMO
> Things that aren't there, but IMO should be:
> - Make GLSL default
> - Make FBOs default
> - Support HDR / float textures

Agreed. Those should be the minimum for 1.0. Appart of flipping the GLSL and 
FBO switch those are mainly bugfixes for me.
> There are various cleanups that should be done as well (eg, getting
> rid of FVFs completely), but I'm not sure if those should block 1.0 or
> not.

Yeah, various areas could need some cleanup(as usual). The surface / texture 
handling is a bit limited too.

[H. Verbeet]

Actually, something else that affects quite a few games is support for
.ani cursors.

[Tom Wickline]

On 3/25/07, Stefan Dösinger  wrote:
> Hi,
> In another thread Alexandre has mentioned to wait for game stuff to stabilize
> before the 1.0 freeze. I think its time for another brainstorm of what
> features are still missing which we want in 1.0. The DirectX Todo has a long
> list but it tends to be useless to me. And I see that it can use some more
> cleanup( /me blames Tom-W for not nagging me enough :-) )

Hi Stefan,

Ahh, nothing like a kind invite to nagg someone about the area of Wine
that im most interested in. To be serious, if there is something
that's missing or that can be added to the DX-ToDo that would be of
real world use....just let me know and ill try my best to do what I
can or nagg ;) someone into helping me get it on that page or another
page if needed.

My wish list in no particular order:
SM 3.0 / HDR support
Improved CAPS support
GLSL / FBO,s as default
Multithreading support

Tom

[Roderick Colenbrander]

> OpenGL: I don't really know of the windowed opengl state, and the wined3d
> -> 
> wgl move. Still planned?

OpenGL needs to get proper windowed opengl rendering support. The best route to that seems to be by using opengl child windows. There's a patch for it but it needs cleanups and then AJ needs to accept it ..

After that the rest of OpenGL can be cleaned up. For instance the pixelformat limitation can be lifted and because of that various things can be done in a proper way. Second multisampling will be possible as well.

After OpenGL is stable, WineD3D can be moved over to WGL.

Regards,
Roderick