Announcement

Collapse
No announcement yet.

Limited ATI support?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • LinuxID10T
    replied
    Originally posted by DanL View Post
    Great. We need something to desensitize and train our young men for WW3
    Nah, this is what we need for that http://www.youtube.com/watch?v=eg8Bh...layer_embedded

    Leave a comment:


  • DanL
    replied
    Originally posted by LinuxID10T View Post
    Just wanted to chime in, Battlefield 3 has amazing graphics. Best from a shooter I have ever seen, by far. Crysis 1 and 2 have nothing on it.
    Great. We need something to desensitize and train our young men for WW3

    Leave a comment:


  • LinuxID10T
    replied
    Originally posted by DanL View Post
    If you're trying to play Battlefield3 on BSD, you're doing it wrong...
    Just wanted to chime in, Battlefield 3 has amazing graphics. Best from a shooter I have ever seen, by far. Crysis 1 and 2 have nothing on it.

    Leave a comment:


  • DanL
    replied
    Originally posted by Panix View Post
    You can't use ATI cards in BSD? Well, only HD 4xxx cards work and only using the open source driver? So, if you bought an Evergreen or NI card, you can't use it at all? CLAP, CLAP... Way to go ATI/AMD! Great support. How are things with Windows these days?
    If you're trying to play Battlefield3 on BSD, you're doing it wrong...

    Leave a comment:


  • Wilfred
    replied
    Originally posted by BlackStar View Post
    To a driver developer, maybe; to the rest of teh world, not really. Everyone (beside you) is speaking about "Gallium3d drivers" not "Gallium3d internals API inside the Mesa driver".



    I stated exactly four things:
    (a) "some BSD developers have started porting the necessary kernel infrastructure"
    (b) "this requires manpower"
    (c) "Gallium3d is a moving target"
    (d) "BSD support for modern 3d is worse than Linux"



    You confirm that (a) is necessary and I recall Phoronix reporting on this work a few months ago.



    You confirm that (c) is a fact. (New features may entail changes to Gallium3d, the kernel drivers and the state tracker).

    (b) and (d) are conjectures based on evidence.

    This is getting silly.
    AFAIK there is a difference between gallium3d and kernel mode setting which does live within the linux kernel. So yes, gallium3d is a moving target, but what would be required for the various bsd's would be to port the kernel mode setting stuff to the kernel of the bsd's. As Airlied indicated the kernel mode setting stuff has been api/abi stable for years. So as I understand it the churn in the gallium3d stuff does not influence the amount of work necessary to port the kernel mode setting stuff required.

    The official intel drivers do not use gallium3d, but do require kernel mode setting.

    Leave a comment:


  • 0x00000000
    replied
    Originally posted by agd5f View Post
    Linux barely has enough desktop market share to make it worthwhile, *BSDs have even less.
    I think you are very wrong ! There is a huge ever-growing-amount of linux users, and the same, maybe not as-big-as-linux-but-huge-nevertheless, for bsd.

    Originally posted by agd5f View Post
    Where do you draw the line?
    Exactly where Nvidia draws their line too, support for (free)bsd.


    obviously at this point bsd users are better-off with a nvidia card,
    but im hoping you will use your ability to change this.

    Leave a comment:


  • yogi_berra
    replied
    Originally posted by Panix View Post
    I notice that 2D is alleged to work. But, who wants a card with no 3D?
    People setting up a server where the display will ultimately be a putty terminal. Which, coincidently, is the best interface for Linux as well.

    Leave a comment:


  • agd5f
    replied
    Companies invest in what will give the best return on their money. Unless there is some incentive (major market, lucrative contract, good PR, etc.) to port your driver to another OS, it's a lot of effort with little return. Linux barely has enough desktop market share to make it worthwhile, *BSDs have even less. The open source drivers are X11 licensed so any OS can pick them up and port them if you are willing to put in the effort. Where do you draw the line? *BSDs? BeOS? Joe's custom OS? Karen's OS?

    The main reason the *BSDs had support in the past is because the old DRI infrastructure was so limited it was relatively easy to port (limited hard coded vram and dma allocations); as it evolved into a modern gfx stack with KMS, the bar got much higher. Unfortunately, that old limited interface was barely adequate 10 years ago. It's nearly impossible to support new asics with the old DRI stack which is why we only support them with KMS.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by airlied View Post
    Gallium3d isn't a generic thing. Its just a bunch of driver internals API inside the mesa driver.
    To a driver developer, maybe; to the rest of teh world, not really. Everyone (beside you) is speaking about "Gallium3d drivers" not "Gallium3d internals API inside the Mesa driver".

    The problem with your statements are they are very unspecific and misleading.
    I stated exactly four things:
    (a) "some BSD developers have started porting the necessary kernel infrastructure"
    (b) "this requires manpower"
    (c) "Gallium3d is a moving target"
    (d) "BSD support for modern 3d is worse than Linux"

    To get r600g working on BSD the kernel needs to expose the radeon DRM interfaces necessary for r600g, i.e. the radeon GEM API.

    To get nouveau working on BSD the kernel needs to expose the nouveau DRM interfaces necessary for nouveau, i.e. the nouveau GEM API.
    You confirm that (a) is necessary and I recall Phoronix reporting on this work a few months ago.

    Gallium is only an abstraction layer. To add new features for new GL things, you have to update the gallium abstraction layer, the Mesa state tracker that talks to it, and then the individual drivers for each hw component. If one of the individual driver components (r600g, nouveau) needs a new kernel interface to expose a feature, then you need to add a new kernel API, not every feature will need a new API exposed, and every hw driver is different.
    You confirm that (c) is a fact. (New features may entail changes to Gallium3d, the kernel drivers and the state tracker).

    (b) and (d) are conjectures based on evidence.

    This is getting silly.
    Last edited by BlackStar; 25 September 2011, 11:56 AM.

    Leave a comment:


  • airlied
    replied
    Originally posted by BlackStar View Post
    You are saying that you need to port the kernel infrastructure in order to use Gallium3d nouveau/radeon on BSD. I am saying... the same thing? I'm not sure where your disagreement lies.

    Just to make this clear, what would one need to do in order to run R600g on BSD?

    (My understanding was that you'd need to write/port a kernel driver that exposes the ABI expected by Gallium3d. If you wanted to add a new feature, like e.g. tesselation shaders, you'd have to update both Gallium3d and all relevant kernel drivers - no?)

    Gallium3d isn't a generic thing. Its just a bunch of driver internals API inside the mesa driver. The problem with your statements are they are very unspecific and misleading.

    To get r600g working on BSD the kernel needs to expose the radeon DRM interfaces necessary for r600g, i.e. the radeon GEM API.

    To get nouveau working on BSD the kernel needs to expose the nouveau DRM interfaces necessary for nouveau, i.e. the nouveau GEM API.

    Gallium is only an abstraction layer. To add new features for new GL things, you have to update the gallium abstraction layer, the Mesa state tracker that talks to it, and then the individual drivers for each hw component. If one of the individual driver components (r600g, nouveau) needs a new kernel interface to expose a feature, then you need to add a new kernel API, not every feature will need a new API exposed, and every hw driver is different.

    Dave.

    Leave a comment:

Working...
X