Open-Source Radeon HD 6000 Series Still Borked

[smitty3268]

Mesa warning: glDraw[Range]Elements(start 7331, end 8087, count 2373, type 0x1403, indices=0xabc0)
end is out of bounds (max=8086) Element Buffer 21 (size 48714)
This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 11022, end 11057, count 123, type 0x1403, indices=0x11232)
end is out of bounds (max=11056) Element Buffer 11 (size 70440)
This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 794, end 1034, count 504, type 0x1403, indices=0xf00)
end is out of bounds (max=1033) Element Buffer 51 (size 4848)
This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 794, end 1034, count 504, type 0x1403, indices=0xf00)
end is out of bounds (max=1033) Element Buffer 51 (size 4848)
This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 297, end 1072, count 2253, type 0x1403, indices=0x9c0)
end is out of bounds (max=1071) Element Buffer 59 (size 7002)
This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 297, end 1072, count 2253, type 0x1403, indices=0x9c0)
end is out of bounds (max=1071) Element Buffer 59 (size 7002)
This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 297, end 1072, count 2253, type 0x1403, indices=0x9c0)
end is out of bounds (max=1071) Element Buffer 59 (size 7002)
This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 297, end 1072, count 2253, type 0x1403, indices=0x9c0)
end is out of bounds (max=1071) Element Buffer 59 (size 7002)
This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 297, end 1072, count 2253, type 0x1403, indices=0x9c0)
end is out of bounds (max=1071) Element Buffer 59 (size 7002)
This should probably be fixed in the application.

This bit is a known issue with the Unigine code. It doesn't seem to cause any problems, so it's safe to ignore.

https://bugs.freedesktop.org/show_bug.cgi?id=38092

[oibaf]

Yes, Im aware. I use gentoo though, but I will be able to apply thanks to you keeping the revision logs. With "debug pool" I mean a pool, similar to current bug pool on freedesktop, that would list the tasks to perform(and instruction on how) some test on current drivers, directed to people that use open drivers but have no possiblilty to program the changes. Ie, bringing hackers and users together.

You can start experimenting on it if you care, but I am a bit busy to do it myself.

[oibaf]

I'm still searching a way to keep 32bit mesa and libdrm in sync with the main 64bit driver. On debian I do use multiarch xserver/mesa from xorg-edgers ppa and dpkg from 'pu/multiarch/full' branch (but natty already ships it), fedora already has multiarch since 6 years, but what about gentoo? multilib overlay sucks, nobody keeps the mesa/libdrm/xf86-video-ati 9999 ebuilds in sync and they simply don't work. Also, if you use external overlays you can forgot about ia32 because multilib is not in portage and so nobody has to take care of it.

P.S.
oibaf, do you plan to support multiarch in your ppa?

I think that multiarch is supported on oneiric but not on natty (my packages are based on these). IIRC xorg-edgers is trying to backport multiarch to natty but it requires some other packages updates which I prefer not to do in my PPA to avoid breaking things for the others.

[oibaf]

Thanks for reporting it! I've pushed a fix to the glsl-to-tgsi branch on fd.o and GitHub which increases the maximum number of temps from 256 to 4096.

Thanks fo fixing it

Updated packages for the PPA are building right now.

[pingufunkybeat]

That's very cool.

So, this was the last Linux app that did not work with r600g?

[darkbasic]

No, it does work since some months, it didn't work with the glsl-to-tgsi branch, but the fix was easy.

[crazycheese]

Works does not nearly mean it is usable. It is not usable. But this would also be last thing that prevents its usage as a driver, at least for 3D apps.

[darkbasic]

Works does not nearly mean it is usable.

Yeah, that's obvious. We still have a long way ahead before unigine

[whizse]

It's been working almost as long as on r300g, performance seems slightly better on r300g though

[darkbasic]

X1950XTX isn't that fast anymore, really. An HD3870 is already faster in the majority of the scenario. Unigine may be an exception tough, I didn't test it.