search

PixarAnimationStudios / OpenUSD

Universal Scene Description
http://www.openusd.org
Other
5.56k stars 1.16k forks source link

Roadblocks of Storm in OptiX/CUDA viewport #992

Open luheqi-code opened 4 years ago

luheqi-code commented 4 years ago

Description of Issue

We made an OptiX/CUDA viewport with existing Storm/Stream(OpenGL) backend features, such as picking, highlighting, overlay display and etc. However, it was hacky and difficult to interop these existing features. As suggested by Pol Jeremias-Vila, a GitHub issue with the list of roadblocks is logged here.

The original post from USD-Interest forum can be found below: https://groups.google.com/forum/?utm_source=footer#!topic/usd-interest/XcRDUDwZ2e8

List of Roadblocks

  1. HdxTaskController::_CreateRenderGraph()

    We start from here, because this is the place where existing features(e.g., _CreateSelectionTask) are registered. There are two important points, which lead us to other road blocks.

    1. _IsStreamRenderingBackend makes only HdStRenderDelegate be able to use existing features.
    2. Rendering rendergraph has so many things, some of which we do not need.

  2. HdStRenderDelegate is final

    The final key word prevents us to inherent form it. Dirty workaround is needed to get rid of it.

  3. Simple light in HdxTaskController::SetLightingState

    Before 19.07, if a backend does not support simple light, no simple light parameter will be set. But in 19.07, simple light is set anyway as long as the task controller creates simple light task.

  4. Difficult to remove/invalidate tasks from HdRenderIndex

    As mentioned in the 1st point, there are many tasks we do not need. However, there is no public functions to remove tasks from _taskMap. So dirty workaround is used to keep only useful tasks for us: renderTask_defaultMaterialTag pickTask selectionTask colorCorrectionTask

  5. HdStLight is final

    On USD 19.07 stream backend uses item types also as stream type, such as HdStLight. So we have to inherit from stream type of objects. Unfortunately, nearly all of these types are marked as final. Fortunately, static cast is used to check HdStLight, workaround is easier to made.

System Information (OS, Hardware)

Windows 10 / Centos 7

Package Versions

Release USD v19.07

jilliene commented 4 years ago

Filed as internal issue #USD-5616

guillaume-lafo-mpc commented 4 years ago

Morning!

We've encountered the issue relating to the task list, here at MPC. We've upgraded our project to USD 19.11 and will upgrade to USD 20.02 once the release is official. The task management generates a decent amount of spam in the error log that can be confusing when investigating other issues.

This issue is quite a few months old... could you please provide us with an update?

Regards, Guillaume Laforte

luheqi-code commented 4 years ago

Here are the details about the issue Guillaume mentioned:

Brief: The issue is relevant to 4th point of "List of Roadblocks"

Error message: The error message is from HdRenderIndex::SyncAll, TF_VERIFY(taskInfo.task == task): _Error in 'pxrInternal_v019pxrReserved::HdRenderIndex::SyncAll' at line 1114 in file : 'Failed verification: ' taskInfo.task == task ''

Why it was happened (short): HdxTaskController::_CreateRenderGraph() created many tasks we do not need. So we removed these tasks in a dirty way by directly removing from the taskMap of HdRenderIndex. The verification in HdRenderIndex::SyncAll caught the hack and gave errors.

Our viewport is implemented as a Hydra plugin, and we avoid modification of USD source code. As there is no way to remove/avoid creation useless tasks in HdxTaskController directly, the dirty workaround is applied.

Why it was happened (long):

  1. HdxTaskController::_CreateRenderGraph(), checks if _IsStormRenderingBackend(GetRenderIndex()), then creates all the tasks. The relevant ids for example _oitResolveTaskId is assigned.

  2. During execution, HdxTaskController::GetRenderingTasks, returns valid tasks by checking the relevant ids for example _oitResolveTaskId. Then return all the tasks that have been created in _CreateRenderGraph().

[blocker: there is no way to remove or avoid creation of the tasks of HdxTaskController.]

  1. Due to the blocker, we worked around the HdRenderIndex. We kept only "renderTask_defaultMaterialTag", "pickTask", "selectionTask" and "colorCorrectionTask" by invalidating the other tasks as: task = boost::make_shared(task.get()->GetId());

If we removing task by HdRenderIndex::RemoveTask(), it would generate much more errors and the viewport would not work.

  1. HdRenderIndex::SyncAll would verify the tasks of HdRenderIndex with the tasks of HdxTaskController. Because we have invalidated the tasks of HdRenderIndex, the verification failed. The viewport works but with error messages.

It seems, USD 20.02 has not changed the code around this issue.

How Pixar may help:

Possibility 1: Pixar may provide us a better approach to use existing storm features instead of our approach. Possibility 2: Pixar may change HdxTaskController to be able to remove or avoid creation some of tasks. Possibility 3: Pixar may change the validation in HdRenderIndex::SyncAll, and allows a routine to work when the tasks of HdxTaskController and HdRenderIndex do not match. Possibility 4: Anyother things that maybe helpful.

Thanks,

Heqi