Commit Graph

3 Commits

Author SHA1 Message Date
Takahito Tejima
541aeddd3a Osd API refactor: EvalStencils and EvalPatches
Add EvalStencils and EvalPatches API for most of CPU and GPU evaluators.

with this change, Eval API in the osd layer consists of following parts:

- Evaluators (Cpu, Omp, Tbb, Cuda, CL, GLXFB, GLCompute, D3D11Compute)
  implements EvalStencils and EvalPatches(*). Both supports derivatives
  (not fully implemented though)

- Interop vertex buffer classes (optional, same as before)
  Note that these classes are not necessary to use Evaluators.
  All evaluators have EvalStencils/Patches which take device-specific
  buffer objects. For example, GLXFBEvaluator can take GLuint directly
  for both stencil tables and input primvars. Although using these
  interop classes makes it easy to integrate osd into relatively
  simple applications.

- device-dependent StencilTable and PatchTable (optional)
  These are also optional, but can be used simply a substitute of
  Far::StencilTable and Far::PatchTable for osd evaluators.

- PatchArray, PatchCoord, PatchParam
  They are tiny structs used for GPU based patch evaluation.

(*) TODO and known issues:
- CLEvaluator and D3D11Evaluator's EvalPatches() have not been implemented.
- GPU Gregory patch evaluation has not been implemented in EvalPatches().
- CudaEvaluator::EvalPatches() is very unstable.
- All patch evaluation kernels have not been well optimized.
- Currently GLXFB kernel doesn't support derivative evaluation.
   There's a technical difficulty for the multi-stream output.
2015-05-25 22:43:43 -07:00
Takahito Tejima
33bfbf699b Refurbish osd layer API.
In OpenSubdiv 2.x, we encapsulated subdivision tables into
compute context in osd layer since those tables are order-dependent
and have to be applied in a certain manner. In 3.0, we adopted stencil
table based refinement. It's more simple and such an encapsulation is
no longer needed. Also 2.0 API has several ownership issues of GPU
kernel caching, and forces unnecessary instantiation of controllers
even though the cpu kernels typically don't need instances unlike GPU ones.

This change completely revisit osd client facing APIs. All contexts and
controllers were replaced with device-specific tables and evaluators.
While we can still use consistent API across various device backends,
unnecessary complexities have been removed. For example, cpu evaluator
is just a set of static functions and also there's no need to replicate
FarStencilTables to ComputeContext.

Also the new API delegates the ownership of compiled GPU kernels
to clients, for the better management of resources especially in multiple
GPU environment.

In addition to integrating ComputeController and EvalStencilController into
a single function Evaluator::EvalStencils(), EvalLimit API is also added
into Evaluator. This is working but still in progress, and we'll make a followup
change for the complete implementation.

-some naming convention changes:
GLSLTransformFeedback to GLXFBEvaluator
GLSLCompute to GLComputeEvaluator

-move LimitLocation struct into examples/glEvalLimit.
We're still discussing patch evaluation interface. Basically we'd like
to tease all ptex-specific parametrization out of far/osd layer.

TODO:
-implments EvalPatches() in the right way
-derivative evaluation API is still interim.
-VertexBufferDescriptor needs a better API to advance its location
-synchronization mechanism is not ideal (too global).
-OsdMesh class is hacky. need to fix it.
2015-05-08 17:31:26 -07:00
manuelk
0d4582b34c Add 'sticles' to the glEvalLimit code example
Make the sample locations dynamic by adding a velocity vector. Face boundary
crossing is handled using the new ptex adjacency functionality recently
added to the Far::TopologyRefiner.
2014-09-30 18:53:47 -07:00