AMD/Linux vs Intel/Microsoft - Microsoft Windows

This is a discussion on AMD/Linux vs Intel/Microsoft - Microsoft Windows ; "Tony Hill" wrote in message news:55d6a143c75f5b8a7acfc4b414b34b5f@news.1usenet .com... > > FWIW at least in theory WinNT was designed to be very portable. The > entire system was built with a hardware abstraction layer that was > supposed to minimize the amount ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 38 of 38

Thread: AMD/Linux vs Intel/Microsoft

  1. Re: AMD/Linux vs Intel/Microsoft


    "Tony Hill" wrote in message
    news:55d6a143c75f5b8a7acfc4b414b34b5f@news.1usenet .com...
    >
    > FWIW at least in theory WinNT was designed to be very portable. The
    > entire system was built with a hardware abstraction layer that was
    > supposed to minimize the amount of architecture-specific code. Now,
    > I'm not sure just how successful this attempt was, but the basis is
    > there. At various times NT was reported to have been running on
    > PowerPC and MIPS in addition to the Alpha, i386 and IA-64 instruction
    > sets that it was officially released for. Combined with the upcoming
    > AMD64 port that makes for a fairly impressive array of architectures,
    > though several of them were stillborn.
    >
    >


    My first NT box was a MIPS based DEC 5000 (or some such thing) prior to
    Alpha being done (I was investigating graphics support for Alpha/NT). A DEC
    group in Seattle (DECWest) did the work as far as I remember. At the first
    NT developers conference, I recall that they made a lot of noise about how
    NT was designed to be portable across architectures. Much later on, in
    connection with some console firmware research - I noted that OpenBoot had a
    "thin veneer" implementation of the "BIOS" interfaces that allowed NT to
    boot on Alpha which apaprently had been used for PowerPC (again IIRC froma
    hazy memory).

    The basic problem really is that the Windows market is a shrink wrap SW
    market. Despite interesting things like FX!32, other architectures just had
    no real advantage unless SW vendors (including Microsoft!) would provide
    native implementations of their apps.




  2. Re: AMD/Linux vs Intel/Microsoft

    Fred Kleinsorge wrote:
    >
    > The basic problem really is that the Windows market is a shrink wrap
    > SW market. Despite interesting things like FX!32, other
    > architectures just had no real advantage unless SW vendors (including
    > Microsoft!) would provide native implementations of their apps.


    Shrink-wrap needn't be a barrier.

    Two things that the average software house aren't willing to pay
    for are...

    Buying machines of every flavour of supported hardware.
    Running a full testing exercise on all platforms.

    If MS (or anyone else) had really wanted RISC editions of NT to
    succeed, they could have done worse than given away zillions of
    x86->RISC cross-compilers. Sure, it wouldn't have been properly
    tested on the new platform, but most software isn't properly
    tested on the developer's platform either. )

    One thing the average user isn't willing to pay for is...

    Buying new copies of all the apps he or she has already paid for.

    MS presumably *had* fully tested and supported RISC versions of
    (say) Office, but failed to include them on the distribution CD.
    (It wouldn't have been hard, since most of the Office bloat is
    in text and graphic resources. There's not much code in there.)



  3. Re: 3D driver availability

    >
    > Adapting drivers to the quirks of various systems is non-trivial,
    > so I don't blame them for not issuing multiple versions. However
    > all manufacturers of anything should be publishing their complete
    > interface specification, timing requirements, etc. so that anyone
    > can build an accurate driver. This doesn't even require that they
    > publish the source to their own drivers, although doing so would
    > probably be helpful to both sales and the public, not to mention
    > driver quality.
    >


    IMHO - Not gonna happen.

    Just exposing the register definitions isn't enough to write functioning
    code - trust me - I've done this for a living. You need some theory of
    operation to go along with it, and even better some code samples, or a
    real-live engineer who can answer your questions. Nor is just understanding
    the HW alone enough. Quite often it is the SW techniques which drive the HW
    that is critical to get the card to perform. How that HW/SW interaction
    works may well have been part of how the chip was designed - but it may not
    be obvious by looking at the HW spec.

    Exposing the HW spec and theory of operation (and/or code) exposes what the
    vendors view as their "crown jewels" to their competition. So, a graphics
    vendor develops the HW and a NT driver using their own resources and which
    is _highly_ optimized. They sell the driver as a binary, and don't expose
    their IP.

    They hire a contractor, and give them some minimal HW documentation and
    "perhaps" a peek at the NT code and have them write a Linux driver. The
    Linux guy takes the DRI/DRM/XAA/Mesa base and hacks something up that mostly
    works (but probably doesn't optimally work - heck it may punt TCL). They
    don't expose the interesting interfaces directly to the public, but only the
    relatively uninteresting ones. They don't have to take advantage of
    whatever cool new stuff that the HW provides, and the result is "good
    enough" for the handful of people using Linux for 3D graphics.

    They execute legal agreements with system vendors to allow the vendor to see
    the "good stuff" for porting to a proprietary UNIX. And they don't do this
    often or lightly. Not enough volume. *And* you have given a 3rd party
    access to your crown jewels.

    Windows is where the volume and the money is at, you don't risk that for low
    volume Linux/UNIX markets.




  4. Re: 3D driver availability

    In comp.arch CBFalconer wrote:

    > For all you know a part of the driver may be required to upload a
    > program in goombah machine code to the device to launch it. That
    > may save a ROM, or ease modification, and the reluctance to
    > publish is because that goombah code exposes trade secrets.


    IIRC Matrox' G-series cards require microcode for the triangle setup
    engines and for some reason or other the instruction set could not be
    released to the public. They got around it by including some precompiled
    binary chunks in the public DDK and saying "use these".

    -a

  5. Re: 3D driver availability


    "chrisv" wrote in message
    newsan.2004.01.09.15.09.25.921442@nospam.invalid...
    > On Fri, 09 Jan 2004 03:47:06 +0000, Bogdan wrote:
    >
    > > chrisv wrote:
    > >
    > >>You can't tell me it would take all THAT much manpower for a company
    > >>like ATI to compile their drivers for the half-dozen or so leading Linux
    > >>distributions.

    > >
    > > It does take THAT much manpower and more.

    >
    > Sorry, I don't understand how. They've done the driver in source code
    > already. They've written insructions on how to compile the kernel
    > modules. How much of the end-user's time do they expect this whole
    > process to take? An hour? That seems to be the maximum reasonable time
    > to expect an end-user to take to get a dang driver installed.


    The whole point of running Linux is to "roll your own". There are DOZENS of
    distro's out there and there is no point to releasing a binary level driver
    for each one.

    You have Linux, learn how to use it.



  6. Re: AMD/Linux vs Intel/Microsoft

    In comp.arch Stephen Sprunk wrote:
    > "GreyCloud" wrote in message
    > news:5IiLb.383$ss.17870@bcandid.telisphere.com...
    >> The porting was by DEC. DEC had to pay for the whole port. Trouble
    >> was, NT couldn't compete against OpenVMS and TRU64 UNIX on the
    >> Alpha. Not enough features and pretty rough around the edges.
    >> DEC dropped developement for M$. M$ let the other vendors do the
    >> port of NT to their perspective platforms. When the vendors finally woke
    >> up, they dropped NT.

    >
    > Were there any platforms besides i386, Alpha, and MIPS?


    PowerPC.

    >
    > S
    >


    --
    Sander

    +++ Out of cheese error +++

  7. Re: 3D driver availability


    > They've never put enough effort towards drivers, even for WINDOWS,
    > IMHO.


    linux doesn't need fancy 3d drivers

    it uses the cpu for x rendering


  8. Re: 3D driver availability

    Mainframe Linux (JBailo) wrote:

    >
    >> They've never put enough effort towards drivers, even for WINDOWS,
    >> IMHO.

    >
    > linux doesn't need fancy 3d drivers
    >
    > it uses the cpu for x rendering


    So this is another area you know nothing about
    --
    To start your shiny new Pentium IV in Gameboy mode just enter
    C:\win


  9. Re: 3D driver availability

    Kevin Lawton wrote:

    > chrisv wrote:


    > If a manufacturer chooses to not supply drivers for your chosen OS then
    > what is the point in 'spitting into the wind' building a machine to run
    > that OS using parts lacking in decent driver support ?
    >


    Exactly. I needed a new photo printer and have used canon in the past. But
    when I started using linux I found the driver support for canon printers
    sucks and this is canon's fault IMHO. Epson and HP provide the info for
    good drivers to be written or actively support linux themselves so guess
    whose printer I bought? A hint, it wasn't Canon. Maybe they don't care that
    I bought someone else's $400+ printer just because they don't want to be
    involved with linux?
    --

    Stacey

  10. Re: AMD/Linux vs Intel/Microsoft


    "Ken Hagan" wrote in message
    news:btmom4$cga$1$8300dec7@news.demon.co.uk...

    > If MS (or anyone else) had really wanted RISC editions of NT to
    > succeed, they could have done worse than given away zillions of
    > x86->RISC cross-compilers. Sure, it wouldn't have been properly
    > tested on the new platform, but most software isn't properly
    > tested on the developer's platform either. )


    That may be true of the vendors that you deal with, but most application
    vendors take testing pretty seriously because it has a direct effect on
    customer satisfaction (revenue) and support costs (expense).

    The commercial vendors that I'm familiar with would (and did) consider
    a cross compilation environment with no opportunity for testing a
    non-starter.

    Heck, the CAD vendors only certify and support specific versions
    of the graphics card drivers!

    Tom



  11. Re: AMD/Linux vs Intel/Microsoft

    Tony Hill writes:

    > there. At various times NT was reported to have been running on
    > PowerPC and MIPS in addition to the Alpha, i386 and IA-64 instruction
    > sets that it was officially released for. Combined with the upcoming


    My first WinNT box was a MIPSpower (MIPS cpu) machine running 3.5.1.
    We used it to run a cheaper (than unix) version of Pro/Engineer
    (parametric CAD software).

    They did work and were fairly fast at the time.

    --
    -rupa

  12. Re: AMD/Linux vs Intel/Microsoft

    Tim Shoppa wrote:
    +---------------
    | ... but all that may have to be re-done... AGAIN. Linux doesn't
    | suffer nearly so much from this stupidity (but it does, to some extent,
    | as many manufacturers distribute binary-only drivers for Linux.
    | That's not the fault of Linux, although many regard binary-only
    | drivers as pure evil.)
    +---------------

    In some cases the manufacturer simply has no other choice. A good case
    in point is for wireless devices (e.g., 802-11.{b,a,g}) in which some
    aspect of the transmission (frequency, power, or encoding, say) is
    dynamically controlled directly by the driver software [so-called
    "software-defined radios"]. The FCC has ruled that the end-user *must*
    not be able to alter those characteristics of the driver, since it
    might result in the device no longer meeting its emissions requirements.
    See "Section C: Software Modifications" in the following:

    http://ftp.fcc.gov/Bureaus/Engineeri...nology/Orders/
    2001/fcc01264.pdf>

    Sam Leffler, in particular, has been working to create a standard for
    an API to the FCC-mandated binary parts of wireless drivers (as well as
    parts considered vendor-proprietary) for open-source operating systems
    (sort of like the old MS-DOS "NDIS" driver API for networking cards),
    starting initially with the Atheros chipset and the Linux & FreeBSD
    operating systems, to encourage more wireless manufacturers to support
    open-source operating systems. See:

    http://cvs.sourceforge.net/viewcvs.py/madwifi/madwifi/
    README?rev=1.17>






    -Rob

    -----
    Rob Warnock
    627 26th Avenue
    San Mateo, CA 94403 (650)572-2607


  13. Re: 3D driver availability

    Followups exclusively to COLA.

    In comp.os.linux.advocacy, Peter Köhlmann

    wrote
    on Sun, 11 Jan 2004 00:12:32 +0100
    :
    > Mainframe Linux (JBailo) wrote:
    >
    >>
    >>> They've never put enough effort towards drivers, even for WINDOWS,
    >>> IMHO.

    >>
    >> linux doesn't need fancy 3d drivers
    >>
    >> it uses the cpu for x rendering

    >
    > So this is another area you know nothing about


    It gets worse. Some of the cheaper embedded chips "steal"
    memory from the main CPU. I'm assuming this is set up
    somewhere in the BIOS but have no idea as to the details.
    So in a sense the card *does* use the CPU -- or the memory
    attached thereto, anyway -- although this is hardly Linux-specific.

    Of course the graphics chip itself has accelerator components.
    Presumably the OpenGL driver knows how to wiggle those registers
    to get its job done.

    --
    #191, ewill3@earthlink.net
    It's still legal to go .sigless.

  14. Re: 3D driver availability

    In comp.arch Mainframe Linux wrote:
    > > They've never put enough effort towards drivers, even for WINDOWS,
    > > IMHO.

    >
    > linux doesn't need fancy 3d drivers
    > it uses the cpu for x rendering


    DRI helps for more than 3D... X on a raw framebuffer is fine with a simple
    window manager and no truetype or other complex fonts, but it's an utter dog
    when running relatively modern applications, window managers and fonts
    without a proper accelerated driver.

    --
    Nate Edel http://www.nkedel.com/

    "I say we take off and nuke the entire site from orbit. That's the only way
    to be sure." -- Ripley, _Aliens_

  15. Re: 3D driver availability

    David Utidjian wrote:
    >

    .... snip ...
    >
    > One can get a very decent card from Nvidia for under US$100 and
    > one that is decent for under US$50. While it would be nice if we
    > could get the specs from Nvidia or they would completely
    > open-source their drivers I have no problem with the current
    > ones. The stock XFree86 "nv" driver works just fine in 2D.


    Conceded that that sort of thing handles 98% of most needs today.
    However I miss the ability to build cheap systems from commercial
    hardware from the ground up. This enables one to correct faults,
    avoid copyrights, etc.

    As an example 20 years ago I could buy a complete Kaypro, replace
    the EPROM, and be running entirely on my own code. No disk drives
    were necessary for some applications. Nothing was hidden - every
    component was fully documented and replaceable. I can't do the
    equivalent today. This makes such systems unsuitable for critical
    applications, such as medicine, aeronautics, voting, even
    financial.

    --
    Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
    Available for consulting/temporary embedded and systems.
    USE worldnet address!



  16. Re: 3D driver availability

    In article ,
    Kevin Lawton wrote:
    > So, if you are running an 'alternative' Op System like Linux or BeOS, then
    >you can get decent drivers to rn your Matrox, nVidia or S3 Savage card no
    >problem.
    > Ultimately, won't this just leave ATI 'out in the cold' while
    >non-Mocro$oft users opt for better-supported hardware ?


    Leaving aside that many people do use ATI's Linux drivers
    successfully:

    A BOTE calculation with reasonable assumptions about number of card
    sales dependent on some particular alternate OS, revenue to the OEM, and
    size and cost of a graphics driver engineering and support team focusing
    on that OS, what pops out the back end is that oficially supporting the
    major flavors of Linux is in the ballpark of a break-even proposition,
    while supporting any other alternate OS is done at a loss. The BeOS,
    BSD, etc. markets are too small to be relevant to companies shipping
    tens-hundreds of millions of chipsets/year.

    Jon

  17. Re: 3D driver availability

    On Wed, 14 Jan 2004 00:33:33 +0000, Jon Leech wrote:

    > In article ,
    > Kevin Lawton wrote:
    >> So, if you are running an 'alternative' Op System like Linux or BeOS, then
    >>you can get decent drivers to rn your Matrox, nVidia or S3 Savage card no
    >>problem.
    >> Ultimately, won't this just leave ATI 'out in the cold' while
    >>non-Mocro$oft users opt for better-supported hardware ?

    >
    > Leaving aside that many people do use ATI's Linux drivers
    > successfully:
    >
    > A BOTE calculation with reasonable assumptions about number of card
    > sales dependent on some particular alternate OS, revenue to the OEM, and
    > size and cost of a graphics driver engineering and support team focusing
    > on that OS, what pops out the back end is that oficially supporting the
    > major flavors of Linux is in the ballpark of a break-even proposition,
    > while supporting any other alternate OS is done at a loss. The BeOS,
    > BSD, etc. markets are too small to be relevant to companies shipping
    > tens-hundreds of millions of chipsets/year.


    I hear that Linux is surpassing (or pretty darn close) Apple in desktop
    share. Apple seems to be split about 50-50 between Nvidia and ATI graphics
    sets. I don't know how that factors in to BOTE calculations but it MUST be
    putting Linux in a better position than it was.

    Another factor that I found surprising the first time I heard about it is
    that, for Nvidia at least, they are working closely with the movie
    industry in providing the drivers they need for their really high end
    cards. I heard a talk by a group of people from Dreamworks at Linux World
    Expo-NYC (I think it was 2 years ago). There seems to be a big push in
    Hollywood SFX houses not just for render farms but for Linux on the
    desktop of their artists. They tend to buy the really high end graphics
    stuff like Nvidias Fire GL. They buy them every time there is a new one
    and they buy them by the hundreds if not thousands. How many gamers buy a
    US$500+ Fire GL card? Probably not many. These SFX houses have a certain
    amount of suction with the chipset makers since they are buying the high
    margin stuff. I think the reason we have seen decent drivers from Nvidia
    is largely thanks to the SFX market. I am not sure where ATI fits into
    that picture... though I suppose it must try.

    -DU-...etc...

  18. Re: AMD/Linux vs Intel/Microsoft

    In comp.arch Tom Morris wrote:
    >
    > "Ken Hagan" wrote in message
    > news:btmom4$cga$1$8300dec7@news.demon.co.uk...
    >
    >> If MS (or anyone else) had really wanted RISC editions of NT to
    >> succeed, they could have done worse than given away zillions of
    >> x86->RISC cross-compilers. Sure, it wouldn't have been properly
    >> tested on the new platform, but most software isn't properly
    >> tested on the developer's platform either. )

    >
    > That may be true of the vendors that you deal with, but most application
    > vendors take testing pretty seriously because it has a direct effect on
    > customer satisfaction (revenue) and support costs (expense).
    >
    > The commercial vendors that I'm familiar with would (and did) consider
    > a cross compilation environment with no opportunity for testing a
    > non-starter.
    >
    > Heck, the CAD vendors only certify and support specific versions
    > of the graphics card drivers!


    Once you read the changelogs you will fast get to the point where you
    say "oh, I see why". GFX drivers seem to be fast moving into complexity
    levels that the companies have trouble handling.

    >
    > Tom
    >
    >


    --
    Sander

    +++ Out of cheese error +++

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2