Intel--Nvidia merger or acqusition. unlikely, but possible ?

On a sunny day (31 Jul 2006 10:49:50 -0700) it happened "Yousuf Khan"
wrote in
.com:

Jan Panteltje wrote:
Hi, I think this is a difficult issue, as releasing source can give the
competition clear hints _how_ the hardware works.

I have followed some of the discussion about GPL 3, Linux, DRM, and the open
source-ing of drivers in the Linux kernel.
I think that it should not be mandatory.
It would just scare hardware manufacturers away from Linux.
Could be wrong on that, but why should they give away a possible lead they
have in hardware design?

How could telling which registers on the GPU do what function, possibly
help the competition? That's like saying that AMD shouldn't reveal the
function of the 64-bit RAX to R15 registers to Intel because it could
give away internal secrets of their processors.

Well, it could, of course if competition _wanted_ to, they could disassemble
code....
But there may indeed be tricks, special instructions, what is done in soft-
and what is done in hardware... special registers, protocols, instructions.
I have done some hardware design, I sure know you can learn about the
hardware from the software.









I think the reason they
don't want to open-source the drivers is because they don't want to
reveal their dirty little secrets like doing deliberate things to
prevent their hardware from cooperating with a rival's hardware. I'll
cite the Creative Labs vs. VIA incident from a few years ago. Or
perhaps they don't want to reveal the special benchmark optimizations
they've done to get better framerates on a specific game (pretty much
every driver that Nvidia or ATI release is like that).

Actually I think opening up the source would be good for the GPU
industry, it might lead to some hardware level compatibility, which
would obviate the need for things like Microsoft DirectX.

Yousuf Khan

Yousuf Khan wrote:
David Kanter wrote:
Yup, I'm absolutely certain that AMD will bring a level of
professionalism to ATI's corporate culture. It's helped by the fact that
in this acquisition there is a clear boss here -- AMD. There's no
pretension that this is a merger of equals, this is an outright
acquisition. If any sort of changes are required, then one guy will have
the final say. If AMD had gone with Nvidia, then the lines of command
would've been a bit blurred.

I certainly hope so. I was on a CC with some folks regarding the
merger and one of my questions was: "Does this mean I can look forward
to ATI drivers for linux that don't suck ass?" The response: "You
know, that's the first time anyone asked us about that." I think it is
one of those issues that may not be readily apparent to an exec, but
that they will get around to fixing.

First order of business for AMD should be to open-source the ATI
drivers.

That's not ever going to happen. As someone else pointed out, the
device driver contains a lot of information about what the hardware is
doing. For instance, if ATI or NV were to have any code paths that
recognize certain prominent benchmarks and then alter their behavior,
all that would be exposed to the public. Similarly, if ATI or NV had
any algorithms that reduced image quality (when it wouldn't be
noticeable) to improve performance, they'd get jumped on for that
(unjustly so).

It's also quite likely that the driver contains a lot of code which
cannot be GPLed. The Havok physics engine probably requires some code
in the driver, and that's definitely not GPL. etc. etc.

I think what AMD will do is improve the quality of Linux support
substantially, but fall short of fully opening the driver. I could see
opening up a few very noncritical areas of the driver, but not anything
substantial. Of course, maybe we'll all get a pleasant surprise.

Establish good relations with the Linux community right off the
bat. BTW, what CC was it, that you were you on?

It was a call between myself and two guys from AMD (one was Hal Speed,
who is a strategic marketing guy and worked closely on the merger)...it
wasn't a recorded one open to the public, but I doubt it would have
been very interesting to the public at large.

Also having open-source drivers for ATI cards will allow media centre
functions to work through Linux just as well as it works through
Microsoft. Perhaps a version of AMD Live, that makes use of Linux as the
OS rather than Windows, making Live a truly OS-agnostic media centre
strategy. I don't think even Intel can claim that.

I don't think you really need to have open drivers for that to work.
That's actually a really good question, will AMD Live work on linux...I
think most PMs or marketing guys would say it's not worth the effort,
but that would be interesting.

