Announcement

Collapse
No announcement yet.

AMD Creates Radeon Technologies Group To Focus On Graphics

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

  • #11
    Originally posted by A_M_Z View Post
    Personally this change will affect Nvidia's market share in the next few years for desktop computing. AMD GPU's is killing Nvidia's top end GPU's in DirectX12 at the moment. AMD is putting in more effort into DirectX 12, but not sure about Vulkan.

    AMD's Vulkan driver should also be very good since it will implement OpenGL 4.2 & OpenGL ES 3.0 (in Mesa 11.0), since that is what Vulkan devices need to implement their drivers.

    AMD is moving slowing towards supporting better open-source AMD drivers in Linux, that is visible, for example the new AMDGPU driver, the Sync to V-Blank option in X and their driver also works very well in Wayland.

    Long story short, I'll be buying the next range of AMD GPU's and get me a AMD Zen CPU

    killing? there is no big games with dx12, and even today i can't play far cry 2 with AA enable with ati/amd drivers because of some bug, i can't read the letters in some games and install a driver (catalyst) in linux without become a nightmare,... i really like to see ati back, out off amd, complety out

    Comment


    • #12
      A dogturd of a company with dogturd support levels. AMD explain why Nvidia 8000 series cards (3 years older) have a Win10 driver yet HD4000 series doesn't ? And don't get me started on HD4000 catalyst linux support.

      Comment


      • #13
        Guess I am the only one that sees that as a wrong move. In early days when the GPUs were independent was the right thing to do. These days devices are moving to more integrated solutions. That's the road AMD took too when made the APU's with integrated graphics. And practically half of AMD products depends on GPU technologies these days. Will that be a future end to the integrated graphics on CPU's?

        Because as an independent division, I don't see much for integration efforts.

        Comment


        • #14
          Originally posted by darkcoder View Post
          Guess I am the only one that sees that as a wrong move. In early days when the GPUs were independent was the right thing to do. These days devices are moving to more integrated solutions. That's the road AMD took too when made the APU's with integrated graphics. And practically half of AMD products depends on GPU technologies these days. Will that be a future end to the integrated graphics on CPU's?

          Because as an independent division, I don't see much for integration efforts.
          If you look at a block diagram the GPU is a different block. It's not like the CPU and the GPU are using the same execution resources, they aren't. They are physically different blocks. When GPU finally got FP64 support a while back there was talk about how the GPU could take over floating point for the CPU, but that's never really been viable due to latency it would take move data from one block to the other.

          Comment


          • #15
            Originally posted by A_M_Z View Post

            I don't see the Fury X in that comparison. Can you confirm this?
            Confirmed.

            It's no coincidence that all the initial benchmarks were 290X vs 980 Ti after all.

            Ever since Microsoft announced DirectX 12, gamers have clamored for hard facts on how the new API would impact gaming. ...

            Comment


            • #16
              Originally posted by A_M_Z View Post
              AMD GPU's is killing Nvidia's top end GPU's in DirectX12 at the moment.
              AMD/ATI has always had as-good-as and sometimes better hardware than nVidia, the biggest difference is that nVidia cares about their drivers a LOT more than AMD does. With DX12 and Vulkan, AMD's hardware will have the chance to shine through without their crappy drivers getting in the way...

              Comment


              • #17
                Originally posted by johnc View Post
                The Fury X is the same as the 980 Ti in that benchmark. It's hard to imagine that's "killing" nvidia.
                It's a sign of things to come. Ashes of the Singularity does not use Async Compute all that much. When games start to make heavy use of it, the difference will become much more marked.

                Here is what a developer from Oxide Games wrote:
                Originally posted by Kollock
                I suspect that one thing that is helping AMD on GPU performance is D3D12 exposes Async Compute, which D3D11 did not. Ashes uses a modest amount of it, which gave us a noticeable perf improvement. It was mostly opportunistic where we just took a few compute tasks we were already doing and made them asynchronous, Ashes really isn't a poster-child for advanced GCN features.

                Comment


                • #18
                  Originally posted by chithanh View Post
                  It's a sign of things to come. Ashes of the Singularity does not use Async Compute all that much. When games start to make heavy use of it, the difference will become much more marked.
                  We don't really know that.

                  Comment


                  • #19
                    I think the reason AMD was beating NVidia so heavily in one of those D3D12 benchmarks is (and please correct me if I'm wrong anywhere):

                    AMD's GPUs have separate graphics (do-everything) and compute-only cores, and the sum of those is greater than what a comparative NVidia card has in CUDA cores. When a game issues compute dispatches to a compute-only queue, these compute cores can work in parallel without stalling or taking up any of the graphics cores. NVidia's CUDA cores however are all do-everything cores, so when lots of compute tasks are dispatched, they take up entire cores even though none of the graphics functionality is used.

                    In D3D11 (and OpenGL) I assume the ordering rules for graphics and compute is the same as for graphics and graphics, namely that they must be logically sequential, so a draw call would have to wait for a compute dispatch to finish before being executed. In D3D12 / Vulkan, only operations queued on the same hardware queue have these ordering requirements, so a game can dispatch on separate compute-only queues (= Async Compute).
                    Last edited by Ancurio; 09 September 2015, 08:40 PM.

                    Comment


                    • #20
                      If they're serious about Linux then it makes sense to continue with the oss path. Otherwise this is going to be the first thing that gets the axe.

                      Comment

                      Working...
                      X