Very interesting and promising package. I especially like that there is a PyQt interface which might provide an alternative to another great package: pyqtgraph[0]. [0] https://github.com/pyqtgraph/pyqtgraph
[dead]
Fastplotlib: GPU-accelerated, fast, and interactive plotting library
91–100 of 190 posts
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#92>sine_wave.colors[::3] = "red" I never knew I needed this until now
We offer a lot of ways to slice colors, set cmaps and cmap transforms, they are really useful in neuroscience:
https://fastplotlib.org/ver/dev/_gallery/line/line_colorslic...
https://fastplotlib.org/ver/dev/_gallery/line/line_cmap_more...
https://fastplotlib.org/ver/dev/_gallery/line/line_cmap.html...
And with collections if you want to go crazy: https://fastplotlib.org/ver/dev/_gallery/line_collection/lin...
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#93Earlier quoted context omitted.
Thanks! That is a great question and one that I've we've been battling with as well. As far as we know, this is not possible due to the way different contexts are set up on the GPU https://github.com/pygfx/pygfx/issues/510 tinygrad which I haven't used seems torch-like and has a WGPU backend: https://github.com/tinygrad/tinygrad
Yeah, I remember looking into it myself as well, and not finding any easy path. A shame.... Maybe there's a hard way to do it though :)
I've been looking into this issue with Datoviz [1] following a user request. It turns out there may be a way to achieve it using Vulkan [2] (which Datoviz is based on) and CuPy's UnownedMemory [3]. I wrote a simple proof of concept using only Vulkan and CuPy.
I'm now working on a way for users to wrap a Datoviz GPU buffer as a CuPy array that directly references the Datoviz-managed GPU memory. This should, in principle, enable efficient GPU-based array operations on GPU data without any transfers.
[2] https://registry.khronos.org/vulkan/specs/latest/man/html/VK...
[3] https://docs.cupy.dev/en/latest/reference/generated/cupy.cud...
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#94This looks super cool! Looking forward to trying it. I think a killer feature of these gpu-plotting libraries would be if they could take torch/jax cuda arrays directly and not require a (slow) transfer over cpu.
Would it be possible to leverage the python array api standard? Or is that more suited for just computations?
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#95Earlier quoted context omitted.
For me, one of the most annoying things in my workflow is when I'm waiting for the software to catch up. If I'm making a plot, there's a lot of little tweaks I want to do to visually extract the maximum amount of information from a dataset. For example, if I'm making a histogram, I may want to adjust the number of bins, change to log scale, set min/max to remove outliers, and change the plot size on page. For the sak…
I think this varies a lot depending on what you're doing. I agree 100% that matplotlib is really slow and should be made to run as fast as humanly possible. I would add a (3) to my list above: optimize matplotlib! OTOH, at least for what I'm doing, the code that runs to generate the data that gets plotted dominates the runtime 99% of the time. For me, adjusting plots is usually the time waster. Hence point (2) above.…
Yeah, I'd love it if mpl could be optimized. I do think that it has a lot of weird design decisions that could justify burning it down and starting from scratch (e.g. weird mix of stateful and stateless api), but I've already learned most of its common quirks so I selfishly don't care anymore, and my only significant complaint is that I want it to be faster :)
edit: regarding runtime, I'm sure this varies a lot based on usecase, but for my usual usecase I store a mostly-processed dataset, so the additional processing before drawing the data is usually minimal.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#96[deleted]
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#97Looks very interesting for interactive visualization. I like the animation interface. Also love imgui, glad to see it here. I wish I had better plotting tools for publication quality images (though, honestly I'm pretty happy with matplotlib).
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#98Earlier quoted context omitted.
Yeah, I remember looking into it myself as well, and not finding any easy path. A shame.... Maybe there's a hard way to do it though :)
I've been looking into this issue with Datoviz [1] following a user request. It turns out there may be a way to achieve it using Vulkan [2] (which Datoviz is based on) and CuPy's UnownedMemory [3]. I wrote a simple proof of concept using only Vulkan and CuPy. I'm now working on a way for users to wrap a Datoviz GPU buffer as a CuPy array that directly references the Datoviz-managed GPU memory. This should, in princip…
This looks cools thanks! Makes me wonder if there's any way to do that with WGPU if WGPU is interfacing with Vulkan, probably not easy if possible I"m guessing.
WGPU has security protections since it's designed for the browser so I'm guessing it's impossible.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#99Every two weeks or so I peruse github looking for something like this and I have to say this looks really promising. In statistical genetics we make really big scatterplots called Manhattan plots https://en.wikipedia.org/wiki/Manhattan_plot and we have to use all this highly specialized software to visualize at different scales (for a sense of what this looks like: https://my.locuszoom.org/gwas/236887/ ). Excited to…
If you’re working in R with ggplot2, you could also consider the `ggrastr` package, specifically, `ggrastr::geom_point_rast`
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#100Earlier quoted context omitted.
Yeah, I remember looking into it myself as well, and not finding any easy path. A shame.... Maybe there's a hard way to do it though :)
I've been looking into this issue with Datoviz [1] following a user request. It turns out there may be a way to achieve it using Vulkan [2] (which Datoviz is based on) and CuPy's UnownedMemory [3]. I wrote a simple proof of concept using only Vulkan and CuPy. I'm now working on a way for users to wrap a Datoviz GPU buffer as a CuPy array that directly references the Datoviz-managed GPU memory. This should, in princip…
Wow. So are you saying that you can have some array on the GPU that you setup with python via CuPy, then you call to the webbrowser and give it the pointer address for that GPU array, and the browser through WASM/WebGPU can access that same array? That sounds like a huge browser security hole.