Page 15 of 111 FirstFirst ... 513141516172565 ... LastLast
Results 141 to 150 of 1109

Thread: "Ask ATI" dev thread

  1. #141
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by bridgman View Post
    I think the issue is that we don't have a link to the AGP hotfix driver on the main download page, so if you just follow the links you end up with a driver that doesn't include the AGP IDs.

    I believe support for AGP under Windows will be in the next Catalyst driver -- if not then we should try to make the hotfix driver more visible.
    I think that was the real point I was making...

  2. #142
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,033

    Default

    So far I've seen usb sticks and wlan cards with the Penguin on the box.
    Gigabyte's and Via's websites mention Linux right next to other supported OS's on their motherboards.

  3. #143
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by curaga View Post
    So far I've seen usb sticks and wlan cards with the Penguin on the box.
    Gigabyte's and Via's websites mention Linux right next to other supported OS's on their motherboards.
    Heh... Things are changing. I just looked at a batch of SanDisk thumb drives. Penguin was on the packaging, Having said this, the graphics card manufacturers and a raftload of others think that putting the Penguin on there means implicit support if it breaks. Give it time.

  4. #144
    Join Date
    Jun 2007
    Posts
    406

    Default

    Quote Originally Posted by Svartalf View Post
    Heh... Things are changing. I just looked at a batch of SanDisk thumb drives. Penguin was on the packaging, Having said this, the graphics card manufacturers and a raftload of others think that putting the Penguin on there means implicit support if it breaks. Give it time.
    well, usr puts the penguin on their recent hw, gigabyte and via does enable support for it netgear releases routers with open source code and firware (this is awesome) but most of the producers will not put the penguin on the boxes since they'd be forced to prepare drivers for the products. on windows is simple since it is the same after some years, but on linux is more difficult since the drivers need to be tested with the ongoing kernels. selling penguin stuff without drivers to clients that aren't aware of how to make them work would be nonsense because they's lose customers.
    so the problem with linux certification is this.

  5. #145
    Join Date
    Dec 2007
    Posts
    90

    Default

    Isn't it so that once a driver for a certain piece of hardware is in the mainstream kernel, it's more or less supported automagically in Linux for the conceivable use-life of that piece of hardware (e.g. 3-5 years)?

    So the challenge for hardware manufacturers isnīt that hard:
    -develop hardware device (what they did anyway)

    -release engineering spec. into OpenSource community

    -assist the startup of the codebase that goes into the mainstream kernel

    -monitor if new editions of the kernel don't break your code and pray to deity of choice that the kernel hardware device driver structure model doesn't get a major overhaul

    -sit back and enjoy life being a hardware vendor who's stuff works in Linux !!

  6. #146
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,402

    Default

    If the programming model doesn't change from one model to the next that works, but for things like graphics cards with nearly 10,000 registers and frequent changes in core capabilities it doesn't work so well. Most of the driver (the part that has to keep changing) is outside the kernel, fortunately, so at least the kernel code (DRM) (no, not that DRM, the other DRM) doesn't have to keep spinning.

    I don't know the exact numbers, but I would guess that >90% of the driver code for both open and closed source drivers is outside the kernel.

    The main things we need IMO to get Tux on the box are (a) board vendors have to feel Linux market is important and have a Linux support policy in place (even if it's "no support"), and (b) Linux driver support needs to arrive on roughly the same schedule as Windows support so the board vendors can include Tux in the box graphics.

  7. #147
    Join Date
    Dec 2007
    Posts
    90

    Default

    Once I typed out my "rule" and hit 'Post' I realised that graphics cards are THE exception to the "rule" because they typically don't get bundled up in the mainstream kernel.
    So you are right in setting me straight, bridgman!

  8. #148
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,402

    Default

    Nobody wishes they were the same more than me. When I joined ATI I had been writing device drivers and working on graphics hardware for years, but I was totally blown away by the size of PC graphics drivers even back in the Rage Pro days.

    "What, a million lines of code for a DRIVER ? Are you nuts ?"

    Anyways, that was 10 years and millions of lines of code ago

  9. #149
    Join Date
    Sep 2006
    Location
    PL
    Posts
    910

    Default

    is that clean code, or are there per-application performance [and other] hacks? :>

  10. #150
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,402

    Default

    Not much per-application, but a lot of general performance optimizations -- developed through testing individual applications -- which can get pretty complicated and make the code a lot bigger.

    Making the chips draw triangles is pretty straightforward (I believe the current 3d open source driver is about 15k lines, although mesa itself is obviously a lot bigger), but taking full advantage of all the performance enhancements in the chips makes the driver *way* more complicated. Workstation apps often behave quite differently from consumer apps and need different code paths for best results.

    Since we don't use the mesa stack in our closed driver we need the full GL implementation, not just the ASIC-specific bits, so that adds a lot of code as well.

    Then again, as big as our driver stack may be I guess it's still a good bit smaller than (X + mesa + X driver + DRM + mesa driver) -- not a fair comparison because X includes input and window functions, but not all that unfair either.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •