r300/500 rant

[curaga]

While it's certainly nice to hear performance tuning happening, wasn't the goal to have it working before tuning?

ie. have it working, in a stable release, would be more useful IMO. Then maybe more people would have a a chance at helping with the speed.

[marek]

While it's certainly nice to hear performance tuning happening, wasn't the goal to have it working before tuning?

I think the driver becomes more stable than current r300c (the classic non-Gallium one).

ie. have it working, in a stable release, would be more useful IMO. Then maybe more people would have a a chance at helping with the speed.

Anyone is encouraged to help us out but that doesn't seem to happen. The only crucial thing missing is support for chipsets with no vertex processors (like ATI Xpress). Also, there seems to be no point in releasing it when it's about 4 times slower than the classic driver.

-Marek

[rohcQaH]

Also, there seems to be no point in releasing it when it's about 4 times slower than the classic driver.

how did that happen by the way? One of the selling points of the G3D architecture was better performance, so where are the bottlenecks?

[HokTar]

Also, there seems to be no point in releasing it when it's about 4 times slower than the classic driver.

Is the situation that "bad"?

I hope Michael will present some test results about it soon.

[curaga]

If everything works on supported chips, then why not release? Speed is not an issue if it's feature-complete.

Yeah, I'm aware that you'd see benchmarks totally crushing it, but so what? I'll say it again that having a stable release is pretty crucial.

[pvtcupcakes]

If everything works on supported chips, then why not release? Speed is not an issue if it's feature-complete.

Yeah, I'm aware that you'd see benchmarks totally crushing it, but so what? I'll say it again that having a stable release is pretty crucial.

There won't be stable release until Mesa 7.8 comes out at least. I don't know if that's the plan or not though.

So the Gallium driver might be stable right now, but since it's part of Mesa it needs to wait for Mesa to release.

[BlackStar]

how did that happen by the way? One of the selling points of the G3D architecture was better performance, so where are the bottlenecks?

On one hand, you have code that has been in development for years (classic Mesa driver). On the other hand you have code that's been in development for months (G3D driver). No wonder the latter is slower at this point.

Personally, I find it very impressive that GLSL 1.10 seems to be working already, with 1.20 being in the works. This means my code will be able to run on OSS drivers in the not-too-distant future, nice!

[marek]

how did that happen by the way? One of the selling points of the G3D architecture was better performance, so where are the bottlenecks?

I don't think so. One of the selling points of G3D was easier driver development and maintenance, which is true. There is another level of abstraction between OpenGL and the driver and that *might* incur higher CPU (driver) overhead than the classic Mesa drivers have. We're yet to see where we can get.

If everything works on supported chips, then why not release? Speed is not an issue if it's feature-complete.

Not so feature-complete, the support of ATI Xpress chipsets is missing. My bet is Mesa 7.9.

-Marek

[marek]

Personally, I find it very impressive that GLSL 1.10 seems to be working already, with 1.20 being in the works.

GLSL 1.2 is already in place. What's missing is support for code branching, loops, and partial derivatives instructions (from the top of my head).

-Marek

[EmbraceUnity]

While using kernel modesetting, whenever I run certain games, like nexuiz or morrowind in Wine (only outdoor cells), I get massive corruption. Yet that corruption persists until I reboot my computer.

Here is what glxgears looks like after such an event.

http://embraceunity.com/?attachment_id=452