-
Notifications
You must be signed in to change notification settings - Fork 808
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal/master #8083
Merged
Merged
Internal/master #8083
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
POI: https://jira.unity3d.com/browse/POI-585 Epic: https://jira.unity3d.com/browse/GFXFEAT-206 Description is also available in Jira.
This PR fixes a compilation error that started occuring as a result of a variable name change in the APV's definition. Additionally it adds a variant of the 39_SmokeLighting test scene that uses APV.
Fix bugs with URP RenderGraph pass names. Specifically the DrawObjectPass does not pass the more descriptive pass name to differentiate between Opaques and Transparent. While investigating this, I noticed that the profiler name and the pass name differ in a range of passes. This PR also consolidates the passnames between the profiler, frame debugger and render graph viewer. Also, the passes are named very inconsistently. In this PR, I've updated the names to be consistent: - No use of "Pass" as the end of the pass name, it does not add anything. - Are an action, so "Do Something", not "SSAO" - Consistent over RG viewer, framedebugger and profiler - Descriptive while short - Can be camelcase or with spaces, the viewers will "nicify" them (to limit the scope and changes of this PR) Consistent action name - "Draw" draws scene objects/meshes, or generally when calling cmd.DrawRendererList in the pass - "Blit" performs a blit to a resource (so Blit Color LUT instead of Color LUT, Blit SSAO instead of SSAO, ..) - "Set" sets keywords or global properties Before ![image](https://media.github.cds.internal.unity3d.com/user/1031/files/c77694bf-9adf-408d-ade3-40915169925e) After ![image](https://media.github.cds.internal.unity3d.com/user/1031/files/f9c92437-5e98-426b-8745-45daf1b1b7c5) Consistent over RG viewer, framedebugger and profiler: - The ProfileSampler names can be camelcase or with spaces. - The pass names are identical to the profilerSampler names - The Profiler "nicifies" the names already, so in this PR we adopt that same practice in the RG viewer. The viewer/tool is responsible for this nicification. The user can now easily identify a certain pass in both tools. ![image](https://media.github.cds.internal.unity3d.com/user/1031/files/5bd08c41-3191-4db3-8450-f330dc863766) Also fixed a number of incorrect ProfilerSample scopes. These should not be used in the static ExecutePass function that is shared between RG and non-RG, since in RG the profiler scope is already set automatically. That also removes the need for static ProfileSamplers.
Fix for Validity format not working if `R8 UNorm` is not supported. Instead a more widely supported format `RGBA8 UNorm` is used. Jira: UUM-73634
Shader Graph's handling of Gradients wasn't updated with the addition of the perceptual color mode on the Gradient unity type.
Fix user feedback ticket and specify where to find Universal Renderers.
Marketing are in the process of moving to a new [CMS for the Unity Blog](https://docs.google.com/document/d/1mk2eDwHjjg1aCljHegEzNwSUACgY5uqJIuw6taSuDL8/edit#heading=h.v9aikhgwe9xr). As part of this process, they have made the decision to sunset some [historic blog content](https://docs.google.com/spreadsheets/d/16BSw2hcgw5HYSox9lh9uDZ96en0yU6FJzMEdk4Ru-14/edit#gid=731758769). I have searched through the core docs and created [this sheet ](https://docs.google.com/spreadsheets/d/1-yyMP-h2tjNIR4Wf1jqURljFbhVchHKVqT1vAygz0Cg/edit#gid=0) to track where we link out to unity blog pages, and then which links will need to be removed as the pages are being retired. This PR removes mentions of these pages to avoid us dealing with reports of broken links in the future. I will backport these changes and check for any extras in 2022.3 & 2021.3.
Fix async SSR that have an uneeded barrier on xbox for reasons https://unity.slack.com/archives/C6Y79CZM0/p1716461545320749?thread_ts=1715329897.499809&cid=C6Y79CZM0 Fix unecessary texture allocation when ssr approximate mode is on Fix unecessary rendergraph barrier on coarse stencil (code is disabled with a comment on shader) Fix triple upload of constant buffer with same data Also fix various debug modes that got broken by fog Trunk: ![image](https://media.github.cds.internal.unity3d.com/user/2154/files/c5cdea7d-7af4-47d4-92a1-a63afbc39a50) Fix: ![image](https://media.github.cds.internal.unity3d.com/user/2154/files/fad6f1e6-513e-43dd-a289-1fc16a770986)
Delegate have a GetHashCode method which is differently behaves in different .Net versions. Instead we force to rely our hashcode calculations to the Method and Target of Delegate. This keep it stable between different .net versions. Plus I did a small refactor to simplify class handling.
Added a warning box to show a warning before you run in playmode. The bug begin fixed is: UUM-62984 ![image](https://media.github.cds.internal.unity3d.com/user/2017/files/f186e66b-d6ef-4242-9396-658c4a8a1ba7)
This PR fixes the build on Switch. The failure was caused by a modification of the build preprocessor priorities which caused our workaround to UUM-73363 to be executed too late.
**BUGS FIXED** - [UUM-70196](https://jira.unity3d.com/browse/UUM-70196) Camera-facing leaf effect [SRP+Builtin] - [UUM-73540](https://jira.unity3d.com/browse/UUM-73540) LOD Transition effect applying only to wind-enabled assets [SRP] - [UUM-73544](https://jira.unity3d.com/browse/UUM-73544) Wind9 animation scaling & animation speed issues [SRP+Builtin] - HDRP [camera movement causing tree wind animation to speed up](https://github.cds.internal.unity3d.com/unity/unity/pull/48921/files#diff-05bc7e42c02de6282ec0961b0690eaff1f9b60bf630e33d0187a6971210f44f4R540) due to camera position applying to noise offset in both edit & play mode - ST9 material wind toggle Branch1/Branch2 mismatch [Builtin] - HDRP Tests SpeedTree9 asset error msg **CHANGES** - [Shadergraph / SpeedTree] - Moved `LOD Transition` & `Leaf-facing` effect nodes out of the `SpeedTreeWind` node - Renamed subgraphs for consistency among ST8 & ST9 - Tidied up, added comments to shadergraphs ![image](https://media.github.cds.internal.unity3d.com/user/5527/files/e8dba5bd-be26-46a5-abda-53506e4a2710) - Fixed Wind9 shader & CPU bugs - fixed direction vectors in shader (x, -z, y) - unpacked branch - wind vector - up - fixed scaling of world-space and noise-space vectors in shader - added new cbuffer `fImportScaling` to adjust vectors in shader that are scaled during importing - removed unnecessary scaling of `afSpeed` from CPU code - fixed ST9 importer's incorrect import scaling & anchor offset - removed `SetPersistent()` call on SpeedTreeWindAsset - Shader & CPP code cleanup, remove unused & unnecessary code - [Tests] updated HDRP & URP unit tests - added new camera-facing asset & updated scenes to include testing bug fixed in main JIRA - updated the screenshots of other tests w/ SpeedTree due to fixed LOD Transition effect
…ected at AfterSkybox/BeforeTransparents This PR fixes the URP RG injection of AfterRenderingSkybox/BeforeRenderingTransparents custom passes. In order to follow URP Compatibility mode logic, custom passes injected at a given event A should be rendered before URP built-in passes that are also happening at the same event A (more info below). Initial bug was about the wrong order of URP CopyColor (AfterRenderingSkybox) / Custom pass (AfterRenderingSkybox) that should be : Custom Pass / URP Color. This is fixed. In the process, I noticed that we had the same issue for URP ProbeVolumeDebug (BeforeRenderingTransparents) / Custom pass (BeforeRenderingTransparents). It should be Custom Pass / URP ProbeVolumeDebug. This is also fixed. URP Comp: ![good-no-RG](https://media.github.cds.internal.unity3d.com/user/5521/files/4321b8e8-2aef-43a4-a162-0ff234a49491) URP RG broken: ![wrong-RG](https://media.github.cds.internal.unity3d.com/user/5521/files/c40582a2-f155-40fe-abdf-9b59e0df518e) URP RG fixed: ![fixed-RG](https://media.github.cds.internal.unity3d.com/user/5521/files/9b535cfa-a697-42c7-ad04-4606c961ae75)
Add history textures documentation to the render graph documentation. Jira ticket: https://jira.unity3d.com/browse/DOCG-3876
In the Universal Renderer Data, you can select Layer Masks to filter out from the renderer. For example, you can click URP Renderer > Opaque Layer Mask > Deselect "Water" layer. If you add a GameObject to that "Water" layer so that the Renderer filters it during rendering, the Motion Vectors for that object are still included in the URP Motion Vector pass. To avoid that we add Opaque Layer Mask to the MotionVectorRenderPass.
…kage is in the project When there's only CustomEditors with SupportedOnRenderPipeline but none of them is active on current RP we expect it to be not supported. So to make something enabled on the Built-In only and there's no CustomEditor for Built-In we create CustomEditor without SupportedOn and manually handle with `GraphicsSettings.isScriptableRenderPipelineEnabled`.
Fix a code sample error introduced in https://github.cds.internal.unity3d.com/unity/unity/pull/50586 Jira ticket: https://jira.unity3d.com/browse/DOCG-5762
Fix the bug where in non-development build, the profiling sampler is null so trying to access profilingsampler.name throws an exception
Recently, there's been some changes leading to a bug when the sample showcase tab content ended up superposed on the inspector content. The simple fix is to remove the sampleshowcase window which has very little purpose and will lead to less potential issue in the future. Now we just select the sample showcase object to make sure the text is displayed at first on scene opened. This is what happened when switching to inspector tab when sample showcase was opened when swthcing scenes. ![image](https://media.github.cds.internal.unity3d.com/user/1764/files/aeae8bd3-9075-44ba-b308-f5c0fd479285) Also fix atmospheric scattering not sampling shadow map with correct location. Fix sampling of sun light absorption in volumetric clouds which was done two times and resulted in incorrect lighting in some cases due to lerp
Add Copy Depth Pass to fix UUM-70107
…en the feature is not used Fix unneeded memory allocation when the volumetric lighting reprojection is not enabled.
It's very easy to create a crash when creating `Primitives` (e.g a Sphere) in a Custom Pass (HDRP). For example, by doing : `GameObject.CreatePrimitive(PrimitiveType.Sphere);` More context in the description of the PR: https://jira.unity3d.com/browse/UUM-2709 As explained from the JIRA ticket, indeed, this should be an illegal case. It seems to be already the case for many scenarios, since this API is used at many places: `ApiRestrictions::RENDERERSCENE_ADDREMOVE` After adding this restriction code, I can confirm the crash is gone. The behavior (creation of Primitives in a Custom Pass) still works well. Though, when starting the HDRP sample project, an error is logged two times in the Console, because of this code in HDRP: ``` // Because SRP rendering happens too late, we need to force the draw calls to update RegisterLocalVolumetricFogEarlyUpdate.PrepareFogDrawCalls(); ``` Since this DrawCall is triggered in the constructor of the `HDRenderPipeline` class, the newly added `APIRestriction` is triggered. I'm already chatting with @antoineL to determine if we could move this code after the constructor. @torbjorn If think you are the initial reporter / investigator of this crash ? Let me know if you see any drawback regarding this solution. You definitely know this part of the code better than me.
This PR fixes https://jira.unity3d.com/browse/UUM-70748 as well as reporting the errors inside the function do to user into to the user call location.
JIRA ticket: https://jira.unity3d.com/browse/UUM-55852 It mentions `Shader Graph + Scene View` only, but it's definitely not related. The issue is because of the Tonemapping system and the `Neutral` mode, when used with 64-bit textures. It's easy to reproduce the issue in the `Game View` too by selecting 64-bit precision in the `Render Pipeline Asset` (`Quality` section). This PR fixes the artifacts when using `Neutral Tonemapping` with 64-bit textures. Clamping negative values to zero fixes the issue since the `Neutral Tonemapping` curve is not designed to handle negative input values (in comparison to the ACES mode, which handles negative values). It also updates the `091_ToneMappingNeutralLDR` test we have. The previous `Expected` image seems wrong, some color are off. With the fix, they are fully rendered, respecting the initial image "synthetic chart" `exr` (c.f screenshot below). ![image](https://media.github.cds.internal.unity3d.com/user/1911/files/bd9fd253-6b77-4766-98c7-07d5ad5ce783) ![image](https://media.github.cds.internal.unity3d.com/user/1911/files/4258a254-e588-484e-a891-e536ebae0118)
Fix baking when bricks are bigger than entry size
Fix an issue where the world space UI would ghost when the camera moves and the UI is in front of objects with motion
What's new in URP 17 (Unity 6)
First draft of the URP 17 upgrade guide.
JIRA: https://jira.unity3d.com/browse/GFXFOUND-421 Merged the depth of field passes to improve render graph performances (like it was done for the SSAO and Bloom passes)
…in use. Fixed yflip issue when depth intermediate texture is required and non-RG is in use Jira: https://jira.unity3d.com/browse/UUM-70472
…rong string UI is adding included/excluded platforms in the UI by NamedBuildTarget. So for instance, "Switch" is obtained from BuildTarget.Switch.ToString(), but if we do NamedBuildTarget(BuildTarget.Switch) it returns you "Nintendo Switch". This was including/excluding RP assets that were not supposed to match the call to the API of BuiltTarget extension https://jira.unity3d.com/browse/UUM-73363
In [this forum post](https://forum.unity.com/threads/disabling-post-processing-effects-in-the-default-volume-profile.1545362/#post-9891525), a user complained that even if Bloom frame settings was set to false, if there was a screen space lens flare override, we "reactivated" the bloom pass without the user's knowledge which can be confusing and deceiving. Now, SSLF frame settings is now a child of the Bloom frame settings. In addition, there's a warning box directly in the override if any of the frame setting (bloom or SSLF) is set to false preventing the bloom pass to be executed without the users knowledge. ![image](https://media.github.cds.internal.unity3d.com/user/1764/files/6e522a47-79f2-49fe-aeaf-d9d4166467ef) In addition, since SSLF writes directly on the bloom buffer and uses the uberpass bloom to be rendered, if bloom intensity is set to zero, it won't render. So in the SSLF override there's now a message warning you that one or more bloom override prevents SSLF to be rendered. ![image](https://media.github.cds.internal.unity3d.com/user/1764/files/16320f54-ad23-4338-a5c7-9e4f0788db65) Lastly, I took the opportunity with this PR to add the frame settings check wherever it made sense in the current override to avoid further users confusions (cf [commit](https://github.cds.internal.unity3d.com/unity/unity/pull/51061/commits/32f1369d6710394879f23d2f24f84b73a68710cb)).
…e (how to inject render passes). DOCG-5705: Corrected a sentence, added a reference to an overview page (how to inject render passes).
Only URP package doc and sample scene script changes. No engine code changes. - Fixes GC.Alloc that happens every frame in URP package doc and package sample scene script [slack](https://unity.slack.com/archives/C010YL29H8F/p1718105805466559) - Blur sample do not use frame buffer fetch. Just use normal blit [UUM-74051](https://jira.unity3d.com/browse/UUM-74051)
This change adds logic to render graph that clears global texture bindings after execution. This behavior prevents code that follows the render graph execution from depending on resources that are only valid within the graph's scope. The behavior is controlled via a C# define for now because it uncovers several other issues that need to be resolved before this is enabled unconditionally. This PR is an temporary change that's a prerequisite for fixing UUM-74470. It has no functional impact when the C# define is not set.
Fixed HDRP area light culling
This PR fixes https://jira.unity3d.com/browse/UUM-60387 The bug requires a few things to be true in order to reproduce: have URP with RenderGraph enabled, use Vulkan, have MSAA disabled. In this case, when the two repro projects were set up in a way that causes CopyDepthPass to be executed (specifically with CopyToDepth=false), the depth was not getting copied correctly, causing subsequent depth tests to fail, resulting in missing objects. When Vulkan validation layers were enabled, the following error was output: ``` VULKAN: VALIDATION ERROR: Validation Error: [ VUID-vkCmdDraw-None-06886 ] Object 0: handle = 0xab7c3f0000001d62, type = VK_OBJECT_TYPE_PIPELINE; Object 1: handle = 0xceb68d0000001d60, name = ExecuteRenderGraph (C0:C/S, C1:L/S, DS:L/S), type = VK_OBJECT_TYPE_RENDER_PASS; Object 2: handle = 0x14239304030, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0xf157442b | vkCmdDraw: depthWriteEnable is VK_TRUE, while the layout (VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL) of the depth aspect of the depth/stencil attachment in the render pass is read only. The Vulkan spec states: If the current render pass instance uses a depth/stencil attachment with a read-only layout for the depth aspect, depth writes must be disabled (https://vulkan.lunarg.com/doc/view/1.3.243.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDraw-None-06886) CommandBuffer labels: CopyDepth | CopyDepthPass Objects: #0: { type = VK_OBJECT_TYPE_PIPELINE, handle = 0xab7c3f0000001d62 } #1: { name = ExecuteRenderGraph (C0:C/S, C1:L/S, DS:L/S), type = VK_OBJECT_TYPE_RENDER_PASS, handle = 0xceb68d0000001d60 } #2: { type = VK_OBJECT_TYPE_COMMAND_BUFFER, handle = 0x14239304030 } ``` The reason for this error is that the render state is being setup in an inconsistent way: - `depthWriteEnable=true` because `CopyDepth.shader` contains `ZWrite On`, but - because we don't bind a depth attachment, the RenderGraph compiler sets `SubPassFlags.ReadOnlyDepth` flag which causes Vulkan backend to use the `VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL` layout. To fix this conflicting setup we set ZWrite to On/Off depending on whether depth output is active or not. This fixes the validation error, and the incorrect rendering in the original repro project, and makes the new graphics test pass. Shoutout to @eduardas-vitkus for creating the new graphics test that catches this specific case, and providing a ton of relevant information on the issue, including the Vulkan validation error!
Introducing two analytics for our Graphics tools: https://jira.unity3d.com/browse/GFXFOUND-452 ``` // schema = com.unity3d.data.schemas.editor.analytics.uGraphicsToolLifetimeAnalytic_v2 // taxonomy = editor.analytics.uGraphicsToolLifetimeAnalytic.v2 ``` and ``` // schema = com.unity3d.data.schemas.editor.analytics.uGraphicsToolUsageAnalytic_v1 // taxonomy = editor.analytics.uGraphicsToolUsageAnalytic.v1 ``` #### Frame Debugger - Lifetime - Enable/Disabled actions #### Rendering Debugger - Lifetime - Widget value changed #### Render Graph Viewer - Lifetime #### URP Converter - Lifetime - Convert action #### HDRP Wizard - Lifetime - Fix/Fix all actions - Convert actions
… submesh mask When implementing instancing support for exposed meshes and textures, we missed one specific case. If we use a multimesh output with a exposed submesh mask that comes from a expression tree that can be optimized, the expression will not be registered properly in runtime mode. if the VFX is compiled in edition mode, the issue will not be visible.
Issue introduced at https://github.cds.internal.unity3d.com/unity/unity/pull/48953 (landed in 6000.0.6f1) To illustrate the problem, here a case which doesn't cause any problem: <img width="1088" alt="image" src="https://media.github.cds.internal.unity3d.com/user/42/files/364fc89f-9e77-4795-b82e-bc25f5718a72"> Failing case: <img width="1085" alt="image" src="https://media.github.cds.internal.unity3d.com/user/42/files/7cfdad6d-ff4b-42b3-aafe-a4fb6c62854d"> Initially, I changed the workflow to collect IHLSLCodeHolder & GraphicsBufferUsage per context but the resolution was incomplete. If two end expressions were sharing the same ancestor, only the first evaluation is able to collected needed data. It's fine when we are catching this globally but this is wrong when the information must be computed per context. After several back and forth, I finally decided to extract the expression collection from compilation and introduce a preprocess. In the end, even if it forces to browse the expression graph twice, it separates concern and prevent side issues. Additionally, it removes the former `collectedData` in all compile functions. 🎁 I added `CollectPerContextData` flag to reserve this graph browsing to a single case.
…orms The compilation of the HDRP path tracing shader timeouts on some consoles. The issue can be reproduced just by switching to the PS5 platform. https://jira.unity3d.com/browse/UUM-72861 Due to hardware/API limitations, the path tracer is only fully functional on d3d platforms right now, so with my PR we only target these platforms.
Several improvements to water samples: - Reorg of gameobjects into prefabs for clarity - Added link to Global Settings from the helper window - Small rework of meshes and textures to reduce sample size Improved test coverage: - Test water mask - Test water decals - Test cpu readback Improved system usability and workflows Various fixes, mostly minor bugs see release notes
https://jira.unity3d.com/browse/PLATGRAPH-3470 On Apple Arm64 (M1+) GPUs, depth priming causes significant rendering artifacts for web builds. WebGL had this same issue and disabled Depth Priming support. We should disable Depth Priming support for WebGPU as well. Depth Priming can actually hurt performance on tile based GPUs like mobile, and we don't know what type of GPU you're running on with the web player. It seems reasonable to just disable support all-together for the web.
Some test results were mixed up in the last trunk batch and https://github.cds.internal.unity3d.com/unity/unity/pull/51256 landed even though it was introducing a test failure: https://unity-ci.cds.internal.unity3d.com/job/38760374 Disabling that test for now to allow future trunk batches to run cleanly and following up with the PR author on getting a fix for this in place.
Fixed missing option to offset probe at runtime, can be used for camera relative rendering on large worlds, or when loading scene at a different location than where it was baked Fixed baking when using terrain trees with LOD groups Fixed warnings in various shaders Fixed dispatches too large for sky occlusion that would result in errors when baking Slightly changed the thread group size and batch size to reduce time spend in baking shaders to avoid windows TDR errors Fixed to debug modes when using baking offset Fix error when we try to delete temp directory but it was marked as readonly by the OS Increase test coverage
… running The purpose of this PR is to avoid a memory leak and null pointer references when the Lighting window closes while APV is baking
When using multiple Volumetric Fog Outputs in a single system, the buffers `outputBuffer` and `maxSliceCount` were shared between the outputs, which was incorrect. It was leading to GPU hangs on some platforms, and to an excessive amount of slices being drawn on all platforms. This PR makes sure that each output is working on its own set of buffers. Renderdoc screenshots of the draw calls: - Before : the quad count is the same of both draw calls and is the sum of the two required quad count for each output ->Wrong ![image](https://media.github.cds.internal.unity3d.com/user/2768/files/58ce7d7c-b618-4428-8c8e-31d5e4ac2f78) - After : the quad count is different for each draw call and matches the number of required slices for each output -> Correct ![image](https://media.github.cds.internal.unity3d.com/user/2768/files/532e4d8d-3a4f-43ac-b4cb-2fcab81ca758)
Fixed missing option to offset probe at runtime, can be used for camera relative rendering on large worlds, or when loading scene at a different location than where it was baked Fixed baking when using terrain trees with LOD groups Fixed warnings in various shaders Fixed dispatches too large for sky occlusion that would result in errors when baking Slightly changed the thread group size and batch size to reduce time spend in baking shaders to avoid windows TDR errors Fixed to debug modes when using baking offset Fix error when we try to delete temp directory but it was marked as readonly by the OS Increase test coverage
This is a continuation of https://github.cds.internal.unity3d.com/unity/unity/pull/50405 The goal is to have identical URP render pass names in all our profiling tools (RG viewer, Frame Debugger and Profiler). The names are now also identical between RG and non-RG/Compatibility passes. This PR fixes a number of potential bugs with regards to setting ScriptableRenderPass.profilerSampler to null, it fixes incorrect profiler scopes (inside the static method shared between RG and non-RG), improves more pass names using the naming convention from the previous PR and could have a very minor performance benefit in release build. In this PR, we separately store the passName and the profileSampler because these samplers can be null in the release build. Therefore, we can't just use sampler.name. By using the ScriptableRenderPass properties (passName, profileSampler) these names are kept in sync automatically. The default name for a (user created) sub-class of a ScriptableRenderPass is now more descriptive, using the sub-class name instead of the base class. The default RenderFeature that users create from the menu is updated to using this. The profile samplers being null in a release build was introduced by this PR as an optimization https://github.cds.internal.unity3d.com/unity/unity/pull/41824 However, in URP, many samplers are created differently, leading to limited performance gain, and inconsistency with some samplers being null and some not in the release build. This PR improves this so more samplers are null in a release build. Potentially gaining around 0.1ms main thread CPU in release on low end CPUs. Before and after this PR (no change), URP, ProfileSamplers references are kept in a few different places. Depending on that, the samplers can be nullified in the release build. - ScriptableRenderPass.profileSampler: used by RG and non-RG, in this PR, when using RG, they are nullified - ProfileSampler.Get(URPProfileId): same pattern as with HDRP, these are nullified by the change from Julien - RenderGraph.m_DefaultProfilingSamplers: created automatically when adding a pass without a sampler, these are nullified - Other places of the URP code (outside of a pass): these are NOT nullified. Likely, part of the optimization for HDRP came from the dictionary .TryGetValue with large pass dictionaries. The samplers kept outside of dictionary don't have this cost. So it likely will not improve performance to clean up these. Since some samplers can be null in the release build, it's bad practice (errors!) to use sampler.name. However, the earlier PR to nullify this might have introduced issues already. To avoid issues with user project that do this (very low chance), in this PR, ScriptableRenderPass.profileSampler is only nullified in RenderGraph mode (not Compatibility). This makes it a bit more complicated to ensure that the pass name and the sampler name (shown in profiler) don't get out of sync. However, it's confusing for users to see different names in different tools and complicates matching them during analysis. Hence the changes in this PR. The RenderGraph add pass methods (eg AddRasterPass, ...) have overloads for both passing a passName and a sampler, and one with only a passName. The use of passing only the passName seems recommended for users since they can't go out of sync, RG creates a new profiler with that name, and will nullify it in a release build, and users don't have access to the profilerSampler. In non release builds, there might be a small perf overhead of this practice since the dictionary can become large.
- Fixes https://jira.unity3d.com/browse/UUM-73877 which could lead to increase import time due to incorrect priorities between dependencies - Add missing meta for image ref (unrelated to the fix) - Hide deprecated Forward Decal Output from Node Search
Jira: [UUM-72985](https://jira.unity3d.com/browse/UUM-72985) 1. Create project using High Definition 3D Template 2. Create VFX Asset and open it 3. In New VFX window press space or right-click to open VFX Node Search Window 4. In the Search field type “Curl” 5. From the panel double click on “Value Curl Noise 2D” 6. Observe the Console window Actual results: Error “ArgumentException: Object of type 'UnityEditor.VFX.Operator.CurlNoise+DimensionCount' cannot be converted to type 'UnityEditor.VFX.Operator.Noise+DimensionCount’.” Expected results: No errors are thrown in the Console, Node is added to the VFX Workspace Reproducible with versions: 17.0.3 (6000.0.1f1, 6000.0.4f1) Not reproducible with versions: 17.0.3 (6000.0.0f1) Tested on (OS): MacBook Pro, 2021. Sonoma 14.4.1 (M1)
We are storing the wrong value for SpawnIndex attribute during Init compute, when processing several instances at the same time. We are currently using the batch thread index, instead of per instance thread index. The fix is very simple, just replacing one with the other when storing the value.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please read the Contributing guide before making a PR.
Checklist for PR maker
need-backport-*
label. After you backport the PR, the label changes tobackported-*
.CHANGELOG.md
file.Purpose of this PR
Why is this PR needed, what hard problem is it solving/fixing?
Testing status
Describe what manual/automated tests were performed for this PR
Comments to reviewers
Notes for the reviewers you have assigned.