NVIDIA Releases Another 180.xx Beta Driver

[deanjo]

Is there a bug report for that? How much memory your card have?

Running out of vram isn't a bug. 256 Meg cards simply run out.

[bridgman]

And 6 months down the road the RV870 cards will be out and then the waiting game starts again.

but programing for them shouldn't be very different from 6xx and 7xx. Possibly for more advanced features there will be changes (which won't be used by the foss driver).

Bingo. One of the big changes between 5xx and 6xx was virtualizing a good chunk of the hardware; partly having more stuff stored in video memory so the driver developers didn't need to worry about on-chip storage, and partly putting a layer of abstraction between the driver programming model and the actual hw implementation.

This really helped going from 6xx to 7xx, for example; the underlying hardware is quite different on 7xx but the acceleration code didn't have to change much at all. On the other hand it sure makes initial bringup and troubleshooting harder, ask any of the developers involved so far.

For future parts, the good news is that now we are largely "caught up" with the last 6 years of hardwware so we can now start to work on open source docs and code while the chip is being developed, which means we have access to the mega-$$ hardware emulators and can see what is going on inside the chip, not just what the programming model tells you. We had to use the emulators a bit getting 6xx/7xx 3d running; the funny part was that we ended up doing the debug on an as-yet-unreleased GPU because that's what happened to be loaded in the emulator.

EDIT - why do all the really interesting AMD/ATI discussions happen in NVidia threads ? Maybe we should take this outside

[deanjo]

Bingo. One of the big changes between 5xx and 6xx was virtualizing a good chunk of the hardware; partly having more stuff stored in video memory so the driver developers didn't need to worry about on-chip storage, and partly putting a layer of abstraction between the driver programming model and the actual hw implementation.

This really helped going from 6xx to 7xx, for example; the underlying hardware is quite different on 7xx but the acceleration code didn't have to change much at all. On the other hand it sure makes initial bringup and troubleshooting harder, ask any of the developers involved so far.

For future parts, the good news is that now we are largely "caught up" with the last 6 years of hardwware so we can now start to work on open source docs and code while the chip is being developed, which means we have access to the mega-$$ hardware emulators and can see what is going on inside the chip, not just what the programming model tells you. We had to use the emulators a bit getting 6xx/7xx 3d running; the funny part was that we ended up doing the debug on an as-yet-unreleased GPU because that's what happened to be loaded in the emulator.

EDIT - why do all the really interesting AMD/ATI discussions happen in NVidia threads ? Maybe we should take this outside

So your telling me that within 6 months of the RV870 release you will have Crossfire support, current openGL level support, accelerated video support and have the same level of performance as the windows drivers?

[bridgman]

So your telling me that within 6 months of the RV870 release you will have Crossfire support, current openGL level support, accelerated video support and have the same level of performance as the windows drivers?

Sure, but I think we were talking about the open source drivers not the proprietary ones. If you want to match the performance and features of the proprietary Windows drivers I expect you will need to use the proprietary Linux drivers. I believe that will apply to all vendors, not just to us.

Within six months of next generation GPU launch I expect that open source driver support will have all of the capabilities supported by the common open source driver code base, whatever those happen to be. I expect that will include :

- GL2.x support -- not sure what the plans are for GL 3.0 in the open drivers, I expect OpenCL will be higher priority

- accelerated video (probably including some decode accel)

- 2d performance comparable to the best of the open drivers today

- considerably higher 3d performance relative to Windows than the open drivers offer today

As I have mentioned before, we do not currently plan to provide open source support for the proprietary video decoding hardware (UVD) but will investigate whether it is possible. That said, a lot of the decode overhead even for H.264 and VC-1 is spent in functions which can easily be done on the GPU (mocomp, filtering), so I think you will see a fair amount of progress in decode acceleration over the next year whether or not anyone opens up the full decode hw.

[DeepDayze]

one thing I still find with the 180.xx drivers is that flash vids play VERY slow...seems to be a negative interaction between flash and the nvidia driver. The 173.xx series sees to be OK

[deanjo]

Sure, but I think we were talking about the open source drivers not the proprietary ones. If you want to match the performance and features of the proprietary Windows drivers I expect you will need to use the proprietary Linux drivers. I believe that will continue to apply to all vendors, not just to us. We are not intending to replace fglrx with an open driver now or in the future.

Within six months of next generation GPU launch I expect that open source driver support will have all of the capabilities supported by the common open source driver code base, whatever those happen to be. I that will include :

