Differences between Karma CPU & XPU renders

   4576   12   3
User Avatar
Member
38 posts
Joined: 9月 2017
Offline
I know the 'XPU is darker' issue is already logged, but I'm trying to figure out why Karma CPU vs XPU renders look so different in other ways.

An easy example - load Crag into solaris, light with a dome light / distant light and look at the results. The XPU render is really glossy. Looks like either / both roughness and normals are behaving very differently.

Or is this just an issue with
my config?



Edited by mrboni - 2021年11月29日 17:27:18

Attachments:
CragKarmaSimple.png (24.0 KB)
CragXPU.png (347.3 KB)
CragCPU.png (353.2 KB)

User Avatar
Member
38 posts
Joined: 9月 2017
Offline
Another example. Here we have a simple road material (mtlx) with Base Colour, Roughness, and Tangent Normal Map. Not only do you see a huge differenct in the 'texture' quality, but there is a strange divergence / blurring the further from camera we get. See the white line road markings in particular.


Edited by mrboni - 2021年11月29日 17:34:43

Attachments:
RoadXPU.png (565.9 KB)
RoadCPU.png (742.1 KB)

User Avatar
Member
10 posts
Joined: 6月 2015
Offline
mrboni
Another example. Here we have a simple road material (mtlx) with Base Colour, Roughness, and Tangent Normal Map. Not only do you see a huge differenct in the 'texture' quality, but there is a strange divergence / blurring the further from camera we get. See the white line road markings in particular.

Hey this caught me out the other day in regards to texture res!

If you go through the XPU page in the docs:
https://www.sidefx.com/docs/houdini/solaris/karma_xpu.html [www.sidefx.com]

You will find this gem:
Texture resolution is limited to 2048×2048 (configurable via the environment variable KARMA_XPU_MAX_TEXTURE_RES).

So to fix the problem and assuming you have enough VRAM you can set KARMA_XPU_MAX_TEXTURE_RES="8192" for example
User Avatar
Member
10 posts
Joined: 6月 2015
Offline
mrboni
I know the 'XPU is darker' issue is already logged, but I'm trying to figure out why Karma CPU vs XPU renders look so different in other ways.

An easy example - load Crag into solaris, light with a dome light / distant light and look at the results. The XPU render is really glossy. Looks like either / both roughness and normals are behaving very differently.

Or is this just an issue with
my config?

Looks like the Crag test geometry is using a principled shader

XPU only supports materialX and USD Preview Surface
Edited by johnp - 2021年11月30日 11:26:49

Attachments:
Screenshot 2021-11-30 132501.png (43.9 KB)

User Avatar
Member
8045 posts
Joined: 9月 2011
Online
johnp
mrboni
I know the 'XPU is darker' issue is already logged, but I'm trying to figure out why Karma CPU vs XPU renders look so different in other ways.

An easy example - load Crag into solaris, light with a dome light / distant light and look at the results. The XPU render is really glossy. Looks like either / both roughness and normals are behaving very differently.

Or is this just an issue with
my config?

Looks like the Crag test geometry is using a principled shader

XPU only supports materialX and USD Preview Surface

Crag's textures are also jpg's, XPU is probably erroneously gamma correcting the roughness map since the gamma correction parameter is not translated from the principled to usd preview surface.
User Avatar
Member
38 posts
Joined: 9月 2017
Offline
Hey this caught me out the other day in regards to texture res!

If you go through the XPU page in the docs:
https://www.sidefx.com/docs/houdini/solaris/karma_xpu.html [www.sidefx.com]

You will find this gem:
Texture resolution is limited to 2048×2048 (configurable via the environment variable KARMA_XPU_MAX_TEXTURE_RES).

So to fix the problem and assuming you have enough VRAM you can set KARMA_XPU_MAX_TEXTURE_RES="8192" for example


Useful doc, thanks! I tried increasing the texture res (although the argument didn't show up when asking 'hconfig -a', should it have done?) and it didn't affect the blurring issue. Anyway, I'd imagine the issue is more to do with texture filtering than resolution, as there are clearly enough pixels in the texture when it's close to the camera
User Avatar
Member
38 posts
Joined: 9月 2017
Offline
Even without textures there is a large discrepancy when looking into the distance along the surface. The following is a mtlxstandard_surface with no textures (or any nodes) connected

Edited by mrboni - 2021年11月30日 13:37:24

Attachments:
CPUvsXPU_NoTextures.png (1.3 MB)

User Avatar
Member
38 posts
Joined: 9月 2017
Offline
So there are at least two issues at the moment.

The first one is represented in the previous image and is to do with the dome light - in CPU rendering the lighting result is significantly 'brighter'. I've tried a variety of images as source, all latlong, in exr / hdr / jpg formats. Is the same for all.

The second issue is visible in the textured road images above and appears to be significant texture filtering artefacts, not connected to the resolution of the source textures (btw I checked and the images are 2048px anyway ) This issue is still present when using lights other than dome. (Also just tried using 'Simplified Shading' and its still there)
Edited by mrboni - 2021年11月30日 13:58:40
User Avatar
Member
10 posts
Joined: 6月 2015
Offline
mrboni
The second issue is visible in the textured road images above and appears to be significant texture filtering artefacts, not connected to the resolution of the source textures (btw I checked and the images are 2048px anyway ) This issue is still present when using lights other than dome. (Also just tried using 'Simplified Shading' and its still there)

So I was just testing this myself and using a tiled texture I seeing the same problem with XPU and not with CPU. However, if you use a USD Preview Surface material instead of a MaterialX Standard Surface the issue looks a little more improved (in my test) but definitely not as good as the CPU result.
Edited by johnp - 2021年11月30日 14:19:36
User Avatar
Member
729 posts
Joined: 7月 2005
Offline
mrboni
Even without textures there is a large discrepancy when looking into the distance along the surface. The following is a mtlxstandard_surface with no textures (or any nodes) connected

This is most likely the same XPU edge-darkening issue we've been seeing. Today's .454 daily build appears to have a fix for it:
Energy-preserving rough GGX implemented, fixing a bug where rough surfaces could look overly dark at grazing angles

The distance texture blurring looks exactly like a lack of anisotropic filtering you would see in video games.
Edited by Siavash Tehrani - 2021年11月30日 17:29:05
User Avatar
Member
38 posts
Joined: 9月 2017
Offline
DaJuice
mrboni
Even without textures there is a large discrepancy when looking into the distance along the surface. The following is a mtlxstandard_surface with no textures (or any nodes) connected

This is most likely the same XPU edge-darkening issue we've been seeing. Today's .454 daily build appears to have a fix for it:
Energy-preserving rough GGX implemented, fixing a bug where rough surfaces could look overly dark at grazing angles

The distance texture blurring looks exactly like a lack of anisotropic filtering you would see in video games.

Ah great, will try the daily build, thanks.

Yes you're right the texture blurring does look like no anisotropic filtering. Any idea how I'd proceed with this? Should I email SideFX support?
User Avatar
スタッフ
531 posts
Joined: 5月 2019
Offline
Hi guys

Just to let you know, XPU will have anisotropic filtering in H19.5
(ie, fixing the issue)

Cheers
Brian
Edited by brians - 2022年1月10日 16:47:24
User Avatar
Member
38 posts
Joined: 9月 2017
Offline
Great
  • Quick Links