pystencils merge requestshttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests2022-05-11T14:33:30+02:00https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/275WIP: Revamp the type system2022-05-11T14:33:30+02:00Markus HolzerWIP: Revamp the type systemMarkus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/175WIP: Opencl to SPIR-V ahead-of-time compilation2023-03-16T12:42:10+01:00Stephan SeitzWIP: Opencl to SPIR-V ahead-of-time compilationThis does not yet use the pystencils' cache folder or disk caching of the compilation.
This can be used to embed compiled bytecode into waLBerla executables as I do with my Vulkan wrapper. Not sure if this is a good way to go but at lea...This does not yet use the pystencils' cache folder or disk caching of the compilation.
This can be used to embed compiled bytecode into waLBerla executables as I do with my Vulkan wrapper. Not sure if this is a good way to go but at least we can experiment with it.
A good way to proceed with this MR is also a comparison between hip/sicl/ocl/vulkan in order to identify a suitable backend for pystencils.https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/42WIP: make kerncraft/matplotlib tests pass with new image2019-09-02T08:28:51+02:00Stephan SeitzWIP: make kerncraft/matplotlib tests pass with new image--https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/98WIP: Graph datahandling2020-01-28T14:24:04+01:00Stephan SeitzWIP: Graph datahandlingThis is the draft for a data handling that (optionally) forwards all calls to SerialDatahandling.
All calls and data transfers get recorded for the creation of an execution graph.
Needs to be changed after the breaking changes in dat...This is the draft for a data handling that (optionally) forwards all calls to SerialDatahandling.
All calls and data transfers get recorded for the creation of an execution graph.
Needs to be changed after the breaking changes in datahandling.
Needs a tiny change in lbmpy:
Instead of using `TimeLoop(...)` for time loop creation a custom function is used.https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/106WIP: Cuda autotune2020-10-07T13:04:35+02:00Stephan SeitzWIP: Cuda autotuneThis PR introduces ~~two~~ one change~~s~~:
- ~~rotate (32,1,1) depending on field strides to fastest dimension. So (1,1,32) for c-layout and (32,1,1) for fortran layout. So pystencils will be fast also for c-layout (this will always be...This PR introduces ~~two~~ one change~~s~~:
- ~~rotate (32,1,1) depending on field strides to fastest dimension. So (1,1,32) for c-layout and (32,1,1) for fortran layout. So pystencils will be fast also for c-layout (this will always be performed)~~
- auto-tune the block dimensions to whatevers is fastest for a specific kernel on localhost. On first kernel call different layouts are tried and the kernel will be called henceforth with the fastest configuration (disk_cached). This could be intersting for OpenCL where we don't know which launch config is the fastest (on OpenCL the runtime can alternatively give a hint on that).
One drawback: the test calls are only correct if input and output fields do not overlap (so no in-place kernels).https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/47WIP: Complex number support2019-10-11T17:57:49+02:00Stephan SeitzWIP: Complex number supportDepends on !43
Pystencils should eventually support complex numbers. Even if complex fields can be considered harmful for CPU vectorization. The concept is nice since SymPy and Python support complex numbers and there should be no pe...Depends on !43
Pystencils should eventually support complex numbers. Even if complex fields can be considered harmful for CPU vectorization. The concept is nice since SymPy and Python support complex numbers and there should be no performance disadvantage for normal CPU and GPU code. Many applications in physics and signal processing rely on complex numbers.
Complex output fields can be passed directly to libraries like `cufft`.
Problem: In C++, one cannot mix calculation with `std::complex<float>` with `std::complex<double>`. So user has to specify `data_type='float32'` when single precision complex floats are desired.
TODO:
* GPU support with the header pycuda provides
* only use `complex_helper.h` when needed
* remove commits from !34 (probably the code will be changed)
* rebase -ihttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/20WIP: Astnodes for interpolation2019-09-24T18:59:50+02:00Stephan SeitzWIP: Astnodes for interpolationThis PR needs maybe still needs some clean-up.
However, it would be good to recieve already some feed-back.
What works:
- Using CUDA textures
- Using HW accelerated interpolation for float32 textures
- Implement linear interpol...This PR needs maybe still needs some clean-up.
However, it would be good to recieve already some feed-back.
What works:
- Using CUDA textures
- Using HW accelerated interpolation for float32 textures
- Implement linear interpolations either via software (CPU, GPU), texture accesses without HW-interpolation but HW boundary handling
- Adding transformed coordinate systems to fields
What does not work:
- HW boundary handling for CUDA textures for the boundary handling modes `mirror` and `wrap` (apparently they have been removed from CUDA's API but are still present in pycuda. Now there's only
```
cudaBoundaryModeZero = 0
Zero boundary mode
cudaBoundaryModeClamp = 1
Clamp boundary mode
cudaBoundaryModeTrap = 2
Trap boundary mode
```
Wtf is trap boundary mode? Nothing is documented so we can only experiment.
What kind of works:
- B-Spline interpolation on GPU using this repo as a submodule (http://www.dannyruijters.nl/cubicinterpolation/), to lazy for tests. Don't know how to prove correctness
- Textures for dtypes with itemsize > 4. PyCUDA has helper header (https://github.com/inducer/pycuda/blob/master/pycuda/cuda/pycuda-helpers.hpp) that loads doubles by two int fetches. However, this hack seems to be only working if we add a 0.5 offset and make all functions in this header accept float.https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/210WIP: Assembly2021-03-26T20:17:13+01:00Markus HolzerWIP: AssemblyAdds the functionality to directly show the assembly output of the generated code.
Further, the base pointer specification is revealed to the user which is helpful to minimize register spilling in some cases.Adds the functionality to directly show the assembly output of the generated code.
Further, the base pointer specification is revealed to the user which is helpful to minimize register spilling in some cases.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/187WIP: ARM NEON vectorization2020-11-18T14:59:55+01:00Michael Kuronmkuron@icp.uni-stuttgart.deWIP: ARM NEON vectorizationWith Apple's new laptops having ARM processors, I thought it might be time to add ARM NEON vectorization to pystencils. I don't currently have hardware to test on, but a bunch of test cases from both pystencils and lbmpy at least compile...With Apple's new laptops having ARM processors, I thought it might be time to add ARM NEON vectorization to pystencils. I don't currently have hardware to test on, but a bunch of test cases from both pystencils and lbmpy at least compile successfully. A Raspberry Pi 4 might actually be a useful and cheap device to add to CI for this purpose.
This may also become useful once ARM HPC clusters actually get deployed, though these might end up using SVE instead of NEON -- while I have added a few `if`s for that case, additional work is needed because SVE's vector width is determined at runtime.Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/225WIP: ARM cache line zeroing2021-04-01T22:59:29+02:00Michael Kuronmkuron@icp.uni-stuttgart.deWIP: ARM cache line zeroingARM has a cache line zero instruction that prevents data that will be overwritten anyway from being loaded from RAM. Kind of a light version of a non-temporal store. Saw this near the end of https://www.youtube.com/watch?v=BP7XD7JHgrI in...ARM has a cache line zero instruction that prevents data that will be overwritten anyway from being loaded from RAM. Kind of a light version of a non-temporal store. Saw this near the end of https://www.youtube.com/watch?v=BP7XD7JHgrI in the context of SVE, but might be relevant on Neon too. Just wanted to keep a note of this here.
Integrating this into pystencils is probably not completely straight-forward as you first need to check how much would be zeroed (64 bytes on all current chips, not guaranteed to match the cache line size), zero it, and then write the corresponding amount of data. Not sure if there are guarantees as to whether it's a multiple of the vector width.
There is not a whole lot of information for ARM, but the exact same thing has existed on IBM‘s PowerPC architecture (!228) for decades. There, a cache line has 128 bytes (can be queried from the kernel via `sysconf(_SC_LEVEL1_DCACHE_LINESIZE)`) and can be zeroed with the `__dcbz` intrinsic.https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/117WIP: Add InterpolatorAccess.__getnewargs__2020-01-28T14:23:15+01:00Stephan SeitzWIP: Add InterpolatorAccess.__getnewargs__it was missing and instead TypedSymbol.__getnewargs__ was usedit was missing and instead TypedSymbol.__getnewargs__ was usedhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/101WIP: Add csqrt, cpow to cuda_complex.hpp2021-11-22T15:41:05+01:00Stephan SeitzWIP: Add csqrt, cpow to cuda_complex.hppApparently, I'm using here a feature of a more recent C++ verion.
Specializing `cpow(T)` to `cpow(complex<T>)`Apparently, I'm using here a feature of a more recent C++ verion.
Specializing `cpow(T)` to `cpow(complex<T>)`https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/97WIP: Add assumptions based on cast_func.args[0]2021-11-22T15:32:23+01:00Stephan SeitzWIP: Add assumptions based on cast_func.args[0]This enables cast_func(1.f, create_type('double')).positive == TrueThis enables cast_func(1.f, create_type('double')).positive == Truehttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/151Use dark mode for code preview if user prefers `prefers-color-scheme: dark`2020-04-23T07:59:41+02:00Stephan SeitzUse dark mode for code preview if user prefers `prefers-color-scheme: dark`pystencils currently does not look good in dark mode :/pystencils currently does not look good in dark mode :/https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/183Updated Kerncraft Coupling2020-11-06T15:45:24+01:00Julian HammerUpdated Kerncraft Couplinghttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/116Throw error when trying to sympify `pystencils.Field` (e.g. using it in an...2020-01-03T13:24:14+01:00Stephan SeitzThrow error when trying to sympify `pystencils.Field` (e.g. using it in an...Throw error when trying to sympify `pystencils.Field` (e.g. using it in an Assignment without indexing)
This is a typical error when using pystencils: you forget the index and use a field directly in an Assignment.
Edit: apparently...Throw error when trying to sympify `pystencils.Field` (e.g. using it in an Assignment without indexing)
This is a typical error when using pystencils: you forget the index and use a field directly in an Assignment.
Edit: apparently, this error is only triggered on recent versions of Sympy that can sympify using `__sympy__` (not on CI).https://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/113Test pystencils_autodiff in integration test2020-01-08T13:49:44+01:00Stephan SeitzTest pystencils_autodiff in integration testhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/111Test pystencils_autodiff in integration test2019-12-17T18:56:19+01:00Stephan SeitzTest pystencils_autodiff in integration testhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/250Switch index type from int32 to int642021-06-07T13:38:27+02:00Markus HolzerSwitch index type from int32 to int64For large domain sizes, int32 is not sufficient. Thus it is planned for waLBerla to change `cell_index_t` from `int` to `int64`. To make it consistent with pystencils and to prevent conversion warnings the index type for pystencils is al...For large domain sizes, int32 is not sufficient. Thus it is planned for waLBerla to change `cell_index_t` from `int` to `int64`. To make it consistent with pystencils and to prevent conversion warnings the index type for pystencils is also adapted to int64
Fixes https://i10git.cs.fau.de/pycodegen/lbmpy/-/issues/18Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/pycodegen/pystencils/-/merge_requests/23Seeding of RNG2019-08-09T08:55:31+02:00Michael Kuronmkuron@icp.uni-stuttgart.deSeeding of RNGFor https://i10git.cs.fau.de/pycodegen/lbmpy/merge_requests/2For https://i10git.cs.fau.de/pycodegen/lbmpy/merge_requests/2Martin BauerMartin Bauer