How Old ATI GPUs Can Be Faster On Open Drivers

[johwes]

What adm does for opensource ...

As someone said before.. i think AMD and other people working on the ATI opensource drivers are doing an awsome job and i'm basing my next purchase because of that support/work. I've run with nvidia hardware for the last couple of years but with my upcoming purchase it will be AMD..And while on the subject.. what card should i be buying?? I want one of the newer cards 6xxx. I dualboot windows for the hardcore games so my linux setup is used most for work/virtualisation although i wouldnt mind getting 3d support in linux aswell. I will want to run gnome3 and would love to get some acceleration.

/J

[Drago]

LiquicAcid, what is your progress with s3tc on r600g. You mentioned some mipmapping issues before. Also you said something with the command stream checker in the kernel. I am interested as a developer. Unfortenately, I do not have graphics programming background, but I am interested.

[Hephasteus]

Another thing to keep in mind is that you have to compare apples to apples. An X1950 has more memory bandwidth and shader resources than an HD2400 for example. You need to compare comparable families (e.g., an X1950 and an HD3850).

Any video card on the planet that just got struck by lightening has more shader resources than an HD2400. Except of course the one nvidia mobile 8400GS and the hd3450 which only has 8 stream packs the same as hd2400. Good for cell shader work and some really really really easy t&l work but NOTHING else.
The thing that is most frustrating about open source drivers is that laptops are being a giant sucking black hole of attention needs sucking the life out of it. When for all the galliant effort they are going to die in a horrible powder metal fire sooner or later. Somone needs to thermite them all and get it over with.

[LiquidAcid]

LiquicAcid, what is your progress with s3tc on r600g. You mentioned some mipmapping issues before. Also you said something with the command stream checker in the kernel.

See the bugreport I mentioned before. I described my finding on a (mobile) RV630. The same approach fails on a RV740.

I am interested as a developer. Unfortenately, I do not have graphics programming background, but I am interested.

Neither do I. I only have basic OpenGL knowledge.

[LiquidAcid]

right if you use the cpu its legal

I didn't say that. I only said that using the hardware capabilities to sample from compressed textures isn't problematic from a legal point of view, since the vendor already payed the license fees. The usage of the libtxc_dxtn is a totally different issue.

[marek]

I didn't say that. I only said that using the hardware capabilities to sample from compressed textures isn't problematic from a legal point of view, since the vendor already payed the license fees. The usage of the libtxc_dxtn is a totally different issue.

Not true. IIRC, the s3tc license must be purchased for each combination of driver/hardware/OS. I guess ATI has a license for Catalyst/RadeonHD/Linux.

[LiquidAcid]

Not true. IIRC, the s3tc license must be purchased for each combination of driver/hardware/OS. I guess ATI has a license for Catalyst/RadeonHD/Linux.

I'd like to see a source of that statement. I can see why one needs a license for the hardware, but why a license for each combination?

If we leave libtxc_dxtn out of the picture then there is neither code inside mesa (and the drivers) that implements compression which the patent covers nor code that implements decompression.

The only place where the patent applies is 'inside' the GPU, when sampling from compressed texture data. How could it matter how the texture data ended up in VRAM/GTT?

Quote from the patent abstract:

An image processing system includes an image encoder system and a image decoder system that are coupled together. The image encoder system includes a block decomposer and a block encoder that are coupled together. The block encoder includes a color quantizer and a bitmap construction module. The block decomposer breaks an original image into blocks. Each block is then processed by the block encoder. Specifically, the color quantizer selects some number of base points, or codewords, that serve as reference pixel values, such as colors, from which quantized pixel values are derived. The bitmap construction module then maps each pixel colors to one of the derived quantized colors. The codewords and bitmap are output as encoded image blocks. The decoder system includes a block decoder. The block decoder includes a block type detector, one or more decoder units, and an output selector. Using the codewords of the encoded data blocks, the comparator and the decoder units determine the quantized colors for the encoded image block and map each pixel to one of the quantized colors. The output selector outputs the appropriate color, which is ordered in an image composer with the other decoded blocks to output an image representative of the original image. A method for encoding an original image and for decoding the encoded image to generate a representation of the original image is also disclosed.

I fail to see where we have such an image decoder/encoder system (that the patent covers) in mesa. I only see such a system implemented (and only the decoder part) inside the GPU, so the patent can only (from my POV) affect the GPU hardware and not the software driving it.

I'm not a lawyer but my common sense simply can't follow this reasoning...

[smitty3268]

Technically, i guess it only depends on what AMD has licensed from S3. If their licensing agreement states that they are only getting the license for a certain combo of drivers/OS/hardware, then anything else would not have the license. From a common sense standpoint, that doesn't make much sense, but then lawyers and software patents have never made much sense.

I don't have any clue what the actual license agreement says it is good for.

[Thatguy]

Crazycheese, same answer as the last few times you asked...

If there was a reliable and reasonably accurate way to track opensource driver usage (one which was reasonably immune to being gamed or scripted) then I'm sure that information would get considered in our development plans at some point. I haven't heard of or seen any approaches which meet those criteria yet. Self-selecting mechanisms such as response forms aren't even close. Let's say we get 23,654 responses all saying "I only use open source drivers" - 100% of users, right ? Now, let's look at that in the context of say 100M units sold per year - now we're down to 0.025% market share, which means we have too many developers working on Linux already.

That said, our commitment is to provide documentation and/or sample code and developer support to let the driver dev community build good open source drivers without having to reverse-engineer the hardware, not to develop those drivers ourselves, and we have been doing that for a few years now, so I'm not sure why you feel it is so important for us to provide additional developers.

It seems to me that the first thing you are asking for is a wholesale change in strategy, maybe the "give up on the workstation market and focus our efforts on the consumer Linux client business so we can justify diverting more resources to open source drivers" approach ?

IP adress and card serial number.

simple enough.

[smitty3268]

IP adress and card serial number.

simple enough.

Did you even read Bridgman's response? You can do that, and the number of responses you get is going to be way, way, WAY under 1% of total sales. Which would then mean they'd end up cutting Linux developers. If you mean they should compare responses from Linux users to Windows users, that opens up the whole "gaming the system" argument.