DK

Jan Panteltje wrote:

On a sunny day (31 Jul 2006 10:49:50 -0700) it happened "Yousuf Khan"
wrote in
.com:


Jan Panteltje wrote:

Hi, I think this is a difficult issue, as releasing source can give the
competition clear hints _how_ the hardware works.

I have followed some of the discussion about GPL 3, Linux, DRM, and the open
source-ing of drivers in the Linux kernel.
I think that it should not be mandatory.
It would just scare hardware manufacturers away from Linux.
Could be wrong on that, but why should they give away a possible lead they
have in hardware design?

How could telling which registers on the GPU do what function, possibly
help the competition? That's like saying that AMD shouldn't reveal the
function of the 64-bit RAX to R15 registers to Intel because it could
give away internal secrets of their processors.


Well, it could, of course if competition _wanted_ to, they could disassemble
code....
But there may indeed be tricks, special instructions, what is done in soft-
and what is done in hardware... special registers, protocols, instructions.
I have done some hardware design, I sure know you can learn about the
hardware from the software.

In the example I mentioned, the magazine noticed that Quake? looked
rather ugly with an ATI video card. They renamed it ~Quack.exe and the
detail and image quality went up while the frame rate went down. The
implication was of course, ATI was blatently cheating. Old saying ~never
underestimate the power of a rigged demo to impress.

It is my understanding that ATI drivers have a serious amount of
assembly code in them if not all. I believe this is another problem with
the GPL license. Specifically code should be portable.

I don't think it would be that hard to implement the changes. Managment
can just have the first round of drivers in C and release that via the
GPL. They could hand optimize the code with assembly later to do any
dirty little tricks they want, but at least the vanilla C code could be
Q.C.'d, debugged, and ready for the Unix clones.

On Mon, 31 Jul 2006 12:17:00 -0400, Yousuf Khan
wrote:

First order of business for AMD should be to open-source the ATI
drivers.

Sweet dreams - nobody in their right mind will begin the acquisition
from giving away IP. Besides, Linux market share of
desktop/laptop/workstation is negligible, and if there is any money to
be made off GPU and/or integrated graphics, it's in Windows. Servers
- that's where Linux share matters - are a different kettle of fish,
this market couldn't care less about graphics performance.

NNN

Rick Cortese wrote:
In the example I mentioned, the magazine noticed that Quake? looked
rather ugly with an ATI video card. They renamed it ~Quack.exe and the
detail and image quality went up while the frame rate went down. The
implication was of course, ATI was blatently cheating. Old saying ~never
underestimate the power of a rigged demo to impress.

Well then the solution might be that they should open-source only their
linux drivers, make them clean and free of all demo rigging functions.
I'm sure that's already done inside the current ATI Linux drivers,
since there's no need to compete in Quake framerate competitions in
that platform.

They open-source the Linux drivers and put it out into the public and
like most open-source projects, the public starts improving them
itself.

It is my understanding that ATI drivers have a serious amount of
assembly code in them if not all. I believe this is another problem with
the GPL license. Specifically code should be portable.

I haven't heard anything about portability being necessary in GNU
projects, all that matters is that the source code be made available to
the public. Otherwise, why would they put GaS (GNU Assembler) into the
GCC suite? Reading x86 assembler code could be more than enough to
bring out a driver for Linux on another platform. Somebody must be
smart enough to translate assembler from one platform to another.


I don't think it would be that hard to implement the changes. Managment
can just have the first round of drivers in C and release that via the
GPL. They could hand optimize the code with assembly later to do any
dirty little tricks they want, but at least the vanilla C code could be
Q.C.'d, debugged, and ready for the Unix clones.

Yup.

Yousuf Khan

Yousuf Khan wrote:
Rick Cortese wrote:
In the example I mentioned, the magazine noticed that Quake? looked
rather ugly with an ATI video card. They renamed it ~Quack.exe and the
detail and image quality went up while the frame rate went down. The
implication was of course, ATI was blatently cheating. Old saying ~never
underestimate the power of a rigged demo to impress.

