all the buildscripts should be complete, they should build with no issues on both windows and centos (centos7 disclaimer, the stock flex is outdated, needs to be replaced with a build from source 2.6.4 or you'll have build errors), the blender windows build with dg2 enabled I made @Xavier Hallade (xavier) was able to confirm as working, on linux all the puzzle pieces are in place but due to my centos container running out of ram i could not complete a blender build there.

Okay, you are right, that seems significant indeed.

I can reproduce it now as well. I was calling the undo history menu via a shortcut. It only fails to undo the strokes when using the undo history from the top bar menus.

Can confirm, the Junk Shop scene works. I even triple checked with logging and radeontop to make sure it's really using HIP - it is. No issues with the hardware accelerated Cycles viewport either.

@Andrius Lukosevicius (niobium93) , please make a separate bug report for your issues rather than commenting them on this task.

Interesting. For me, just adding an image texture node to an active material (with no texture actually loaded), and connecting the color output of the texture node to the Principled BSDF color input, crashes Blender immediately if I use Cycles with GPU compute enabled as my viewport renderer.

It happens on blender-3.2.0-beta+v32.84e55e3dc251-linux.x86_64-release on Ubuntu 20.04, rocm 5.1.3 and an 5600XT (RDNA1)

I upgraded to ROCm 5.1.3 and blender 3.3.r115176.gffa262c9f8c and now the HIP kernel fails to compile.

This report was merged into a bug report about Windows, where a driver update fixed the issue. However the Linux driver is quite different, and I have not seen confirmation yet that it's fixed on Linux.

Resolve setting is CIE XYZ since that is what the EXR was encoded in

This seems to be working as designed. I'm not sure what this node setup is intended to do though.

Same is true for Cycles btw.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

What are your input, and output transforms set to in resolve and what is the timeline color space set to? Having any of these set to sRGB/Rec709 will hard limit the Chromaticity displayed in the scope even if the file itself contains more.

Thanks for the report.
Result doesn't look like intended. That shading issue also disappear when view is switched to orthographic mode (or camera type to orthographic)

hi guys, i know this thread is old and a 'known issue' but i've got something even worse to add on to this. i've attached a blend file where freestyle is generating lines, where there is NO LINE to be drawn. Not hidden/occluded edges, not boolean based edges, but lines where there is no boundary, edge, contour, or crease at all. these lines are just popping up out of no-where at all. i'm really confused.

Scripted sycl (and it's deps) for both windows and linux should be available in the deps builder of cycles_oneapi

Will not consider this a blocker for the 3.2 release even if it would be good to solve.

Can confirm, broke between 17eb8a9cebd5 and a5644f9a28ea

Will confirm for now (since I cant make sense of it atm).

1. you can use sycl-nightly/20220501 for both linux and windows, we'll make sure to recommend the same version on both OSes.
2. ocloc and graphics compiler don't have to be redistributed or windows nor on linux, this is absolutely only a build time component used for AoT binaries.
3. on your build system, you can use a version I put in our shared drive to support dg2. the point of it is that anybody else can still use the public package and target older versions, and in the near future the public package will also support dg2. there is an issue with compile time for older versions but still ~1h should be enough at the moment.

current concerns:

"However they are different nodes and I'm not sure if it's really to be expected that the result to be the same." Well the normals that the bump node and displacement node give are identical but for some reason the rendered result isn't.

I thought this was about actual displacement, but if it's bump from the displacement socket that's indeed not ideal.

pi_opencl.dll/libpi_opencl.so aren't needed anymore since 15c146091def58c6f1bd156611cda3efff982687

Here's a simplified scene:

Bump mapping is only an approximation, it would be great if it matched displacement exactly but it doesn't.

I can confirm the difference.
However they are different nodes and I'm not sure if it's really to be expected that the result to be the same.
So we need information from the Render & Cycles team to define if it's a bug or not.