Blender 4.3 Released With AMD HIP-RT Ray-Tracing On Linux, Experimental Vulkan Backend

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67186

    Blender 4.3 Released With AMD HIP-RT Ray-Tracing On Linux, Experimental Vulkan Backend

    Phoronix: Blender 4.3 Released With AMD HIP-RT Ray-Tracing On Linux, Experimental Vulkan Backend

    Blender 4.3 is out today as the newest feature update to this leading open-source 3D modeling software...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • Quackdoc
    Senior Member
    • Oct 2020
    • 5000

    #2
    the vulkan UI stuff is nice, but we all know what people are really waiting for xD, but what im curious is, does blender with vulkan UI support color management, or really what we all care more specifically about, HDR when used on KDE?

    Comment

    • tenchrio
      Senior Member
      • Sep 2022
      • 173

      #3
      Small error in the article it says
      - Geometry Nodes now support working with Grase Pencil data.
      Should be grease pencil, anyway some great stuff in this Blender update.

      HIP-RT hits Linux and in classroom with HIP-RT + GPU OIDN, I managed to get around 16.5 to 17 seconds with the RX7900XTX but non RT remained the same at about 20 seconds, same as my 4.1 and 4.2 HIP benchmarks (didn't test run the RTX 3090 this time but with 4.2 it was at around 17 to 17.6 seconds). AMD's BVH building seems a bit faster but it is still noticeably "slow" (at least compared to Optix, both are blink and you'll miss it but I feel like HIP is less so), I found that this is basically the last checkpoint on the Cycles HIPRT device checklist ("The BVH builder doesn't efficiently handle degenerate triangles." I just can't help but imagine triangles shitposting on reddit, that or being circles).

      Eevee added light linking, performance seems unaffected. When Cycles got the feature in Blender 4.0 Nvidia GPUs got a hefty penalty in performance (AMD's was less, in the case of the RX 7900XTX it even went up a little), might not have been light linking's fault, anyway I managed to get 2.25 with the RX 7900XTX which is about 0.25 seconds faster than what it was in Blender 4.2, I tested with the RTX 3090 last week on the RC build but when I did that both cards had the same performance as they did with 4.2, if I find time in the week I might see if the full release also improved the 3090 performance.

      Missing in both the article and patch notes; Light linking is the first part of (hopefully) many that will come from the Eevee NPR Prototype which is being headed by Miguel/pragma37, the person behind the Malt3D render engine (a great NPR render engine), in collaboration with Dilongoostudios (the team behind Goo Engine, a custom Blender build for NPR). Most of it is still in a separate Blender build that can be downloaded pre-compiled from the Blender website (different from the regular 4.4 alpha).
      It will be interesting to see what else will come from the prototype into the main branch and can make for one hell of a future Blender release (there is already a lot but it is very "we will break things if we have to next update").

      I'm not sure if the the experimental Vulkan acceleration includes workbench (the viewport render engine), the workbench-next issue seems to be closed so Workbench has been rewritten but I can't find any mention in the patch notes, documents or even the issue itself if that means Workbench runs on Vulkan or not (it feels implied but UI can also just mean.... UI like text and buttons, the windows). Regardless enabling the Vulkan backend (+ the mandatory restart) actually decreased my performance when running playback in solid mode from 9FPS to 6FPS in one of my heavier scenes, it should be noted that it is still labeled as experimental and I wonder how for instance the Intel Arc cards are affected as they tend to have terrible OpenGL performance (we're talking half of equivalently priced AMD/Nvidia cards, the wired performance being even worse, might see if I can pick an Arc card up for really cheap on Black Friday to test with). But for now I will keep it off with 4.3.

      Now onto the main event for 4.3: Grease PencilV3!
      Geometry nodes support is amazing as it opens up a lot of cool new possibilities.
      For example I have made a node setup that generates a bunch of instances of a rose drawing onto a plane but it swaps out my red fill color material with 2 other materials (at random with a 1/3 chance for each material) + random size differences to create a flower field. This was not possible before as you couldn't use a Grease Pencil object as an instance (grease pencil materials also do not have node support so you can't change the color value based on ID or location or even at random like with other objects, the "Replace Material" geometry node is a good work around for this).

      I can also see use in this for say a crowd where you randomize the hair and clothing color (and not have the juxtaposition of a 3D crowd).
      The possibilities don't end there, as you can now use the geometry node modifier on GP objects, this was somewhat possible in 4.2 by first converting it into a curve but than you lost the ability to further draw, as well as any fill layers/materials. With this functionality it is now possible to basically use Grease Pencil to draw Geometry (link to a great example of this to make claymation like animation) but also to add effects that either did not exist or had some "unexpected" behavior even now due to the way GP objects are handled.

      If I use the GP array modifier it will always render the first layer on top (this is necessary for layers or else you would always get Z-fighting or inconsistencies when drawing on different layers in draw mode) even if I use a Y offset to displace the geometry/strokes far away. This can be avoided by applying the array modifier with a Y offset and separating each of the array geometry as their own GP object. Now however if I "recreate" the array modifier in 4.3 on my Grease pencil object the outlines will be behind the preceding object when I use even a small Y offset (basically each of the circles are treated as if they were a GP object, there are reasons why you don't want this with the array modifier, for starters I cannot apply the Geonode version to further edit it):

      It's a bit of a simple example but in the case of that geonode array setup there is also the ability to add on more effects based on certain conditions like distance from the origin point or which instance it is, basically allowing you to create more advanced versions of existing effects, sometimes the outcomes were already possible but would require a lot more manual labor to actualize (e.g. I wanted a mirrored character doing the same action/animation but had a different color scheme, before I would have to apply the mirror modifier and replace the material on each frame, now I can make a geonode setup that does that for me), not only does geonode make it faster to accomplish (easier is subjective to how well you understand geonodes), you can also add node setups to your asset library for future re-use.

      The UI/UX improvements are also great, Layer Groups is a feature a lot of people have requested over the years coming from more traditional drawing tools like Toonboom and Krita. There are a couple of QOL the release notes don't mention like how lights is now off by default on a new layer (might actually be unintentional but better for me as I always turned it off, I can't find an issue in the issue tracker so I consider it a feature). New erase tool is great too, no more weird erases because the distance between 2 points was to large like this:

      Overall a great update if you are a fan of Grease Pencil and Geonodes, with a nice AMD performance boost for Cycles on Linux (personally going to stick to Eevee but its nice to know that extra Cycles performance is there if I ever need it). ​
      Last edited by tenchrio; 19 November 2024, 02:59 PM.

      Comment

      • stargeizer
        Phoronix Member
        • Jul 2008
        • 100

        #4
        Originally posted by Quackdoc View Post
        the vulkan UI stuff is nice, but we all know what people are really waiting for xD, but what im curious is, does blender with vulkan UI support color management, or really what we all care more specifically about, HDR when used on KDE?
        Vulkan support in Blender is Experimental, and both said features are software based, so Vulkan will have nothing to do with HDR/color management at all, so Cycles will work with color management as usual, as long that OpenColorIO can be compilled in your favorite distro . Also, Vulkan itself isn't developed with 3D creation software in mind, so expect Vulkan versions to be quite slower than their OpenGL/DirectX counterparts, for a while. (Since some operations require software based solutions for now, until Vulkan solutions can be developed).

        Blender itself doesn't care about KDE/Gnome/Windows/Cocoa or whatever UI toolkit/OS running it. Blender use it's own UI toolkit that allows them to be fully independent, easily portable between different OS platforms, and allows them to have exactly the same UI, no matter if you are running Linux/Windows/MAC//Ipad (if you are a developer and have the keys, due to Apple walled garden rules)/xBSD and whatever it can be ported to.
        Last edited by stargeizer; 19 November 2024, 03:21 PM.

        Comment

        • Quackdoc
          Senior Member
          • Oct 2020
          • 5000

          #5
          Originally posted by stargeizer View Post

          Vulkan support in Blender is Experimental, and both said features are software based, so Vulkan will have nothing to do with HDR/color management at all, so Cycles will work with color management as usual, as long that OpenColorIO can be compilled in your favorite distro . Also, Vulkan itself isn't developed with 3D creation software in mind, so expect Vulkan versions to be quite slower than their OpenGL/DirectX counterparts, for a while. (Since some operations require software based solutions for now, until Vulkan solutions can be developed).

          Blender itself doesn't care about KDE/Gnome/Windows/Cocoa or whatever UI toolkit/OS running it. Blender use it's own UI toolkit that allows them to be fully independent, easily portable between different OS platforms, and allows them to have exactly the same UI, no matter if you are running Linux/Windows/MAC//Ipad (if you are a developer and have the keys, due to Apple walled garden rules)/xBSD and whatever it can be ported to.
          I am talking about display output, not the internals of blender. vulkan is currently the only way to get HDR displaying properly on kde/gnome, though both do have have merged the wip color management profile. I havent found any software that actually properly triggers HDR on them aside from a MPV PR

          Comment

          • stargeizer
            Phoronix Member
            • Jul 2008
            • 100

            #6
            Not a Blender problem. Cycles will render with color management/HDR if configured to do so.

            AFAIK, for the viewports, HDR on Linux requires wayland and driver support (AMD works mostly, Nvidia is broken AFAIK), and on KDE, gamescope is needed to have any effect on games. MPV running through gamescope seems to work here. I think Color management/HDR is still experimental on KDE ATM, but YMMV.
            Last edited by stargeizer; 19 November 2024, 03:44 PM.

            Comment

            • Quackdoc
              Senior Member
              • Oct 2020
              • 5000

              #7
              Originally posted by stargeizer View Post
              Not a Blender problem. Cycles will render with color management/HDR if configured to do so.

              AFAIK, for the viewports, HDR on Linux requires wayland and driver support (AMD works mostly, Nvidia is broken AFAIK), and on KDE, gamescope is needed to have any effect on games. MPV running through gamescope seems to work here. I think Color management/HDR is still experimental on KDE ATM, but YMMV.
              again as I said, Vulkan applications can trigger HDR on KDE, I am not talking about rendering with cycles or anything, I am talking about the user looking at the UI and viewports, if they can see in HDR using VK_EXT_hdr_metadata and VK_EXT_swapchain_colorspace as there is a vulkan layer which makes these work over wp_color_management.

              This is used in things like games, video players like MPV etc. If the UI is rendered via vulkan, it *may* be possible to use these extensions to trigger HDR in a cross platform way. This is what I am asking.

              Comment

              • stargeizer
                Phoronix Member
                • Jul 2008
                • 100

                #8
                Sure, can be color managed via Vulkan, but it cannot be color managed in a cross platform way, since color management requires shader setup, and this varies through vendors, hardware and driver configuration.

                ATM, Blender only supports HDR color managed on MACS, since they provide support and a well defined OS interface for it. Windows is still experimenting with HDR stuff, and Linux is basically a disaster. (xorg cannot support it, every application has to support it individually; and wayland recently defined a protocol for it, but requires Window Manager support, and i doubt it will standard between WM's)

                In Blender, color management as of now, is supported on rendered images, and viewport display on a "best effort". The UI color picker is Gamma corrected, but nothing more, as requires OS support. AFAIK, Blender devs won't do any work towards cross-platform color management until there's enough OS support for it. Of course you can always ask at their forums directly.
                Last edited by stargeizer; 19 November 2024, 05:47 PM.

                Comment

                • xcom
                  Senior Member
                  • Dec 2017
                  • 123

                  #9
                  Please add back OpenCL support to Blender. AMD doesn't support HIP normally. Only a few GPU gets full support.

                  Comment

                  • Panix
                    Senior Member
                    • Sep 2007
                    • 1551

                    #10
                    Originally posted by tenchrio View Post
                    Small error in the article it says
                    - Geometry Nodes now support working with Grase Pencil data.
                    Should be grease pencil, anyway some great stuff in this Blender update.

                    HIP-RT hits Linux and in classroom with HIP-RT + GPU OIDN, I managed to get around 16.5 to 17 seconds with the RX7900XTX but non RT remained the same at about 20 seconds, same as my 4.1 and 4.2 HIP benchmarks (didn't test run the RTX 3090 this time but with 4.2 it was at around 17 to 17.6 seconds). AMD's BVH building seems a bit faster but it is still noticeably "slow" (at least compared to Optix, both are blink and you'll miss it but I feel like HIP is less so), I found that this is basically the last checkpoint on the Cycles HIPRT device checklist ("The BVH builder doesn't efficiently handle degenerate triangles." I just can't help but imagine triangles shitposting on reddit, that or being circles).

                    Eevee added light linking, performance seems unaffected. When Cycles got the feature in Blender 4.0 Nvidia GPUs got a hefty penalty in performance (AMD's was less, in the case of the RX 7900XTX it even went up a little), might not have been light linking's fault, anyway I managed to get 2.25 with the RX 7900XTX which is about 0.25 seconds faster than what it was in Blender 4.2, I tested with the RTX 3090 last week on the RC build but when I did that both cards had the same performance as they did with 4.2, if I find time in the week I might see if the full release also improved the 3090 performance.

                    Missing in both the article and patch notes; Light linking is the first part of (hopefully) many that will come from the Eevee NPR Prototype which is being headed by Miguel/pragma37, the person behind the Malt3D render engine (a great NPR render engine), in collaboration with Dilongoostudios (the team behind Goo Engine, a custom Blender build for NPR). Most of it is still in a separate Blender build that can be downloaded pre-compiled from the Blender website (different from the regular 4.4 alpha).
                    It will be interesting to see what else will come from the prototype into the main branch and can make for one hell of a future Blender release (there is already a lot but it is very "we will break things if we have to next update").

                    I'm not sure if the the experimental Vulkan acceleration includes workbench (the viewport render engine), the workbench-next issue seems to be closed so Workbench has been rewritten but I can't find any mention in the patch notes, documents or even the issue itself if that means Workbench runs on Vulkan or not (it feels implied but UI can also just mean.... UI like text and buttons, the windows). Regardless enabling the Vulkan backend (+ the mandatory restart) actually decreased my performance when running playback in solid mode from 9FPS to 6FPS in one of my heavier scenes, it should be noted that it is still labeled as experimental and I wonder how for instance the Intel Arc cards are affected as they tend to have terrible OpenGL performance (we're talking half of equivalently priced AMD/Nvidia cards, the wired performance being even worse, might see if I can pick an Arc card up for really cheap on Black Friday to test with). But for now I will keep it off with 4.3.

                    Now onto the main event for 4.3: Grease PencilV3!
                    Geometry nodes support is amazing as it opens up a lot of cool new possibilities.
                    For example I have made a node setup that generates a bunch of instances of a rose drawing onto a plane but it swaps out my red fill color material with 2 other materials (at random with a 1/3 chance for each material) + random size differences to create a flower field. This was not possible before as you couldn't use a Grease Pencil object as an instance (grease pencil materials also do not have node support so you can't change the color value based on ID or location or even at random like with other objects, the "Replace Material" geometry node is a good work around for this).

                    I can also see use in this for say a crowd where you randomize the hair and clothing color (and not have the juxtaposition of a 3D crowd).
                    The possibilities don't end there, as you can now use the geometry node modifier on GP objects, this was somewhat possible in 4.2 by first converting it into a curve but than you lost the ability to further draw, as well as any fill layers/materials. With this functionality it is now possible to basically use Grease Pencil to draw Geometry (link to a great example of this to make claymation like animation) but also to add effects that either did not exist or had some "unexpected" behavior even now due to the way GP objects are handled.

                    If I use the GP array modifier it will always render the first layer on top (this is necessary for layers or else you would always get Z-fighting or inconsistencies when drawing on different layers in draw mode) even if I use a Y offset to displace the geometry/strokes far away. This can be avoided by applying the array modifier with a Y offset and separating each of the array geometry as their own GP object. Now however if I "recreate" the array modifier in 4.3 on my Grease pencil object the outlines will be behind the preceding object when I use even a small Y offset (basically each of the circles are treated as if they were a GP object, there are reasons why you don't want this with the array modifier, for starters I cannot apply the Geonode version to further edit it):

                    It's a bit of a simple example but in the case of that geonode array setup there is also the ability to add on more effects based on certain conditions like distance from the origin point or which instance it is, basically allowing you to create more advanced versions of existing effects, sometimes the outcomes were already possible but would require a lot more manual labor to actualize (e.g. I wanted a mirrored character doing the same action/animation but had a different color scheme, before I would have to apply the mirror modifier and replace the material on each frame, now I can make a geonode setup that does that for me), not only does geonode make it faster to accomplish (easier is subjective to how well you understand geonodes), you can also add node setups to your asset library for future re-use.

                    The UI/UX improvements are also great, Layer Groups is a feature a lot of people have requested over the years coming from more traditional drawing tools like Toonboom and Krita. There are a couple of QOL the release notes don't mention like how lights is now off by default on a new layer (might actually be unintentional but better for me as I always turned it off, I can't find an issue in the issue tracker so I consider it a feature). New erase tool is great too, no more weird erases because the distance between 2 points was to large like this:

                    Overall a great update if you are a fan of Grease Pencil and Geonodes, with a nice AMD performance boost for Cycles on Linux (personally going to stick to Eevee but its nice to know that extra Cycles performance is there if I ever need it). ​
                    This is interesting but can you test on some demo files: Classroom, Barbershop, Lone Monk etc.?

                    The 7900 xtx and 3090 are the comparisons I'm interested in, ironically - so, it's intriguing those are your cards? The 7900 xtx used, in my market, is about $100 ish more - assuming someone would reduce their price on the amd gpu. The 3090 prices are all over the place but that's probably because some ppl are hoping for rich ppl to just pay what they are asking - and they think the 24gb gives them the right to hype their cards - plus, it's nvidia. But, they are around $100-$200 used. The 7900 xtx new prices are still high.

                    The 7900 xtx would be the only amd gpu I'd even consider - but, used. It's disconcerting - at least, to me, though - that the hip-rt - ray tracing - is still not reliable or ironed out - it's still considered experimental. I feel like I'd still be forced to go with nvidia even though it's the older gen/architecture. The 4070 Ti Super might be coming down in price depending....the only 40 series I'd look at - used again, though. I wouldn't go anything lower than 3090 or 4070 Ti S.

                    Anyway, didn't mean to ramble on - thanks for your write up.

                    Comment

                    Working...
                    X