Well then the solution might be that they should open-source only their
linux drivers, make them clean and free of all demo rigging functions.
I'm sure that's already done inside the current ATI Linux drivers,
since there's no need to compete in Quake framerate competitions in
that platform.

As I mentioned before, there is probably a rather substantial amount of
code inside GPU drivers (especially for workstations) that cannot be
GPLed, because someone outside of ATI owns it. For example, most
workstation drivers have a lot of application specific optimizations
and settings that have been heavily tested. Some of those tweaks are
no doubt owned by the application vendor, which may not want to GPL
their code.

You didn't respond to my post discussing the issue of code that cannot
be GPLed...which incidentally, is one of the major reasons why Solaris
is under its own license (some of the elements in solaris aren't owned
by Sun).

Also, you have done nothing to address the problem that GPU drivers
almost certainly contain code that would give a lot of internal details
about the device itself, and would aid a competitor in analyzing it.

They open-source the Linux drivers and put it out into the public and
like most open-source projects, the public starts improving them
itself.

How does this help ATI sell more cards? What is the ROI for this? I
don't think there is much they could gain by open sourcing drivers that
they couldn't otherwise...say by having good linux drivers in the first
place.

It is my understanding that ATI drivers have a serious amount of
assembly code in them if not all. I believe this is another problem with
the GPL license. Specifically code should be portable.

I haven't heard anything about portability being necessary in GNU
projects, all that matters is that the source code be made available to
the public. Otherwise, why would they put GaS (GNU Assembler) into the
GCC suite? Reading x86 assembler code could be more than enough to
bring out a driver for Linux on another platform. Somebody must be
smart enough to translate assembler from one platform to another.

I don't think portability is a requirement...I mean there are open
source drivers, and most drivers are sure as hell not portable.

DK

David Kanter wrote:
As I mentioned before, there is probably a rather substantial amount of
code inside GPU drivers (especially for workstations) that cannot be
GPLed, because someone outside of ATI owns it. For example, most
workstation drivers have a lot of application specific optimizations
and settings that have been heavily tested. Some of those tweaks are
no doubt owned by the application vendor, which may not want to GPL
their code.

That's a separate codebase for those drivers. You don't want to release
such specialized drivers to the public anyways. Just GPL the generic
drivers.

Also, you have done nothing to address the problem that GPU drivers
almost certainly contain code that would give a lot of internal details
about the device itself, and would aid a competitor in analyzing it.

I think this is the least important of all of the concerns. The
graphics card makers aren't the only ones that have balked at releasing
open-source drivers because of this concern. I've seen everyone from
makers of SCSI cards to ethernet cards, all doing this. It's the sign
of an immature company, with an immature corporate culture. You can't
learn anything about laying down the internal chip circuits simply from
their software interfaces. The only thing they're worried about is that
a competitor is going to create a card that is completely software
compatible with their own cards. For example, if Nvidia or Matrox sees
the source code of ATI drivers and creates a card that can use the ATI
drivers, thus saving them the time and expense of creating their own
drivers, or vice-versa.

Actually I think this might actually be a good idea for the GPU
industry, if the GPU makers did start copying each other in there
software interfaces. It would lead to a unified software model for
GPUs, much like there is a unified software model between AMD and Intel
in CPUs. In the case of CPUs, just knowing the software interfaces (aka
the instruction set) has not resulted in internal secrets being
revealed. They should go towards the same model in GPUs.

They open-source the Linux drivers and put it out into the public and
like most open-source projects, the public starts improving them
itself.

How does this help ATI sell more cards? What is the ROI for this? I
don't think there is much they could gain by open sourcing drivers that
they couldn't otherwise...say by having good linux drivers in the first
place.

Well, right off the bat, they will save on Linux support costs by
open-sourcing the drivers. Second their drivers will be included in all
Linux distros right away by default, thus no need to maintain codebases
for SuSE vs. Red Hat vs. whatever. When the drivers are included by
default in each distro, the maintainers of the distro do the testing
and support.

Yousuf Khan