Radeon Gallium3D MSAA Mesa 10.1 Git Benchmarks

[smitty3268]

The only thing stopping it from being an extension in the future is for the Architectural Review Board to put it in there. The only aa method I could find in the spec is multisampling. I'd imagine they have a reason for not including other methods in there (I'd guess the reason is, as marek says, that this is something that game developers are supposed to handle).

The reason is that OpenGL is meant to be a low-level API, and as such it mostly is there to give the developer access to features of the hardware.

Post-processing shaders like this can already be done by passing in GLSL shaders to do the work - and by allowing devs to just pass in shaders like normal the entire thing is much more flexible. If someone discovers a certain way of doing it that works well with their engine, they can use that rather than being forced into some generic thing hardcoded into the API for no reason.

Maybe one day these AA capabilities will be built directly into the hardware. That's when you are going to see an ARB extension approved, not before.

[marek]

I can imagine EQAA/CSAA will be exposed as an OpenGL extension, because it's a hardware feature. SMAA is not.

As far as my latest radeonsi patches are concerned, I'll commit them after I test that they don't break r600g.

[curaga]

What a fun thread

or even the existence of RadeonPro for that matter.

Why would Linux devs care about a Windows tool?

As an enthusiast, I've felt the industry has been holding back far too much lately on what we could do.

"The industry" is not holding back anything here in Linuxland. It's a meritocracy, post patches. Marek made r300g and r600g support MSAA. I made capable Gallium drivers do Jimenez's MLAA (which in case you didn't know, is the SMAA precursor, by the same people, and almost exactly equivalent to SMAA 1x - a different, better implementation than the one in AMD Catalyst).

RadeonPro's other features could just as well be implemented here. We already have HUD, too.

Since you clearly care about them, I look forward to reviewing your patches.

[liam]

The reason is that OpenGL is meant to be a low-level API, and as such it mostly is there to give the developer access to features of the hardware.

Post-processing shaders like this can already be done by passing in GLSL shaders to do the work - and by allowing devs to just pass in shaders like normal the entire thing is much more flexible. If someone discovers a certain way of doing it that works well with their engine, they can use that rather than being forced into some generic thing hardcoded into the API for no reason.

Maybe one day these AA capabilities will be built directly into the hardware. That's when you are going to see an ARB extension approved, not before.

The discussion isn't about whether or not these aa methods can be achieved in ogl but where their implementations should reside. OGL is certainly low level but it doesn't map exactly to hardware AFAIK so I don't know that mapping directly to a hardware component is necessary.
Frankly, I don't understand the difference between post/pre processing in this area, so maybe I should just be quiet

[liam]

Yes, the PC gaming community has complained about how NVIDIA/AMD do not implement SMAA in their drivers on Windows, but instead implement inferior solutions like MLAA and FXAA. Neither are desirable. The only way to get SMAA on Windows is either for the game developer to implement it as a graphics option, manually inject SMAA into the game's code yourself with the SMAA injector, or use RadeonPro which automatically forces it in all 3D Direct3D/OGL apps unless otherwise specified.

Rather than look better sometimes, it makes all games look/perform better all of the time. It's not hurting FPS at all -- no, in fact it improves FPS. But let's look at it from a different perspective.

You have a new shiny game with a new shiny $500 graphics cards, but you want to enable all the graphics options to Ultra and use a good amount of AA. If you use MSAA, you cut your FPS by a large margin, and it doesn't look very good, even at 8xMSAA. However, if use RadeonPro to use SMAA 4x Ultra instead, you have higher framerates, and the image looks nicer. It's a win win.

But then you still like playing some of your older games on Steam, but these games just can't make use of your GPU because the graphics are too crud to max out your hardware. For that, you can take the texturelod slider from default and lower it to -2 so that textures in your old games become more detailed, thus improving your image quality and utilizing that graphics card a bit more. Furthermore, you can also use it with modern graphics techniques like SSAO and HBAO with SMAA, and maybe even SweetFX to improve the colours, to make your games much more enjoyable. I mean really, don't you think I'd rather have better graphics than have 300FPS with only half my GPU being utilized?

In any case, it's still a win win for users. I mean honestly, high end graphics cards are sold to gamers, so why not implement features that improves games and gives gamers want they want? As an enthusiast, I've felt the industry has been holding back far too much lately on what we could do.

Since it works well what's the problem? Implement radeonpro for the open drivers.
I do question that you get both better looking and faster games.
Perhaps curaga or marek could chime in here?

[smitty3268]

The discussion isn't about whether or not these aa methods can be achieved in ogl but where their implementations should reside. OGL is certainly low level but it doesn't map exactly to hardware AFAIK so I don't know that mapping directly to a hardware component is necessary.
Frankly, I don't understand the difference between post/pre processing in this area, so maybe I should just be quiet

It would be easy enough to stick it into the drivers, just like MLAA is. In fact, the whole post-processing system in gallium is setup to allow adding new effects like this, so all you'd have to do is implement the shader and plug it in. It should be a really simple project for anyone interested in doing it.

I don't know if there's any IP issues involved - i remember Jimenez specifically granted Mesa the rights to his MLAA implementation, because i think it was non-free or something incompatible by default.

[mmstick]

Since it works well what's the problem? Implement radeonpro for the open drivers.
I do question that you get both better looking and faster games.
Perhaps curaga or marek could chime in here?

You can always Google to see for yourself about what users of RadeonPro experience. If you are familiar with how we enthusiast PC gamers work, we monitor our framerate latencies and framerates all the time when gaming. We don't really look at benchmarks since we are pretty much always benchmarking when gaming thanks to having a framerate counter and GPU load graph overlaid through an OSD like what RadeonPro provides. There's one testimony I see from this gamer on YouTube: http://www.youtube.com/watch?v=rj8-PpmJ6pI in which he explains it. This is also a nice chart of the kind of frame latency improvements one guy reported with using RadeonPro with his crossfire setup: http://forums.overclockers.co.uk/sho...php?t=18499549 As for who will implement this stuff into open source drivers, I'm not a driver programmer.

[mmstick]

It would be easy enough to stick it into the drivers, just like MLAA is. In fact, the whole post-processing system in gallium is setup to allow adding new effects like this, so all you'd have to do is implement the shader and plug it in. It should be a really simple project for anyone interested in doing it.

I don't know if there's any IP issues involved - i remember Jimenez specifically granted Mesa the rights to his MLAA implementation, because i think it was non-free or something incompatible by default.

SMAA is MIT-licensed so it is compatible.