- GL2.x support -- not sure what the plans are for GL 3.0 in the open drivers, I expect OpenCL will be higher priority

- accelerated video (probably including some decode accel)

- 2d performance comparable to the best of the open drivers today

- considerably higher 3d performance relative to Windows than the open drivers offer today

As I have mentioned before, we do not currently plan to provide open source support for the proprietary video decoding hardware (UVD) but will investigate whether it is possible. That said, a lot of the decode overhead even for H.264 and VC-1 is spent in functions which can easily be done on the GPU (mocomp, filtering), so I think you will see a fair amount of progress in decode acceleration over the next year whether or not anyone opens up the full decode hw.

I am talking about the opensource drivers. Judging by your reply the answer is that the opensource drivers will not take full advantage of the hardware's capability. Therefore blobs are the only solution if you want to take full advantage of the hardware. Case and point, if you want limited features and slower performance you go with the opensource alternatives. If you want full feature set , best performance and near same day support, you go blob. It's the features and performance that cause people to buy newer cards, if those features are not supported then why upgrade when you are a foss die hard and the performance and features are going to be crippled by using the foss drivers?

[Kjella]

I am talking about the opensource drivers. Judging by your reply the answer is that the opensource drivers will not take full advantage of the hardware's capability. Therefore blobs are the only solution if you want to take full advantage of the hardware.

It's not reasonable to assume that highly optimized drivers written by a team working closely with the hardware designers will be beaten just like that, if it was then somebody should have been fired. I'd say they would have come far if they have full working acceleration in six months - not optimized and all that but stable, visually correct and within an order of magnitude of the proprietary drivers on all fronts and maybe half performance on average.

It's important to get a little perspective on where we are too - without acceleration many things run ungodly slow, where even a very naive one would probably improve performance by a few orders of magnitude. The first order of business is to make them playable under open drivers at all, then you can start optimizing. There's a lot of slightly older games that could be made playable that aren't. It sure beats a big nothing.

[deanjo]

It's not reasonable to assume that highly optimized drivers written by a team working closely with the hardware designers will be beaten just like that, if it was then somebody should have been fired. I'd say they would have come far if they have full working acceleration in six months - not optimized and all that but stable, visually correct and within an order of magnitude of the proprietary drivers on all fronts and maybe half performance on average.

It's important to get a little perspective on where we are too - without acceleration many things run ungodly slow, where even a very naive one would probably improve performance by a few orders of magnitude. The first order of business is to make them playable under open drivers at all, then you can start optimizing. There's a lot of slightly older games that could be made playable that aren't. It sure beats a big nothing.

Again your just re-enforcing my point:

If you want basic support that maybe as good as the blobs in stability and are satisfied feature loss and slower performance on average then maybe opensource is an alternative.

If you want advanced support and features with great performance that is on par with other OS's, stability because of complete documentation and the close working relationship with their engineers, then the blobs will always have a huge advantage over their foss counterparts thus why everyone claiming "just give us the docs because we can do better" and telling the companies to "scew off and abandon the blobs" are delusional. People upgrade cards for better performance because their present solution is "tapped out". Opensource drivers are the limiting factor when used on a piece of hardware, with the blobs it's usually a case of the hardware has reached it's limits, not the blobs.

[bridgman]

I think there is a place for both. The open source drivers will (of necessity) be smaller and simpler than the blobs because of the huge resource differential -- but simplicity brings a lot of advantages as well. I see the open source drivers potentially being more stable than any of the proprietary drivers, and they will certainly adapt more quickly to changes in kernel and graphics framework.

Modern graphics cards are *really* fast, to the point where it is pretty hard to get GPU-limited on a high end card under Linux unless you run the largest possible screen and crank up all of the visual effects. Our architects figure that the open source 3D drivers should be able to run around 50-60% as fast as the proprietary drivers just by being "clean and elegant", ie without a big investment in performance tuning. A lot of users won't care about that difference.

2D performance is already driven more by enhancements in the server than in the driver (so the open source drivers are often faster), and we expect that to continue. Getting the 3D drivers to the 50-60% performance level will require work at all levels of the 3D stack, but between Gallium3D, GEM and the ongoing command submission restructuring effort most of the key areas are being addressed now.

I agree with you completely that getting rid of the blobs is not practical if we want to address the entire Linux market, but there are a lot of benefits to offering a fairly full-featured open source solution as well.