[PATCH] ACPI/Intel: Rework Opregion support

Jerome Glisse j.glisse at gmail.com
Wed Mar 16 07:11:13 PDT 2011

On Wed, Mar 16, 2011 at 2:26 AM, Indan Zupancic <indan at nul.nu> wrote:
> On Wed, March 16, 2011 03:17, Alex Deucher wrote:
>> It's not HDCP, encrypted bluray is the main issue.  And while
>> there are hacks for bluray around already, contractual obligations
>> don't care whether existing hacks are available or not.
> So the contract says to keep it secret, not to make it secure.
> Wonderful.
>> Without going into detail, they are very intertwined.  The hw was
>> designed long before we planned to support open source as much as we
>> are now.  Fortunately, we have been working with our hw teams to make
>> future UVD implementations take the open source driver into account.
> It has nothing to do with open source, if you need to trust the
> driver you're already screwed from a security point of view.
>>> It would be nice to have an open source Fusion based media player/
>>> IPTV decoder, but I guess that's hoping for too much.
>>> I understand if AMD/ATI wants to keep its 3D driver secret, but
>>> hardware video decoding?! If you have to keep it secret it means
>>> shortcuts were taken and it's all insecure anyway. That if it gets
>>> broken the Open source driver gets blamed is ridiculous and more
>>> politics than anything else.
>> We don't keep the 3D engine secret.  Most of the code we've written
>> and specs we've released are 3D engine stuff.  Fortunately 3D is less
>> tied up in drm compared to video.
> That's not what I said, I was talking about the driver. There are always
> details not documented, and plenty of optimisation tricks that make the
> hardware go fast. Just compare the performance of the Windows driver
> with the open source Linux driver. It doesn't give the impression that
> AMD is putting much effort in the open source drivers or that it takes
> it seriously.

People are over thinking and believe secret recipes is what actually
make driver fast. From my experience i would say that it's just the
open source driver stack that is limiting performances, mostly because
it require a huge amount of work. I believe there is several hundred
of engineers working on the closed driver just to optimize it and
improve it while the open source stacks have couple dozen and not all
working on same hw but working on AMD, Intel, NVidia.

You can check that with some of the test that were in r600 demo, iirc
correctly with direct hw access perf were close to theoretical hw


More information about the dri-devel mailing list