OpenGL 3.3 renderer rewrite

[joevenzon]

I'm planning on rewriting the rendering engine from scratch using OpenGL 3.3. The main reason for rewriting the rendering engine is to make it easier to support multiple types of texture maps and materials (instead of this "miscmap" nonsense), multiple UV sets, precomputed tangent space for cheaper normal mapping, and so on. The reason for using OpenGL 3.3 is because it's fairly well supported now (Geforce 8 and up or equivalent), the API is nice and clean, and I want to play with the new features. For cards that don't support OpenGL 3.3, they'd get the crap-graphics-no-shaders fallback mode. Thoughts? Complaints? Outrage?

[abs1nth]

sadly mac os x currently only supports opengl 2.1 plus many extensions from opengl 3.x:

http://developer.apple.com/graphicsimagi...abilities/

[joevenzon]

Windows only supports OpenGL 1, but you can get around the lack of OS support with GLEW. I wonder if it's the same thing with OSX. Do you have an OpenGL 3 compatible card to test with? Running "glewinfo | grep VERSION" should show what GLEW detects.

[portets]

what was wrong with my post?

i don't see a reason for why it was deleted.

[thelusiv]

I never saw it portets, I certainly didn't delete it. When did you post? In this thread? Are you sure it was successful?

[portets]

yeah, i'm positive it was successful. i refreshed the page and it was there after i posted. i think it was a few hours after abs1nth said:

sadly mac os x currently only supports opengl 2.1 plus many extensions from opengl 3.x:

i then mentioned that i think gl 3.3 would be a good idea and that it's features vs compatibility seems well balanced for what we want.

i also asked something about the renderer being abstracted enough to support leaving 2.1 in place, allowing vdrift to go to gl 2.1 mode when it detects an incompatible card. that way, people that have 2.1 but not 3.3 support could see shading in it's current form. and the 2.1 mode would also probably be less supported, allowing the 3.3 renderer to gain more development attention.

[fudje]

Requiring GL3 features effects would really suck for anyone using opensource drivers on Linux or BSD (and this includes anyone with ATi R500 or earlier chipset, because they're not supported by Catalyst any more)... There's a pretty high chance that a sizeable chunk of the GL3/4 specs will never be included in Mesa3D because of patent issues.

[charlieg]

If you want to re-write the renderer (again? didn't this happen somewhat recently?) then you may as well adopt Ogre or another decent graphics engine. Then you don't have to worry so much about opengl versions.

Certainly it comes with advanced support for materials.

[NaN]

Requiring GL3 features effects would really suck for anyone using opensource drivers

Are open source drivers able to run current shader path?

There's a pretty high chance that a sizeable chunk of the GL3/4 specs will never be included in Mesa3D because of patent issues.

There's a pretty high chance that Mesa3D won't be able to run any sufficient complex 3d game at playable frame rates. Given that 3d speed is not even a priority for the developers: "From a high-level RedHat point-of-view we aren't interesting in gaming level drivers. ..."

re-write the renderer (again? didn't this happen somewhat recently?)

As long as nobody gets hurt and we get rid of some of the restrictions of the current one, why not?

you may as well adopt Ogre or another decent graphics engine.

There is an Ogre implementation already: http://vdrift.net/Forum/viewtopic.php?t=1316

It would be cool if we had some minimal graphics interface to allow for multiple renderer implementations(GL3, GL2, ...). Something like being able to upload some vertex attributes, textures and pick a shader/rendering layer.

[fudje]

Are open source drivers able to run current shader path?

No, but pretty much only because of the use of floating point textures.

There's a pretty high chance that Mesa3D won't be able to run any sufficient complex 3d game at playable frame rates. Given that 3d speed is not even a priority for the developers: "From a high-level RedHat point-of-view we aren't interesting in gaming level drivers. ..."

Neither are the AMD Linux Catalyst guys, who are effectively adapting workstation graphics drivers to run on consumer hardware. As it happens, on my (IGP) Radeon 4200, fglrx is barely faster than recent mesa3d versions when vdrift is run without shaders at this point. It's 'unplayable' on either with the shaders enabled (setting aside the shader path issues that mostly result in rendering errors). I haven't tested with nouveau, but I hear reports from some other games that it's less RAM (don't know about VRAM) intensive than the nVidia binary blob and gives higher frame rates in some situations.

My concern is only that persons with graphics cards that aren't so old and can handle sufficient shader complexity to make vdrift look like it's a new game rather than one programmed in the mid 90s, but aren't supported by any vendor-supplied closed source driver, might be being excluded. This includes anyone with an Intel IGP, and a not insignificant number of Radeon users.

[abs1nth]

Windows only supports OpenGL 1

this is a completely different situation. windows only ships with OpenGL 1.1. headers and only supports 1.1. (software rendering?) unless nvidia/ati/intel video drivers are installed.

on mac os x there are proper headers but there is no way to get around the 2.1+extensions limitation by installing anything.

[abs1nth]

fglrx is barely faster than recent mesa3d versions when vdrift is run without shaders at this point

this article found out that fglrx is multiple times faster than mesa3d for any game other than vdrift and they suspect that vdrift is hitting a bug in fglrx:


http://www.phoronix.com/scan.php?page=ar...q111&num=1

[joevenzon]

I run ubuntu 10.04 with my ati radeon 4850 and the fglrx drivers and get a much higher framerate than my old nvidia 7900gt. Where the 7900 would get 30 FPS I'm usually over 100 FPS.

[joevenzon]

i also asked something about the renderer being abstracted enough to support leaving 2.1 in place, allowing vdrift to go to gl 2.1 mode when it detects an incompatible card. that way, people that have 2.1 but not 3.3 support could see shading in it's current form. and the 2.1 mode would also probably be less supported, allowing the 3.3 renderer to gain more development attention.

Yeah, I was thinking about doing that. It wouldn't be too hard to leave the 2.1+ code in place as is. It sounds like people definitely want that.

[joevenzon]

this article found out that fglrx is multiple times faster than mesa3d for any game other than vdrift and they suspect that vdrift is hitting a bug in fglrx:
http://www.phoronix.com/scan.php?page=ar...q111&num=1

It's definitely not a bug in fglrx. I think his test results are in error; I sent him an e-mail. There's a similar weird result for his NVIDIA testing:
http://www.phoronix.com/scan.php?page=ar...q111&num=4