...

• XPU does not currently support redirection of errors away from the console, which means DCCs will not be able to report XPU errors in their UI.
• Warnings on the console when rendering to XPU from Katana.  There are some warnings you will see on the console about a bad DSO being found for the socket display driver.  You can ignore these.
• Picking from "it" does not relay the selection back to RenderMan for Maya
• RenderMan for Maya does not yet support batch renderinng rendering to XPU

Shading

...

• There is no support for custom C++ plugins. Patterns written in OSL are supported.
• PxrSeExpr is not supported.
• PxrDirt & PxrCurvature require the trace() OSL call, which is not yet supported.
  
• Point clouds are not supported.
• PxrBakeTexture and PxrBakePointCloud are not supported.
• XPU samples textures at one MIP level coarser than RIS so that it may store more textures in limited GPU memory.  This results in slightly blurrier renders from XPU than RIS.

• We are currently in the process of updating the texture cache for the GPU to give better performance if it isn't large enough to hold the textures required for your render.

• Textures with a non square pixel aspect ratio are not supported.
• If you update a texture while the renderer is running, XPU may not update the texture. If this happens, restart your render.
• If you stop interactive rendering while textures are still being made, sometimes you will get a crash.

OSL

• In XPU, the first argument to the OSL getbuiltin() shadeop is ignored. You may continue to specify a first argument in order for your shader to remain compatible with RIS, but the distinction between "primvar", "builtin", and "attribute" that exists in RIS does not exist in XPU.
• getattribute() calls asking for geometry primvars (in RIS, getattribute("primvar")) are fully supported.

• getattribute() calls targeting "builtins" (renderer computed quantities that are not directly geometry primvars) are partially supported. Some builtins known to RIS are not currently available in XPU. The most important changes are summarized in the table below. If an alternative is suggested, it means that OSL patterns should be rewritten to use the alternative to be as forward looking as possible.

  Builtin	Supported in XPU	Alternative (if possible)
  P	✅	global P may be preferred
  PRadius	❌
  Po	✅
  Nn	❌	use global N
  Non	✅	supported, but only if displacement took place
  Ngn	❌	use global Ng
  Naon	❌	point Po; getattribute("primvar", "P", Po); normalize(cross(Dx(Po), Dy(Po)));
  Tn	✅
  Vn, VLen	❌
  curvature	❌
  dPdu, dPdv	❌	use globals dPdu and dPdv
  u, v	✅	globals u and v may be preferred
  st	✅
  du, dv	❌	use 0.5 * Dx(u), 0.5 * Dy(v)
  dPdtime	❌
  time	❌
  id, id2	✅

• The only getattribute("attribute", ...) lookups that are supported in XPU are "user" and "identifier" attributes (e.g. getattribute("attribute", "user:foo", foo)).
• getattribute("context") and getattribute("rendererInfo") queries are not supported in XPU.
• trace() is not currently supported. Support for a single level of recursion will be added in a future release.
• Dynamic string construction is not supported.
• It is possible in some cases that strings within OSL patterns are not properly constant folded, resulting in errors at runtime.
• Dynamic path construction in your own patterns is not supported, but please note that we do support the following path tokens <UDIM>, <u>, <v>, <U>, <V> and <primstr:varname> that will result in a "dynamic" path to your textures.  <primstr:varname> can be used to reference the value in a constant primvar or user attribute to build a dynamic path (this feature will be available in 24.1)

...