If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
- r128, r100, r200. Don't really need it, as we understand these really well, and the code for them is rather self-documenting.
- Power management. We have most of the AtomBIOS stuff for power management, and it's being tested out, but we don't actually have docs for it. We still know how to do it, though.
- UVD/UVD2. We will never see full UVD2 docs. Get used to it. UVD is another story, though; docs for that will show up at some point. Doesn't really matter, though, since we can use a shaderful state tracker (from Gallium) to do most of what these chips do.
- Context management. This ability just doesn't exist, so of course there's no docs on it.
- AES chip. Ditto.
What about the Rialto AGP-PCIE-bridge? AGP cards still aren't really supported.
Yes, they do. Also afaik most of the people who have been dedicating a bigger part of their attention span on r6xx/r7xx 3D last Spring and so have been AMD/ATi paid developers (including the ones they pay Novell to provide). If it wasn't for them, we wouldn't probably have nearly as much of the r6xx/r7xx specific code done in Mesa. (community attention seems to have been focusing more on r1xx-r5xx) And yes, they keep in touch with the community developers, both directly and through bridgman. And yeah, writing a documentation books is no small feat either.
Yes, I am sure they did have internal docs, but you need to work on them a lot before rel.easing them to the public.
Thanks, now I feel happier I bought an AMD/ATI system, and looking forward to buy a dedicated ATI PCIe card some time later this year.
Yes, I am sure they did have internal docs, but you need to work on them a lot before rel.easing them to the public.
That's not at all what I said. I said the paid AMD/ATi developers had to write the internal docs. They published them close to last new year after which community has had the chance to participate in the coding effort. (but as I said, haven't apparently been very interested)
This conversation belongs to the opensource side, neeh?
Hey, guys, I'm here to help, as alway, we at Arch Linux try our best to contribute to the Linux environment. catalyst 9.6 and kernel 2.6.30 can work together it requires patching the kernel and the 9.6 catalyst, instructions:
Thanks, kensai. There were reports of a stream of kernel error messages when using one of these patches (but that might have been a KCL patch rather than kernel patch). Did you see anything like that ?
Thanks, kensai. There were reports of a stream of kernel error messages when using one of these patches (but that might have been a KCL patch rather than kernel patch). Did you see anything like that ?
In fact, I didn't see anything like that.
We still get the very awesome:
[fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_close] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7f8d6f439000,handle:0xd2400000
from dmesg All in all performance is way better now at least on my laptop, and I feel happy again. Maybe 9.7 will make me angry again, but oh, well, that is life.
Comment