Blender Git Statistics -> Developers -> pmoursnv

Patrick Mours (pmoursnv)

Total Commits : 97
Master Commits : 95
Branch Commits : 2
First Commit : August 26, 2019
Latest Commit : January 8, 2021

Commits by Month

DateNumber of Commits
January, 20214
December, 20206
November, 20206
October, 20204
September, 20201
August, 20200
July, 20209
June, 20204
May, 20202
April, 20202
March, 20202
February, 202015
January, 20209
December, 20191
November, 20198
October, 20195
September, 20195
August, 201914

Commit Distribution

PathNumber of Commits

Favourite Files

FilenameTotal Edits

File Changes

ActionTotalPer Commit

Code Changes

ActionTotalPer Commit
Lines Added5 53467.5
Lines Removed3 02336.9

Latest commits Feed

Revision c66f00d by Patrick Mours (master)
January 8, 2021, 12:38 (GMT)
Fix Cycles rendering with OptiX after instance limit increase when building with old SDK

Commit d259e7dcfbbd37cec5a45fdfb554f24de10d0268 increased the instance limit, but only provided
a fall back for the host code for older OptiX SDKs, not for kernel code. This caused a mismatch when
an old SDK was used (as is currently the case on buildbot) and subsequent rendering artifacts. This
fixes that by moving the bit that is checked to a common location that works with both old an new
SDK versions.
Revision d259e7d by Patrick Mours (master)
January 7, 2021, 18:23 (GMT)
Cycles: Increase instance limit for OptiX acceleration structure building

For a while now OptiX had support for 28-bits of instance IDs, instead of the initial 24-bits (see also
value reported by OPTIX_DEVICE_PROPERTY_LIMIT_MAX_INSTANCE_ID). This change makes use of
that and also adds an error reported when the number of instances an OptiX acceleration structure is
created with goes beyond the limit, to make this clear instead of just rendering an image with artifacts.

Manifest Tasks: T81431
Revision 3373d14 by Patrick Mours (master)
January 5, 2021, 17:37 (GMT)
Fix T83925: Crash when rendering on the CPU with OptiX denoiser enabled

Rendering on the CPU uses the Embree BVH layout, whether the OptiX denoiser is enabled or not.
This means the "build_bvh" function gets a "BVHEmbree" object to fill and not a "BVHMulti" as it
was assuming before, which caused crashes due to memory geting overwritten incorrectly. This
fixes that by redirecting Embree BVH builds to the Embree device.

Manifest Tasks: T83925
Revision 166c0db by Patrick Mours (master)
January 5, 2021, 16:59 (GMT)
Fix T83915: Subdivision Surface modifier causes visual artifacts in Cycles rendered viewport - CPU and OptiX

Changing the geometry in the current scene caused the primitive offsets for all geometry to
change, but the values would not be updated in all bottom-level BVH structures. Rendering
artifacts and crashes where the result. This fixes that by ensuring all BVH structures are
updated when the primitive offsets change.
Revision bfb6fce by Patrick Mours (master)
December 11, 2020, 12:24 (GMT)
Cycles: Add CPU+GPU rendering support with OptiX

Adds support for building multiple BVH types in order to support using both CPU and OptiX
devices for rendering simultaneously. Primitive packing for Embree and OptiX is now
standalone, so it only needs to be run once and can be shared between the two. Additionally,
BVH building was made a device call, so that each device backend can decide how to
perform the building. The multi-device for instance creates a special multi-BVH that holds
references to several sub-BVHs, one for each sub-device.

Reviewed By: brecht, kevindietrich

Differential Revision:
Revision 41bca5a by Patrick Mours (master)
December 9, 2020, 16:06 (GMT)
Fix T83581: "Only local" ambient occlusion option causes error on OptiX 2.92

The SVM AO node calls "scene_intersect_local" with a NULL pointer for the intersection
information, which caused a crash with OptiX since it was not checking for this case and
always dereferencing this pointer. This fixes that by checking whether any hit information
was requested first (like is done in the BVH2 intersection routines).
Revision d7cf464 by Patrick Mours (master)
December 8, 2020, 15:13 (GMT)
Cycles: Remove "OptiX support is experimental" notice

OptiX support is not in fact experimental anymore, so it is time for that notice to go.
All Cycles features that are currently supported on the GPU do work now when OptiX is selected.
Revision 612b83b by Patrick Mours (master)
December 8, 2020, 15:06 (GMT)
Cycles: Enable baking panel in OptiX and redirect those requests to CUDA for now

This enables support for baking when OptiX is active, but uses CUDA for that behind the scenes, since
the way baking is currently implemented does not work well with OptiX.

Reviewed By: brecht

Differential Revision:
Revision c10546f by Patrick Mours (master)
December 4, 2020, 12:04 (GMT)
Cycles: Add support for shader raytracing in OptiX

Support for the AO and bevel shader nodes requires calling "optixTrace" from within the shading
VM, which is only allowed from inlined functions to the raygen program or callables. This patch
therefore converts the shading VM to use direct callables to make it work. To prevent performance
regressions a separate kernel module is compiled and used for this purpose.

Reviewed By: brecht

Differential Revision:
Revision a3c4091 by Patrick Mours (master)
December 3, 2020, 14:20 (GMT)
Fix Cycles device kernels containing debug assertation code

NanoVDB includes "assert.h" and makes use of "assert" in several places and since the compile
pipeline for CUDA/OptiX kernels does not define "NDEBUG" for release builds, those debug
checks were always added. This is not intended, so this patch disables "assert" for CUDA/OptiX
by defining "NDEBUG" before including NanoVDB headers.
This also fixes a warning about unknown pragmas in NanoVDB thrown by the CUDA compiler.

MiikaHweb - Blender Git Statistics v1.06
By: Miika HämäläinenLast update: Nov-07-2014 14:18 MiikaHweb | 2003-2021