You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+61Lines changed: 61 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,72 @@
1
1
# CHANGELOG
2
2
3
+
## [0.4.3] - 2022-09-20
4
+
5
+
- Update all samples to use GPU interop path by default
6
+
- Fix for arrays > 2GB in length
7
+
- Add support for per-vertex USD mesh colors with warp.render class
8
+
9
+
## [0.4.2] - 2022-09-07
10
+
11
+
- Register Warp samples to the sample browser in Kit
12
+
- Add NDEBUG flag to release mode kernel builds
13
+
- Fix for particle solver node when using a large number of particles
14
+
- Fix for broken cameras in Warp sample scenes
15
+
16
+
## [0.4.1] - 2022-08-30
17
+
18
+
- Add geometry sampling methods, see `wp.sample_unit_cube()`, `wp.sample_unit_disk()`, etc
19
+
- Add `wp.lower_bound()` for searching sorted arrays
20
+
- Add an option for disabling code-gen of backward pass to improve compilation times, see `wp.set_module_options({"enable_backward": False})`, True by default
21
+
- Fix for using Warp from Script Editor or when module does not have a `__file__` attribute
22
+
- Fix for hot reload of modules containing `wp.func()` definitions
23
+
- Fix for debug flags not being set correctly on CUDA when `wp.config.mode == "debug"`, this enables bounds checking on CUDA kernels in debug mode
24
+
- Fix for code gen of functions that do not return a value
25
+
26
+
27
+
## [0.4.0] - 2022-08-09
28
+
29
+
- Fix for FP16 conversions on GPUs without hardware support
30
+
- Fix for `runtime = None` errors when reloading the Warp module
31
+
- Fix for PTX architecture version when running with older drivers, see `wp.config.ptx_target_arch`
32
+
- Fix for USD imports from `__init__.py`, defer them to individual functions that need them
33
+
- Fix for robustness issues with sign determination for `wp.mesh_query_point()`
34
+
- Fix for `wp.HashGrid` memory leak when creating/destroying grids
35
+
- Add CUDA version checks for toolkit and driver
36
+
- Add support for cross-module `@wp.struct` references
37
+
- Support running even if CUDA initialization failed, use `wp.is_cuda_available()` to check availability
38
+
- Statically linking with the CUDA runtime library to avoid deployment issues
39
+
40
+
41
+
### Breaking Changes
42
+
43
+
- Removed `wp.runtime` reference from the top-level module, as it should be considered private
44
+
45
+
46
+
## [0.3.2] - 2022-07-19
47
+
48
+
- Remove Torch import from `__init__.py`, defer import to `wp.from_torch()`, `wp.to_torch()`
49
+
3
50
4
51
## [0.3.1] - 2022-07-12
5
52
6
53
- Fix for marching cubes reallocation after initialization
7
54
- Add support for closest point between line segment tests, see `wp.closest_point_edge_edge()` builtin
8
55
- Add support for per-triangle elasticity coefficients in simulation, see `wp.sim.ModelBuilder.add_cloth_mesh()`
56
+
- Add support for specifying default device, see `wp.set_device()`, `wp.get_device()`, `wp.ScopedDevice`
57
+
- Add support for multiple GPUs (e.g., `"cuda:0"`, `"cuda:1"`), see `wp.get_cuda_devices()`, `wp.get_cuda_device_count()`, `wp.get_cuda_device()`
58
+
- Add support for explicitly targeting the current CUDA context using device alias `"cuda"`
59
+
- Add support for using arbitrary external CUDA contexts, see `wp.map_cuda_device()`, `wp.unmap_cuda_device()`
60
+
- Add PyTorch device aliasing functions, see `wp.device_from_torch()`, `wp.device_to_torch()`
61
+
62
+
63
+
### Breaking Changes
64
+
65
+
- A CUDA device is used by default, if available (aligned with `wp.get_preferred_device()`)
66
+
-`wp.ScopedCudaGuard` is deprecated, use `wp.ScopedDevice` instead
67
+
-`wp.synchronize()` now synchronizes all devices; for finer-grained control, use `wp.synchronize_device()`
68
+
- Device alias `"cuda"` now refers to the current CUDA context, rather than a specific device like `"cuda:0"` or `"cuda:1"`
### How does Warp relate to other Python projects for GPU programming, e.g.: Numba, Taichi, cuPy, PyTorch, etc?
137
+
-------
138
+
139
+
Warp is inspired by many of these projects, and is closely related to Numba and Taichi which both expose kernel programming to Python. These frameworks map to traditional GPU programming models, so many of the high-level concepts are similar, however there are some functionality and implementation differences.
140
+
141
+
Compared to Numba, Warp supports a smaller subset of Python, but offering auto-differentiation of kernel programs, which is useful for machine learning. Compared to Taichi Warp uses C++/CUDA as an intermediate representation, which makes it convenient to implement and expose low-level routines. In addition, we are building in datastructures to support geometry processing (meshes, sparse volumes, point clouds, USD data) as first-class citizens that are not exposed in other runtimes.
142
+
143
+
Warp does not offer a full tensor-based programming model like PyTorch and JAX, but is designed to work well with these frameworks through data sharing mechanisms like `__cuda_array_interface__`. For computations that map well to tensors (e.g.: neural-network inference) it makes sense to use these existing tools. For problems with a lot of e.g.: sparsity, conditional logic, hetergenous workloads (like the ones we often find in simulation and graphics), then the kernel-based programming model like the one in Warp are often more convenient since users have control over individual threads.
144
+
145
+
### Does Warp support all of the Python language?
146
+
-------
147
+
148
+
No, Warp supports a subset of Python that maps well to the GPU. Our goal is to not have any performance cliffs so that users can expect consistently good behavior from kernels that is close to native code. Examples of unsupported concepts that don't map well to the GPU are dynamic types, list comprehensions, exceptions, garbage collection, etc.
149
+
150
+
### When should I call `wp.synchronize()`?
151
+
-------
152
+
153
+
One of the common sources of confusion for new users is when calls to `wp.synchronize()` are necessary. The answer is "almost never"! Synchronization is quite expensive, and should generally be avoided unless necessary. Warp naturally takes care of synchronization between operations (e.g.: kernel launches, device memory copies).
154
+
155
+
For example, the following requires no manual synchronization, as the conversion to NumPy will automatically synchronize:
# bring data back to host (and implicitly synchronize)
163
+
x = array_z.numpy()
164
+
```
165
+
166
+
The _only_ case where manual synchronization is needed is when copies are being performed back to CPU asynchronously, e.g.:
167
+
168
+
```python
169
+
# copy data back to cpu from gpu, all copies will happen asynchronously to Python
170
+
wp.copy(cpu_array_1, gpu_array_1)
171
+
wp.copy(cpu_array_2, gpu_array_2)
172
+
wp.copy(cpu_array_3, gpu_array_3)
173
+
174
+
# ensure that the copies have finished
175
+
wp.synchronize()
176
+
177
+
# return a numpy wrapper around the cpu arrays, note there is no implicit synchronization here
178
+
a1 = cpu_array_1.numpy()
179
+
a2 = cpu_array_2.numpy()
180
+
a3 = cpu_array_3.numpy()
181
+
```
182
+
183
+
### What happens when you differentiate a function like `wp.abs(x)`?
184
+
-------
185
+
186
+
Non-smooth functions such as `y=|x|` do not have a single unique gradient at `x=0`, rather they have what is known as a `subgradient`, which is formally the convex hull of directional derivatives at that point. The way that Warp (and most auto-differentiation framworks) handles these points is to pick an arbitrary gradient from this set, e.g.: for `wp.abs()`, it will arbitrarily choose the gradient to be 1.0 at the origin. You can find the implementation for these functions in `warp/native/builtin.h`.
187
+
188
+
Most optimizers (particularly ones that exploit stochasticity), are not sensitive to the choice of which gradient to use from the subgradient, although there are exceptions.
189
+
190
+
### Does Warp support multi-GPU programming?
191
+
-------
192
+
193
+
Yes! Since verrsion `0.4.0` we support allocating, launching, and copying between multiple GPUs in a single process. We follow the naming conventions of PyTorch and use aliases such as `cuda:0`, `cuda:1`, `cpu` to identify individual devices.
194
+
195
+
### Should I switch to Warp over IsaacGym / PhysX?
196
+
-------
197
+
198
+
Warp is not a replacement for IsaacGym, IsaacSim, or PhysX - while Warp does offer some physical simulation capabilities this is primarily aimed at developers who need differentiable physics, rather than a fully featured physics engine. Warp is also integrated with IsaacGym and is great for performing auxilary tasks such as reward and observation computations for reinforcement learning.
0 commit comments