Page 3 of 7 FirstFirst 12345 ... LastLast
Results 21 to 30 of 66

Thread: AMD Pushes Out New R600/700 3D Code

  1. #21
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by 89c51 View Post
    what happens with radeonhd ??
    Why should anyone care?

  2. #22
    Join Date
    Jan 2009
    Posts
    1,593

    Default

    sorry i got confused with all the mesa radeons 2D 3D stuff

    my mistake



    sorry again

  3. #23
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,577

    Default

    Quote Originally Posted by elanthis View Post
    Why should anyone care?
    Now now, of course people should care. It's just not an imminent matter and can be safely ignored for the time being. (maybe even for years)

  4. #24
    Join Date
    Dec 2007
    Posts
    91

    Default

    I've just seen that Google released a plugin for some browsers to be able to render 3d. It requires opengl 2.0, maybe it's time to ask them to contribute with manpower to the development of free drivers.
    I understood they were pushing hard amd and nvidia for open drivers, now that they want the web to take advantage of opengl, pushing open source drivers could be a good way to promote their plugins, by offering a more out of the box experience ?

  5. #25
    Join Date
    Jul 2008
    Posts
    565

    Default Could always be better...

    This is great, though it's still programming for a single chipset. What is needed is a standardized unified driver system for graphics cards like what exists for USB devices now, and like other standards such as firewire. Graphics card makers need to form and support open graphics driver standards so that driver development isn't wasted by only being compatible with specific card chipsets. If you combined the devs in the various driver projects under a single umbrella, Linux graphics would be in a much better state today.
    Last edited by Yfrwlf; 05-06-2009 at 06:43 PM.

  6. #26
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    That's one of the goals of Gallium3D. If it works as hoped, it reduces the amount of device-specific acceleration code significantly and puts it all in one place.

    The current Gallium3D implementation assumes the existence of DRI2, which in turn requires video memory management in the kernel. Once that is stable and merged into the upstream kernel tree you should see greater progress with and usage of Gallium3D by both the 3D and X drivers.

    There's a reasonable chance that most cards will be able to use a "generic" X driver which uses KMS for modesetting and Gallium3D for 2D and video acceleration.
    Last edited by bridgman; 05-06-2009 at 06:50 PM.

  7. #27
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by bridgman View Post
    That's one of the goals of Gallium3D. If it works as hoped, it reduces the amount of device-specific acceleration code significantly and puts it all in one place.

    The current Gallium3D implementation assumes the existence of DRI2, which in turn requires video memory management in the kernel. Once that is stable and merged into the upstream kernel tree you should see greater progress with and usage of Gallium3D by both the 3D and X drivers.

    There's a reasonable chance that most cards will be able to use a "generic" X driver which uses KMS for modesetting and Gallium3D for 2D and video acceleration.
    So while it's not the complete focus of Gallium3D, it *will* allow "generic" cards to use it? I can only hope these generic features will be quite good, and that effort will focus on improving the API so that "generic" cards can be extremely good, featureful, and fast, hopefully to the point at which AMD, Intel, Nvidia, and others can release "generic" cards which won't even require any driver updates.

    Plug-n-play, like UVC/firewire/etc, is what I'm hopin' for. Greatly simplifies life for everyone. ^^

  8. #28
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,577

    Default

    Quote Originally Posted by Yfrwlf View Post
    So while it's not the complete focus of Gallium3D, it *will* allow "generic" cards to use it? I can only hope these generic features will be quite good, and that effort will focus on improving the API so that "generic" cards can be extremely good, featureful, and fast, hopefully to the point at which AMD, Intel, Nvidia, and others can release "generic" cards which won't even require any driver updates.

    Plug-n-play, like UVC/firewire/etc, is what I'm hopin' for. Greatly simplifies life for everyone. ^^
    The way I understood it was that you do have to write a basic card-specific driver for Gallium but the benefits come on high level. As in, every card that has a Gallium driver gets to benefit of all state trackers. As in, you do need to have a card-specific basic access (including KMS and memory manager) to the card but higher level stuff (including access to for X.org (whatever it means, I don't exactly know; I'd guess 2D accel), DRI2, video acceleration using Motion Compensation etc) are done with the state trackers - and might from one perspective come for free. Especially after Gallium matures, a completely new card that someone writes a Gallium driver for would immediately tap into a set of powerful working state trackers so it's a big future investment.
    A developer can correct me if I was misleading or imprecise.
    Last edited by nanonyme; 05-08-2009 at 05:01 AM.

  9. #29
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Yeah, there isn't really such a thing as a "generic" graphics card or GPU (ie one with a standard programming model or register set shared across multiple vendors), and it seems unlikely there will ever be one.

    The programming model for each GPU is constantly evolving, primarily to support new programming standards, both for graphics and for compute. The drivers have to keep changing at the same pace, in order to provide a standard API to other parts of the graphics stack.

  10. #30
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Even individual CPUs, bus architectures, and so on need specific drivers. Even the "generic driver" interfaces that exist (intel-hda, ac97, usb) all end up having tons of per-device tweaks and fixes. Generic is pretty pointless. It's done in the industry as is mostly to save time on engineering, not for consumer or FLOSS friendliness.

Posting Permissions

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