- default flags include warnings enabled by -Wall and -Wextra
- suppressed newer warnings in public headers and internal files
(-Wclass-memaccess, -Wcast-function-type, -Wdeprecated-copy)
- suppressed -Wunused-function from internal source files
Client applications may keep track of the active shader program so as to
not unnecessarily bind and unbind the same shader consecutively as
switching shaders is costly.
The current behavior of the OpenGL compute evaluator is to set the
active shader to 0 (zero) after running its program(s) which might
interfere with the aforemoentioned client applications' behavior,
leading to bugs.
Instead of unsetting any previously set shader program, cache the
current program before using the evaluator program, and reset the active
program to the previous one when done.
In Blender, this lead to some rendering artifacts. See https://
developer.blender.org/D15064 for more details on it.
At build time, the preprocessor symbols: OSD_USES_GLEW or
OSD_USES_INTERNAL_GLAPILOADER determine the GL API loader
that will be used by the OSD library.
This introduces an internal glLoader library which allows
most of the implementation to be agnostic about the
implementation of the GL loading library. Specifically,
this removes references to the GLEW headers and libraries
from the rest of the source code and build system.
This updates the patch basis evaluation functions in Osd
to match recent changes to far/patchBasis.
This also exposes a common facility for dealing with PatchCoord,
PatchArray, and PatchParam. These are exposed as global functions
operating on struct data, since C++ style class methods are not
supported by all of the Osd shader and kernel execution envirionments.
Changes:
- Merged far/patchBasis.cpp to osd/patchBasisCommon{,Types,Eval}.h
- Exposed PatchCoord, PatchArray, and PatchParam to Osd kernels
- exposed OsdEvaluatePatchBasis and OsdEvaluatePatchBasisNormalized
- Updated CPU, TBB, Omp, CUDA, OpenCL, GLSL, HLSL, and Metal evaluators
- Updated glFVarViewer
Now that Far::LimitStencilTable and Far::PatchTable
support evaluation of 1st and 2nd derivatives the
Osd Evaluator API for evaluating stencils and patches
has been updated to match.
Implemented EvalPatchesVarying and EvalPatchesFaceVarying
methods for Osd::*Evaluator classes, i.e. cpu, omp, tbb,
GLXFB, GLSLCompute, OpenCL, and CUDA.
Also, the GPU Kernel implementations have been updated to use
the common patchBasis implementation instead of re-implementing
methods to compute patch basis weights locally.
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.
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.
