Nouveau With Mesa 7.9 Is Better, But Still Slow

[cl333r]

Any word on the patent side of things yet? Was it at all discussed during XDS?

Problem is, all big corps like Google, Oracle, IBM etc etc care much more about the enterprise side then the desktop, hence the desktop stuff (OpenGL stack, modern X stack) are mostly done by relatively few individuals (from corps and communities) hence these problems (in Linux) are traditionally underrated and underdeveloped.
Respectively, if these corps were mostly desktop OS and desktop apps providers (forget mobile), they would have poured tons of money into buying/lobbying/bribing to solve (quickly) pretty much any issues and patents that matter.
That's why these issues get solved slowly despite discussions. Individuals play a more important role here but obviously can't solve them anywhere as quickly as (rich) corps do.

[jabjoe]

In other words, after like 3 years (after ATI started the open-source initiative) neither ATI nor Nouveau (not to mention Intel) have fast and complete open-source OpenGL 2.1 support, not to mention 3.x.

I say it's gonna take another 3 years until we got reliable and fast OpenGL 2.1 support but even today there's many folks already learning the new 3.x so in like 3 years the "fast and reliable" 2.1 version is gonna be too little too late. Not grumpy, it's true.

No, this is the whole point. With Gallium3D, OpenGL is just another state tracker, and the driver is nothing directly to do with it. When ATI and Nouveau Gallium3D is fast, little and ideally nothing, would need changing for a new OpenGL (or any other graphics API). The new state tracker would get written once and it would work with all the Gallium3D drivers. The graphics API is completely abstracted away from the driver.

[whizse]

Right, except I was more interested in how the Mesa devs are planning on handling the situation...

Eric Anholt mentioned on #dri-devel that Intel was fine with just having a configure switch for patented stuff: http://people.freedesktop.org/~cbril...2010-08-31.log

It would be interesting to know if others are okay with that too. I guess most of this is discussed off-list though, so it would be interesting to know how things are progressing.

[mendieta]

http://www.phoronix.com/forums/showthread.php?t=23598

Brilliant, many thanks for the pointer!

[Nobu]

At one point, I was getting really good framerates on freedoom, and there weren't too many artifacts, either. I guess the speed increase was a regression, since it hasn't been that fast since, but the quality is still good.

I posted some screenshots a while back (one a month ago, and another a month before that) on identi.ca, for anyone interested.

...apparently the links expired. Here are the original links: Screenshot 1 Screenshot 2

[Lynxeye]

Nouveau drivers don't use any kind of buffer management that comes with Gallium, which helped us to get a lot of speed. For example pb_bufmgr_* managers are used only in r300g, r600g, and svga. u_upload_mgr is only used in those three plus i965. Maybe they have something in the kernel?

No, nouveau does no caching or suballocation in kernel code, so we are *really* cpu limited at the time, because mapping all the kernel created buffers eats up much cpu time. I am working on integrating pipebuffer in nvfx right now and hope to extend this work to nv50. This should bring a significant performance improvement.

[not.sure]

I am working on integrating pipebuffer in nvfx right now and hope to extend this work to nv50. This should bring a significant performance improvement.

Awesome!