Announcement

Collapse
No announcement yet.

Linux Kernel Set To Finally Retire AMD 3DNow!

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

  • #31
    My recollection is that 3DNow! was designed for and initially used for vertex processing in geometry pipelines, since most of the early graphics cards only had pixel processing hardware.

    It made a big difference with the graphics cards of the time and IIRC also with software 3D renderers, but as graphics cards started to include vertex processing (~12 years after introducing 3DNow!) the use cases for vector instructions changed from 3D to multimedia and general compute.

    3DNow! evolved as well but my impression is that the real architectural advantages of 3DNow! were for the 3D use cases.
    Test signature

    Comment


    • #32
      Originally posted by mitch074 View Post
      For a while, 3DNow! was referenced as "Integer SSE", eventhough it's false - both SSE and 3DNow! could process 64-bit FP values. SSE could do pretty much the same, but also added the ability to process 128-bit values.
      Neither SSE nor 3dnow are able to work with 64-bit FP values. That only came with SSE2. 3dnow packed two single precision (32-bit) floating point values into a single register (the 3dnow register file was aliased with the x87 registers, so you couldn't use both at the same time), and SSE introduced the 128-bit xmm registers containing 4 32-bit FP values.
      Last edited by jabl; 13 December 2021, 01:24 PM.

      Comment


      • #33
        Originally posted by willmore View Post
        So we add features with hundreds of KLOC, but we remove a small chunk of well tested code because...progress?

        At least they didn't remove support for these processors entirely.
        Yep, there are millions of other bs lines of code to remove. Like the graphic drivers. A light and universal cpu vulkan support a la lavapipe should be enough to drive graphics until mesa or blobs are installed.
        Last edited by rmfx; 13 December 2021, 01:15 PM.

        Comment


        • #34
          Originally posted by mitch074 View Post
          both SSE and 3DNow! could process 64-bit FP values
          That is false. Read the PDF documentation (the link is below).

          Originally posted by mitch074 View Post
          SSE could do pretty much the same, but also added the ability to process 128-bit values.
          The main point of SSE is that it added separate 128-bit registers. x87, MMX and 3DNow share the same 64-bit registers.

          https://www.amd.com/system/files/TechDocs/21928.pdf

          Comment


          • #35
            I guess time to upgrade my server machine already...

            Comment


            • #36
              Originally posted by atomsymbol View Post
              That is false. Read the PDF documentation (the link is below).

              The main point of SSE is that it added separate 128-bit registers. x87, MMX and 3DNow share the same 64-bit registers.
              https://www.amd.com/system/files/TechDocs/21928.pdf
              FP64 : true, sorry. It could process 2 FP32 values in a single instruction,which doesn't make it a FP64 unit.
              Registers : SSE added 8 more registers while 3DNow! shared the 8 existing MMX registers, true - and it's a GOOD THING they did, due to how starved for registers the x86-32 arch is... And considering Intel created SSE to prevent 3DNow! from becoming prevalent (as it had been adopted by all its x86-32 competitors), they had to make it better. AMD had already done good with 3DNow! by allowing simultaneous processing of 2 FP instructions in a single cycle, SSE had to be better everywhere.

              Comment


              • #37
                Originally posted by mitch074 View Post

                FP64 : true, sorry. It could process 2 FP32 values in a single instruction,which doesn't make it a FP64 unit.
                Registers : SSE added 8 more registers while 3DNow! shared the 8 existing MMX registers, true - and it's a GOOD THING they did, due to how starved for registers the x86-32 arch is... And considering Intel created SSE to prevent 3DNow! from becoming prevalent (as it had been adopted by all its x86-32 competitors), they had to make it better. AMD had already done good with 3DNow! by allowing simultaneous processing of 2 FP instructions in a single cycle, SSE had to be better everywhere.
                Just a note: Citation from the PDF I linked in my previous post: "All 3DNow! operations [on an AMD-K6 CPU] have an execution latency of two clock cycles and are fully pipelined." -- The "fully pipelined" most likely means that the throughput is 1 instruction per clock.

                A major issue with MMX & 3DNow isn't register starvation (which can be handled via register renaming), but the fact that it is relatively costly to mix MMX & 3DNow instructions with x87 instructions (because x87 uses a stack of registers, while MMX and 3DNow don't). ---- The hypothetical universe in which AMD later (such as: in AMD-K7) added an instruction prefix to enable MMX & 3DNow to work with the x87 stack, thus reducing the cost of mixing MMX & 3DNow instructions with x87 instructions, isn't the universe in which we live.

                Comment


                • #38
                  BTW. This just drops use of 3DNow! from kernel to accelerate memory copies and comparison. SSE, SSE2, AVX are available for about 25 years now.

                  You can still run user space applications using 3DNow! (including native and via wine) just fine on CPUs that support it.

                  Comment


                  • #39
                    Originally posted by TemplarGR View Post

                    Do you need 3DNow? Does anything use it, really?
                    You could argue that about a lot of things. I don't, for example, use or need AVX512. Like I said, the hardware supports SSE4a so for me the loss of 3DNow! support will hardly be noticed.

                    Comment


                    • #40
                      With the global chip shortage, and no end in sight it is beyond me why support/features for older hw generations is getting removed from the linux kernel and mesa recently.

                      Comment

                      Working...
                      X