R600 Open-Source Driver WIth GLSL, OpenGL 2.0

[Qaridarium]

Hired by AMD to work on open source graphics.

realy........ this user only does fun.. payed by nvidia LOL

comedown... this is very important!

we need more people like that everyone needs something to laugh !

i read his statement and laugh very loud !

really! thats important!

[bridgman]

yes...... i realy wrote that only in Wine point of view....
in wine you are lost on an non OpenGl3.2 amd card.

for nativ games.. yes nice....

but..... be sure in the next future time we will have some gread openGL3 only game engines... save a lot of CPU you can play a hardcore game with an monster grafic card on an 1ghz single core CPU.... thats the future of openGL3 engines..

but yes thats the future

So here's something to think about...

I haven't looked at all of the 3.2 extensions related to DX/OGL interoperability, but the ones I did look at have been supported by the hardware since pretty much the dawn of time. agd5f already added support for one or two of them IIRC.

So... as long as Wine checks for specific extensions rather than saying "Can I haz 3.2 ?" there's a decent chance those extensions will be available on older hardware as well.

[Qaridarium]

So here's something to think about...

I haven't looked at all of the 3.2 extensions related to DX/OGL interoperability, but the ones I did look at have been supported by the hardware since pretty much the dawn of time. agd5f already added support for one or two of them IIRC.

So... as long as Wine checks for specific extensions rather than saying "Can I haz 3.2 ?" there's a decent chance those extensions will be available on older hardware as well.

ok nice try again!.......

this works for 'DirectX9b' because OpenGL2.1 is neear by 9B!


this will never work for DirectX9C shader3 +'vertex texturing''texture sampling in vertex shaders'

Because a X1950XTX do not support "texture sampling in vertex shaders"

But vertex texturing is on the minimum feature set of wine!

i can tell you facts these tell you that wouldn't work !
but yes its a shame.....

Wine tells the Programms(gamez,appz) "I'm a 'Nvidia GPU'"
thats because some Gamez only have full features if there a nvidia GPU.

after the handshake "Im a nvidia GPU" the game Pushes out the directX9c-shader3-vertextexturing code....
wine now get the code and translate it to openGL.......

if you port all wine-openGL3.2 extansions to the R500 driver this will never ever work!

because the hardware R500 can not NOT do never ever "texture sampling in vertex shaders"


"So here's something to think about..."

now think abaut that this will never work!

or yes you can render all the missing features by the CPU.....

slow slow slow slow..... 5fps the game will never run fast!

never ever!

http://developer.nvidia.com/object/u..._textures.html

http://www.opengl.org/wiki/Vertex_Texture_Fetch

"
An issue with accessing a texture is the texture format. Your GPU might support a wide range of formats that can be accessed by the TIU of the FS but the TIU of the VS simply doesn't support certain formats. For example, nVidia has published Vertex_Format.pdf when Gf6 was released
Gf 6 supports only GL_TEXTURE_2D of format GL_LUMINANCE32F_ARB and GL_RGBA32F_ARB. It doesn't support any of the other floating point formats or fixed point formats. There is no floating point compressed format.
All other formats besides GL_LUMINANCE32F_ARB and GL_RGBA32F_ARB cause the VS to run in software mode.
Gf 7 is similar to the Gf6.
Gf 8 is a DX10 level GPU and all DX10 level GPUs should support VTF with the same formats supported by the fragment pipe.

ATI/AMD :
ATI/AMD chose not to have VTF in their SM 3.0 GPUs.
X300 up to X1950. All of their standard X series.
They said it would be too slow. It would be better to do Render_To_VertexBuffer (R2VB).
In OpenGL, to do R2VB you would need PBO support. http://www.opengl.org/registry/specs...fer_object.txt
PBO became core in GL 2.1 and ATI's driver do support GL 2.1.
ATI's DX10 parts, in other words all their GPUs with the HD in the name, support VTF.
ATI's driver does report 16 for GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS but users are saying that their shaders don't work."

[BlackStar]

ok nice try again!.......

this works for 'DirectX9b' because OpenGL2.1 is neear by 9B!


this will never work for DirectX9C shader3 +'vertex texturing''texture sampling in vertex shaders'

Because a X1950XTX do not support "texture sampling in vertex shaders"

But vertex texturing is on the minimum feature set of wine!

Good thing that virtually no SM3 game requires vertex texture fetching. This functionality only became mainstream with SM4/DX10 and all such cards support VTF.

In other words, I fail to see what you are trying to say with this example.

[barbarbaron]

not everyone is only interested in wine games.

+1

I'm not expecting to have ass kicking dx9c performance from my gpu in wine too, nor do I care about it. I think the important thing here is to have more game companies port their titles to linux environment. Or a reason for companies like Loki Games to port older titles. And that reason is proper driver support. Mac and linux users combined, opengl graphics stack only people are %10 of all computer users worldwide. It is a good portion to base a business on but something is preventing it.

Despite their opensource evangelism AMD doesn't do much to make this happen and it makes me think AMD is actually hindering the efforts by giving sorta support in both their closed source and opensource drivers. If there weren't people like Corbin Simpson and Marek Olsak (who are independent developers and do most of the gallium3d r300g work now) we would be doomed in gallium3d too -or wouldn't be doomed -. An excerpt from a phoronix.com article:

Contrary to earlier reports stating that the forthcoming id Tech 5 engine from id Software would likely not be ported to Linux due to the involved work, cost, and lackluster Linux graphics drivers (according to John Carmack), it looks like we will end up seeing this next-generation game engine running with Linux.

Carmack is talking about AMD/ATI drivers there.

@Bridgman:

The "specified capabilities" are only specified for Windows (read the box)

From an AMD Linux guy? It doesn't make sense.

I'm not trying to glorify nVidia's binary blob linux support here, but there is an inevitable rule in everything: It has to work first to make a difference.

[Qaridarium]

Good thing that virtually no SM3 game requires vertex texture fetching. This functionality only became mainstream with SM4/DX10 and all such cards support VTF.

In other words, I fail to see what you are trying to say with this example.

you do not understand!

all direktX9c games have 2 complete render-path….

1 for nvidia with VTF and 1 for ati/amd cards with no VTF

ok 'if' wine supports 2 render-path to one the DirectX side to and 2 on the openGL sides ..... you can get the right code into the R500 graficcard!

But!... WINE on the directX side always shows a nvidia card to the software!

thats because some software only has full features with an nvidia card.

in fact! yes the DirectX9C games do not need VTF because they have Ugly fallback non VTF code for outdated cards like the R500 BUT wine do not care abaut that!

wine needs VTF!

openGL2.1+VTF works well but OpenGL2.1 with no VTF wine is doomed!

first time OpenGL3.2 has all the needed features.

to have 1 single DirectX9C+VTF to OpenGL code... witout ati/amd extra code.

[bridgman]

Seriously, any approach which requires hardware from one vendor to behave exactly the same as hardware from another vendor is not going to work long term. If this is true then it's something that will need to change in Wine.

The Wine devs have said multiple times that there is no NVidia-specific code in Wine -- this sounds pretty NVidia-specific to me. Not saying you're wrong, but there is a disconnect there that would be good to get clarified.

[Ghworg]

wine tries to detect what Video card you have and reports that to the directx side. It defaults to an Nvidia card if it can't work out what card you have, which is currently the case for the open radeon drivers.

If you hack the detection routines to add support for VENDOR_MESA and R600 (for example) in the render string, then you can absolutely get it to report that you have an ATI card on the directx side. I've done it.

[barbarbaron]

A graphics driver nowadays is a heap of code as complicated as an OS kernel. With only independent developers it will take ages to reach performance and reliability levels. The future of open source radeon and radeon-gallium3d drivers regarding this:

r200 -> Stay at OGL 1.3. will never reach OGL 1.4 if independent devs don't implement it. AMD left you fellas.

r300 - r500 -> Stay at OGL 1.5. will never reach OGL 2.0 and GLSL if independent devs don't make gallium3d work. AMD left you fellas.

r600 - r700 -> Stay at OGL 2.0 and GLSL. will never reach OGL 3.x if independent devs don't implement it. AMD will leave you fellas.

r800 and beyond -> Stay at X. And leave it to independent devs. AMD will leave you fellas.

As for closed source drivers they will never be feature complete.

So this* is the sorta linux support strategy of AMD. By this strategy AMD keeps its linux user base at a stable level and hinders the linux gaming efforts at the same time.

[bridgman]

That's a pretty good post. It ignores everything we said about our open source strategy, then manages to present what we *did* say as a radical change of direction for the worse and some kind of revelation for the masses. Other than the "leaving" part, what you described *is* the open source plan, worked out with the open source community.

What you fail to mention, of course, is all the work that agd5f has done on 3xx-5xx building the foundation for the new driver stack, but I realize that doesn't fit the message you are trying to convey. If you don't understand this then you might want to take a look at the commit history for KMS over the last year or so.

Our commitment on the open source side has always been to (a) provide documentation and technical support to the development community, to (b) help kickstart the effort by partnering with Novell on a new atombios-based driver, and to (c) help with the development effort in places where even public documentation might not be enough to get new features working quickly.

Independent devs have always been the heart of the open source driver effort, and I don't expect that to change. We never planned to take over the open source drivers or to control their development, and if you ask the development community they will make it pretty clear they don't want that anyways.

On the closed source side, other than video playback which is still WIP, what features do you feel are missing ? Outside of video playback, most of the complaints we hear involve support for new kernel and X versions and testing on a broader range of distros, not missing features.