Make matplotlib running on GPU/CUDA

Thank you Chris for your reply.

I have to admit I already stumbled on VisPy while doing my research on the
web. Still, I've got a lot of code already working with *matplotlib*.
Indeed, not only I plot data with it, but i manage a lot of *mpl events* to
provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
the beginning few lines were managed and noone complained, now that big
amout of data has to be displayed, the non-GPU core of the library is
starting to show its limits.

Since matplotlib is a reference library for this kind of applications, I
thought it deserved an update in this direction. If anyone is willing to do
so, I'm available to discuss possible solutions and also provide any help I
can give.

Best regards,
Francesco Faccenda

2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:

···

On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda < > f.faccenda86 at gmail.com> wrote:

But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
K40c), so I?d like to know if there is a way to make matplotlib run on it,
or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.

I tihnk you want VisPy:

https://vispy.readthedocs.io/en/latest/

It's a plotting package with a kinda like matplotlib API, built on OpenGL.

Unfortunately, it doesn't look like it's been updated in a while -- from
teh docs. But the gitHub project is active:

GitHub - vispy/vispy: Main repository for Vispy

So maybe it's only the docs that haven't been updated!

But probably a much better option than trying to shoehorn GPU rendering
into MPL.

The problem is that while MPL was designed to be "backend" independent --
so it is "easy" to plug in an alternative renderer, the rendering model is
not really well suited to GPU rendering -- it would take a lot of
refactoring to really be able to take advantage of the graphics card.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE
<Google Maps;
  (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170913/8c419f09/attachment.html&gt;

A bit of background regarding efforts in this area...

A long time ago, some experiments were done to see if an opengl backend
could be made for matplotlib. The results weren't that great, particularly
for text rendering, so the effort was dropped. The core developers all
agree that an opengl backend would be neat to have, but we all have
limited, if any, experience developing opengl. Furthermore, such a backend
would likely require a lot of rapid development and trial-n-error. So, we
encouraged others to go develop a package or two separately, with the eye
for bringing it back into matplotlib when it was ready. Glumpy and a few
other projects were born from that prodding.

VisPy was an attempt to consolidate the development efforts for those
projects. The matplotlib devs had very fruitful discussions with some VisPy
devs back at SciPy 2015, but the project became non-responsive shortly
afterwards.

Ben Root

···

On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:

Thank you Chris for your reply.

I have to admit I already stumbled on VisPy while doing my research on the
web. Still, I've got a lot of code already working with *matplotlib*.
Indeed, not only I plot data with it, but i manage a lot of *mpl events*
to provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
the beginning few lines were managed and noone complained, now that big
amout of data has to be displayed, the non-GPU core of the library is
starting to show its limits.

Since matplotlib is a reference library for this kind of applications, I
thought it deserved an update in this direction. If anyone is willing to do
so, I'm available to discuss possible solutions and also provide any help I
can give.

Best regards,
Francesco Faccenda

2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:

On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda < >> f.faccenda86 at gmail.com> wrote:

But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
K40c), so I?d like to know if there is a way to make matplotlib run on it,
or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.

I tihnk you want VisPy:

https://vispy.readthedocs.io/en/latest/

It's a plotting package with a kinda like matplotlib API, built on
OpenGL.

Unfortunately, it doesn't look like it's been updated in a while -- from
teh docs. But the gitHub project is active:

GitHub - vispy/vispy: Main repository for Vispy

So maybe it's only the docs that haven't been updated!

But probably a much better option than trying to shoehorn GPU rendering
into MPL.

The problem is that while MPL was designed to be "backend" independent --
so it is "easy" to plug in an alternative renderer, the rendering model is
not really well suited to GPU rendering -- it would take a lot of
refactoring to really be able to take advantage of the graphics card.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE
<Google Maps;
  (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170913/ab39dca3/attachment.html&gt;

Thank you, Ben.

unfortunately I don't have experience developing opengl neither, but I'd
like to make an attempt riesuming this subject.

I am starting from this: GitHub - ChrisBeaumont/mplgl: Investigating an OpenGL backend for Matplotlib

Can anyone confirm this is the last update we have for this project?

Francesco Faccenda

2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:

A bit of background regarding efforts in this area...

A long time ago, some experiments were done to see if an opengl backend
could be made for matplotlib. The results weren't that great, particularly
for text rendering, so the effort was dropped. The core developers all
agree that an opengl backend would be neat to have, but we all have
limited, if any, experience developing opengl. Furthermore, such a backend
would likely require a lot of rapid development and trial-n-error. So, we
encouraged others to go develop a package or two separately, with the eye
for bringing it back into matplotlib when it was ready. Glumpy and a few
other projects were born from that prodding.

VisPy was an attempt to consolidate the development efforts for those
projects. The matplotlib devs had very fruitful discussions with some VisPy
devs back at SciPy 2015, but the project became non-responsive shortly
afterwards.

Ben Root

Thank you Chris for your reply.

I have to admit I already stumbled on VisPy while doing my research on
the web. Still, I've got a lot of code already working with *matplotlib*.
Indeed, not only I plot data with it, but i manage a lot of *mpl events*
to provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
at the beginning few lines were managed and noone complained, now that big
amout of data has to be displayed, the non-GPU core of the library is
starting to show its limits.

Since matplotlib is a reference library for this kind of applications, I
thought it deserved an update in this direction. If anyone is willing to do
so, I'm available to discuss possible solutions and also provide any help I
can give.

Best regards,
Francesco Faccenda

2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:

But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
K40c), so I?d like to know if there is a way to make matplotlib run on it,
or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.

I tihnk you want VisPy:

https://vispy.readthedocs.io/en/latest/

It's a plotting package with a kinda like matplotlib API, built on
OpenGL.

Unfortunately, it doesn't look like it's been updated in a while -- from
teh docs. But the gitHub project is active:

GitHub - vispy/vispy: Main repository for Vispy

So maybe it's only the docs that haven't been updated!

But probably a much better option than trying to shoehorn GPU rendering
into MPL.

The problem is that while MPL was designed to be "backend" independent
-- so it is "easy" to plug in an alternative renderer, the rendering model
is not really well suited to GPU rendering -- it would take a lot of
refactoring to really be able to take advantage of the graphics card.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE
<Google Maps;
  (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170914/faafcb0e/attachment.html&gt;

···

On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda < > f.faccenda86 at gmail.com> wrote:

On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda < >>> f.faccenda86 at gmail.com> wrote:

That was one of the old attempts (but not the oldest). It doesn't seem like
it ever intersected with the vispy project, though, so it is likely all
that exists.

I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
Luke does a nice job providing an overview of the vispy package. One of the
most exciting things that the matplotlib and vispy devs were discussing at
scipy 2015 was the possibility of making a matplotlib backend out of some
parts from vispy. It was attractive because the vispy folks were actively
working on improving their opengl code and packaging to make it work on a
wide variety of hardware and setups. They had supposedly even implemented a
headless opengl mode, too, which was very important for us.

Cheers!
Ben Root

···

On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:

Thank you, Ben.

unfortunately I don't have experience developing opengl neither, but I'd
like to make an attempt riesuming this subject.

I am starting from this: GitHub - ChrisBeaumont/mplgl: Investigating an OpenGL backend for Matplotlib

Can anyone confirm this is the last update we have for this project?

Francesco Faccenda

2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:

A bit of background regarding efforts in this area...

A long time ago, some experiments were done to see if an opengl backend
could be made for matplotlib. The results weren't that great, particularly
for text rendering, so the effort was dropped. The core developers all
agree that an opengl backend would be neat to have, but we all have
limited, if any, experience developing opengl. Furthermore, such a backend
would likely require a lot of rapid development and trial-n-error. So, we
encouraged others to go develop a package or two separately, with the eye
for bringing it back into matplotlib when it was ready. Glumpy and a few
other projects were born from that prodding.

VisPy was an attempt to consolidate the development efforts for those
projects. The matplotlib devs had very fruitful discussions with some VisPy
devs back at SciPy 2015, but the project became non-responsive shortly
afterwards.

Ben Root

On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda < >> f.faccenda86 at gmail.com> wrote:

Thank you Chris for your reply.

I have to admit I already stumbled on VisPy while doing my research on
the web. Still, I've got a lot of code already working with *matplotlib*.
Indeed, not only I plot data with it, but i manage a lot of *mpl events*
to provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
at the beginning few lines were managed and noone complained, now that big
amout of data has to be displayed, the non-GPU core of the library is
starting to show its limits.

Since matplotlib is a reference library for this kind of applications,
I thought it deserved an update in this direction. If anyone is willing to
do so, I'm available to discuss possible solutions and also provide any
help I can give.

Best regards,
Francesco Faccenda

2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:

On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda < >>>> f.faccenda86 at gmail.com> wrote:

But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
K40c), so I?d like to know if there is a way to make matplotlib run on it,
or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.

I tihnk you want VisPy:

https://vispy.readthedocs.io/en/latest/

It's a plotting package with a kinda like matplotlib API, built on
OpenGL.

Unfortunately, it doesn't look like it's been updated in a while --
from teh docs. But the gitHub project is active:

GitHub - vispy/vispy: Main repository for Vispy

So maybe it's only the docs that haven't been updated!

But probably a much better option than trying to shoehorn GPU
rendering into MPL.

The problem is that while MPL was designed to be "backend" independent
-- so it is "easy" to plug in an alternative renderer, the rendering model
is not really well suited to GPU rendering -- it would take a lot of
refactoring to really be able to take advantage of the graphics card.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE
<Google Maps;
  (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170914/9ef4dbe5/attachment-0001.html&gt;

I'll take a look, thank you.

So you are suggesting me to start form the VisPy code? Is there someone who
I can refer in case I will need some clarification?

Francesco Faccenda

2017-09-14 15:50 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:

That was one of the old attempts (but not the oldest). It doesn't seem
like it ever intersected with the vispy project, though, so it is likely
all that exists.

I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
Luke does a nice job providing an overview of the vispy package. One of
the most exciting things that the matplotlib and vispy devs were discussing
at scipy 2015 was the possibility of making a matplotlib backend out of
some parts from vispy. It was attractive because the vispy folks were
actively working on improving their opengl code and packaging to make it
work on a wide variety of hardware and setups. They had supposedly even
implemented a headless opengl mode, too, which was very important for us.

Cheers!
Ben Root

Thank you, Ben.

unfortunately I don't have experience developing opengl neither, but I'd
like to make an attempt riesuming this subject.

I am starting from this: GitHub - ChrisBeaumont/mplgl: Investigating an OpenGL backend for Matplotlib

Can anyone confirm this is the last update we have for this project?

Francesco Faccenda

2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:

A bit of background regarding efforts in this area...

A long time ago, some experiments were done to see if an opengl backend
could be made for matplotlib. The results weren't that great, particularly
for text rendering, so the effort was dropped. The core developers all
agree that an opengl backend would be neat to have, but we all have
limited, if any, experience developing opengl. Furthermore, such a backend
would likely require a lot of rapid development and trial-n-error. So, we
encouraged others to go develop a package or two separately, with the eye
for bringing it back into matplotlib when it was ready. Glumpy and a few
other projects were born from that prodding.

VisPy was an attempt to consolidate the development efforts for those
projects. The matplotlib devs had very fruitful discussions with some VisPy
devs back at SciPy 2015, but the project became non-responsive shortly
afterwards.

Ben Root

Thank you Chris for your reply.

I have to admit I already stumbled on VisPy while doing my research on
the web. Still, I've got a lot of code already working with
*matplotlib*. Indeed, not only I plot data with it, but i manage a lot
of *mpl events* to provide the users usefool tools, like lines
picking, tooltips, lines copy/paste, square selectors for multiple
selections, context menu and so on. Moreover, I got matplotlib *embedded
*on *wxpython *as well. While at the beginning few lines were managed
and noone complained, now that big amout of data has to be displayed, the
non-GPU core of the library is starting to show its limits.

Since matplotlib is a reference library for this kind of applications,
I thought it deserved an update in this direction. If anyone is willing to
do so, I'm available to discuss possible solutions and also provide any
help I can give.

Best regards,
Francesco Faccenda

2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:

But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
K40c), so I?d like to know if there is a way to make matplotlib run on it,
or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.

I tihnk you want VisPy:

https://vispy.readthedocs.io/en/latest/

It's a plotting package with a kinda like matplotlib API, built on
OpenGL.

Unfortunately, it doesn't look like it's been updated in a while --
from teh docs. But the gitHub project is active:

GitHub - vispy/vispy: Main repository for Vispy

So maybe it's only the docs that haven't been updated!

But probably a much better option than trying to shoehorn GPU
rendering into MPL.

The problem is that while MPL was designed to be "backend" independent
-- so it is "easy" to plug in an alternative renderer, the rendering model
is not really well suited to GPU rendering -- it would take a lot of
refactoring to really be able to take advantage of the graphics card.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE
<Google Maps;
  (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170914/c5c732e1/attachment.html&gt;

···

On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda < > f.faccenda86 at gmail.com> wrote:

On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda < >>> f.faccenda86 at gmail.com> wrote:

On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda < >>>>> f.faccenda86 at gmail.com> wrote:

The person who has been most responsive to me in the past would be Nicolas
Rougier <http://www.loria.fr/~rougier/index.html&gt;, who developed glumpy.
He might also be able to give you a better sense of where to start.

Ben Root

···

On Thu, Sep 14, 2017 at 10:37 AM, Francesco Faccenda <f.faccenda86 at gmail.com > wrote:

I'll take a look, thank you.

So you are suggesting me to start form the VisPy code? Is there someone
who I can refer in case I will need some clarification?

Francesco Faccenda

2017-09-14 15:50 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:

That was one of the old attempts (but not the oldest). It doesn't seem
like it ever intersected with the vispy project, though, so it is likely
all that exists.

I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
Luke does a nice job providing an overview of the vispy package. One of
the most exciting things that the matplotlib and vispy devs were discussing
at scipy 2015 was the possibility of making a matplotlib backend out of
some parts from vispy. It was attractive because the vispy folks were
actively working on improving their opengl code and packaging to make it
work on a wide variety of hardware and setups. They had supposedly even
implemented a headless opengl mode, too, which was very important for us.

Cheers!
Ben Root

On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda < >> f.faccenda86 at gmail.com> wrote:

Thank you, Ben.

unfortunately I don't have experience developing opengl neither, but I'd
like to make an attempt riesuming this subject.

I am starting from this: GitHub - ChrisBeaumont/mplgl: Investigating an OpenGL backend for Matplotlib

Can anyone confirm this is the last update we have for this project?

Francesco Faccenda

2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:

A bit of background regarding efforts in this area...

A long time ago, some experiments were done to see if an opengl backend
could be made for matplotlib. The results weren't that great, particularly
for text rendering, so the effort was dropped. The core developers all
agree that an opengl backend would be neat to have, but we all have
limited, if any, experience developing opengl. Furthermore, such a backend
would likely require a lot of rapid development and trial-n-error. So, we
encouraged others to go develop a package or two separately, with the eye
for bringing it back into matplotlib when it was ready. Glumpy and a few
other projects were born from that prodding.

VisPy was an attempt to consolidate the development efforts for those
projects. The matplotlib devs had very fruitful discussions with some VisPy
devs back at SciPy 2015, but the project became non-responsive shortly
afterwards.

Ben Root

On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda < >>>> f.faccenda86 at gmail.com> wrote:

Thank you Chris for your reply.

I have to admit I already stumbled on VisPy while doing my research on
the web. Still, I've got a lot of code already working with
*matplotlib*. Indeed, not only I plot data with it, but i manage a
lot of *mpl events* to provide the users usefool tools, like lines
picking, tooltips, lines copy/paste, square selectors for multiple
selections, context menu and so on. Moreover, I got matplotlib *embedded
*on *wxpython *as well. While at the beginning few lines were managed
and noone complained, now that big amout of data has to be displayed, the
non-GPU core of the library is starting to show its limits.

Since matplotlib is a reference library for this kind of
applications, I thought it deserved an update in this direction. If anyone
is willing to do so, I'm available to discuss possible solutions and also
provide any help I can give.

Best regards,
Francesco Faccenda

2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:

On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda < >>>>>> f.faccenda86 at gmail.com> wrote:

But there?s a good news, I have a nice GPU available (an NVIDIA
Tesla K40c), so I?d like to know if there is a way to make matplotlib run
on it, or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.

I tihnk you want VisPy:

https://vispy.readthedocs.io/en/latest/

It's a plotting package with a kinda like matplotlib API, built on
OpenGL.

Unfortunately, it doesn't look like it's been updated in a while --
from teh docs. But the gitHub project is active:

GitHub - vispy/vispy: Main repository for Vispy

So maybe it's only the docs that haven't been updated!

But probably a much better option than trying to shoehorn GPU
rendering into MPL.

The problem is that while MPL was designed to be "backend"
independent -- so it is "easy" to plug in an alternative renderer, the
rendering model is not really well suited to GPU rendering -- it would take
a lot of refactoring to really be able to take advantage of the graphics
card.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE
<Google Maps;
  (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170914/c372b2f7/attachment-0001.html&gt;

As as matter of fact, I?m currently writing a (open access) book about Python, OpenGL and scientific visualization that explains pretty much everything. I hope to be able to release by the end of the year.

Concerning Vispy, the code might be a bit hard to handle at first but the project is still alive with new contributors.
Concerning glumpy, I still maintain it and it is less complex than Vispy but it does not offer the high-level interface of vispy. I usually make the comparison numpy/scipy and glumpy/vispy. But the two projects are independent (even if I transferred a lot of code from glumpy to vispy).

For a starter on OpenGL, you can have a look at glumpy documentation: Glumpy documentation — glumpy v1.x documentation

Nicolas

···

On 14 Sep 2017, at 16:47, Benjamin Root <ben.v.root at gmail.com> wrote:

The person who has been most responsive to me in the past would be Nicolas Rougier, who developed glumpy. He might also be able to give you a better sense of where to start.

Ben Root

On Thu, Sep 14, 2017 at 10:37 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:
I'll take a look, thank you.

So you are suggesting me to start form the VisPy code? Is there someone who I can refer in case I will need some clarification?

Francesco Faccenda

2017-09-14 15:50 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
That was one of the old attempts (but not the oldest). It doesn't seem like it ever intersected with the vispy project, though, so it is likely all that exists.

I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
Luke does a nice job providing an overview of the vispy package. One of the most exciting things that the matplotlib and vispy devs were discussing at scipy 2015 was the possibility of making a matplotlib backend out of some parts from vispy. It was attractive because the vispy folks were actively working on improving their opengl code and packaging to make it work on a wide variety of hardware and setups. They had supposedly even implemented a headless opengl mode, too, which was very important for us.

Cheers!
Ben Root

On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:
Thank you, Ben.

unfortunately I don't have experience developing opengl neither, but I'd like to make an attempt riesuming this subject.

I am starting from this: GitHub - ChrisBeaumont/mplgl: Investigating an OpenGL backend for Matplotlib

Can anyone confirm this is the last update we have for this project?

Francesco Faccenda

2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
A bit of background regarding efforts in this area...

A long time ago, some experiments were done to see if an opengl backend could be made for matplotlib. The results weren't that great, particularly for text rendering, so the effort was dropped. The core developers all agree that an opengl backend would be neat to have, but we all have limited, if any, experience developing opengl. Furthermore, such a backend would likely require a lot of rapid development and trial-n-error. So, we encouraged others to go develop a package or two separately, with the eye for bringing it back into matplotlib when it was ready. Glumpy and a few other projects were born from that prodding.

VisPy was an attempt to consolidate the development efforts for those projects. The matplotlib devs had very fruitful discussions with some VisPy devs back at SciPy 2015, but the project became non-responsive shortly afterwards.

Ben Root

On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:
Thank you Chris for your reply.

I have to admit I already stumbled on VisPy while doing my research on the web. Still, I've got a lot of code already working with matplotlib. Indeed, not only I plot data with it, but i manage a lot of mpl events to provide the users usefool tools, like lines picking, tooltips, lines copy/paste, square selectors for multiple selections, context menu and so on. Moreover, I got matplotlib embedded on wxpython as well. While at the beginning few lines were managed and noone complained, now that big amout of data has to be displayed, the non-GPU core of the library is starting to show its limits.

Since matplotlib is a reference library for this kind of applications, I thought it deserved an update in this direction. If anyone is willing to do so, I'm available to discuss possible solutions and also provide any help I can give.

Best regards,
Francesco Faccenda

2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:
But there?s a good news, I have a nice GPU available (an NVIDIA Tesla K40c), so I?d like to know if there is a way to make matplotlib run on it, or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.

I tihnk you want VisPy:

https://vispy.readthedocs.io/en/latest/

It's a plotting package with a kinda like matplotlib API, built on OpenGL.

Unfortunately, it doesn't look like it's been updated in a while -- from teh docs. But the gitHub project is active:

GitHub - vispy/vispy: Main repository for Vispy

So maybe it's only the docs that haven't been updated!

But probably a much better option than trying to shoehorn GPU rendering into MPL.

The problem is that while MPL was designed to be "backend" independent -- so it is "easy" to plug in an alternative renderer, the rendering model is not really well suited to GPU rendering -- it would take a lot of refactoring to really be able to take advantage of the graphics card.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

One possibility for which I'd certainly appreciate some help is to see
whether we can use cairo's gl backend (which is sadly quite
underdocumented) in GitHub - matplotlib/mplcairo: A (new) cairo backend for Matplotlib. -- which can
currently use cairo's raster ("image") and X11 backends, with pretty good
performance (much better than the builtin gtk3cairo, and generally better
than the builtin Agg backends).
Antony

2017-09-14 8:03 GMT-07:00 Nicolas Rougier <Nicolas.Rougier at inria.fr>:

As as matter of fact, I?m currently writing a (open access) book about
Python, OpenGL and scientific visualization that explains pretty much
everything. I hope to be able to release by the end of the year.

Concerning Vispy, the code might be a bit hard to handle at first but the
project is still alive with new contributors.
Concerning glumpy, I still maintain it and it is less complex than Vispy
but it does not offer the high-level interface of vispy. I usually make the
comparison numpy/scipy and glumpy/vispy. But the two projects are
independent (even if I transferred a lot of code from glumpy to vispy).

For a starter on OpenGL, you can have a look at glumpy documentation:
Glumpy documentation — glumpy v1.x documentation

Nicolas

>
> The person who has been most responsive to me in the past would be
Nicolas Rougier, who developed glumpy. He might also be able to give you a
better sense of where to start.
>
> Ben Root
>
> I'll take a look, thank you.
>
> So you are suggesting me to start form the VisPy code? Is there someone
who I can refer in case I will need some clarification?
>
> Francesco Faccenda
>
> 2017-09-14 15:50 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
> That was one of the old attempts (but not the oldest). It doesn't seem
like it ever intersected with the vispy project, though, so it is likely
all that exists.
>
> I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
> Luke does a nice job providing an overview of the vispy package. One of
the most exciting things that the matplotlib and vispy devs were discussing
at scipy 2015 was the possibility of making a matplotlib backend out of
some parts from vispy. It was attractive because the vispy folks were
actively working on improving their opengl code and packaging to make it
work on a wide variety of hardware and setups. They had supposedly even
implemented a headless opengl mode, too, which was very important for us.
>
> Cheers!
> Ben Root
>
>
> Thank you, Ben.
>
> unfortunately I don't have experience developing opengl neither, but I'd
like to make an attempt riesuming this subject.
>
> I am starting from this: GitHub - ChrisBeaumont/mplgl: Investigating an OpenGL backend for Matplotlib
>
> Can anyone confirm this is the last update we have for this project?
>
> Francesco Faccenda
>
> 2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
> A bit of background regarding efforts in this area...
>
> A long time ago, some experiments were done to see if an opengl backend
could be made for matplotlib. The results weren't that great, particularly
for text rendering, so the effort was dropped. The core developers all
agree that an opengl backend would be neat to have, but we all have
limited, if any, experience developing opengl. Furthermore, such a backend
would likely require a lot of rapid development and trial-n-error. So, we
encouraged others to go develop a package or two separately, with the eye
for bringing it back into matplotlib when it was ready. Glumpy and a few
other projects were born from that prodding.
>
> VisPy was an attempt to consolidate the development efforts for those
projects. The matplotlib devs had very fruitful discussions with some VisPy
devs back at SciPy 2015, but the project became non-responsive shortly
afterwards.
>
> Ben Root
>
>
> Thank you Chris for your reply.
>
> I have to admit I already stumbled on VisPy while doing my research on
the web. Still, I've got a lot of code already working with matplotlib.
Indeed, not only I plot data with it, but i manage a lot of mpl events to
provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib embedded on wxpython as well. While at the
beginning few lines were managed and noone complained, now that big amout
of data has to be displayed, the non-GPU core of the library is starting to
show its limits.
>
> Since matplotlib is a reference library for this kind of applications,
I thought it deserved an update in this direction. If anyone is willing to
do so, I'm available to discuss possible solutions and also provide any
help I can give.
>
> Best regards,
> Francesco Faccenda
>
> 2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
> But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
K40c), so I?d like to know if there is a way to make matplotlib run on it,
or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>
>
> I tihnk you want VisPy:
>
> https://vispy.readthedocs.io/en/latest/
>
> It's a plotting package with a kinda like matplotlib API, built on
OpenGL.
>
> Unfortunately, it doesn't look like it's been updated in a while -- from
teh docs. But the gitHub project is active:
>
> GitHub - vispy/vispy: Main repository for Vispy
>
> So maybe it's only the docs that haven't been updated!
>
> But probably a much better option than trying to shoehorn GPU rendering
into MPL.
>
> The problem is that while MPL was designed to be "backend" independent
-- so it is "easy" to plug in an alternative renderer, the rendering model
is not really well suited to GPU rendering -- it would take a lot of
refactoring to really be able to take advantage of the graphics card.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris.Barker at noaa.gov
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> Matplotlib-devel Info Page
>
>
>
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170914/6ba397d6/attachment.html&gt;

···

> On 14 Sep 2017, at 16:47, Benjamin Root <ben.v.root at gmail.com> wrote:
> On Thu, Sep 14, 2017 at 10:37 AM, Francesco Faccenda < > f.faccenda86 at gmail.com> wrote:
> On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda < > f.faccenda86 at gmail.com> wrote:
> On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda < > f.faccenda86 at gmail.com> wrote:
> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda < > f.faccenda86 at gmail.com> wrote:

I have to admit I already stumbled on VisPy while doing my research on the
web. Still, I've got a lot of code already working with *matplotlib*.
Indeed, not only I plot data with it, but i manage a lot of *mpl events*
to provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
the beginning few lines were managed and noone complained, now that big
amout of data has to be displayed, the non-GPU core of the library is
starting to show its limits.

Since matplotlib is a reference library for this kind of applications, I
thought it deserved an update in this direction.

Well, As I understand it, VisPY made some effort to be compatible with the
MPL API -- but that is going to depend on how much you use the lower-level
parts f the API -- things like the transform, etc. to take advantage of GPU
rendering, all the transforms, etc needs to be pushed to the GPU, so the
architecture (and API) needs to be quite different.

If anyone is willing to do so, I'm available to discuss possible solutions
and also provide any help I can give.

As Ben pointed out, and I was trying to make clear -- it really isn't a
matter of "just" writing an OpenGL backend -- there really needs to be a
major restructuring.

And VisPy is pretty much that project. Whether it is feature complete,
robust and maintained enough for your use-cases, I have no idea, but even
if not -- you'll probably be better off contributing to that effort than
starting all over with trying to make an GPU_based OPenGL back-end.

However -- maybe there is another option:

Taking full advantage of GPUs does require a full restructuring, but maybe
there are other ways to get better performance -- for instance, optimizing
the transform code, etc:

Using the GPU with PyCuda or [what the heck is the name of the more general
GPU-using lib??]

using numba

Maybe there is still room for Cython, etc....

In short, profiling MPL carefully, to see where the performance bottlenecks
are:

With modern hardware, actually rendering stuff is no longer the slow part
of visualization. Rather, it's pushing data to the renderer, transforming
data etc.

This is why to take advantage of the GPU, you need to do the
transformations, etc on the GPU -- which the MPL architecture doesn't make
easy by dropping in a new back-end.

Which is why VisPy built a new architecture from the bottom up.

-CHB

···

On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda <f.faccenda86 at gmail.com > wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170921/157481ca/attachment.html&gt;

Depending on the exact use case you can get pretty good mileage out of
blitting (See http://matplotlib.org/api/animation_api.html#funcanimation for
an explanation or how it is used in the widgets module).

The best way to make things faster is to just do less work :slight_smile:

Tom

···

On Thu, Sep 21, 2017 at 5:14 PM Chris Barker <chris.barker at noaa.gov> wrote:

On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda < > f.faccenda86 at gmail.com> wrote:

I have to admit I already stumbled on VisPy while doing my research on
the web. Still, I've got a lot of code already working with *matplotlib*.
Indeed, not only I plot data with it, but i manage a lot of *mpl events*
to provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
at the beginning few lines were managed and noone complained, now that big
amout of data has to be displayed, the non-GPU core of the library is
starting to show its limits.

Since matplotlib is a reference library for this kind of applications, I
thought it deserved an update in this direction.

Well, As I understand it, VisPY made some effort to be compatible with the
MPL API -- but that is going to depend on how much you use the lower-level
parts f the API -- things like the transform, etc. to take advantage of GPU
rendering, all the transforms, etc needs to be pushed to the GPU, so the
architecture (and API) needs to be quite different.

If anyone is willing to do so, I'm available to discuss possible
solutions and also provide any help I can give.

As Ben pointed out, and I was trying to make clear -- it really isn't a
matter of "just" writing an OpenGL backend -- there really needs to be a
major restructuring.

And VisPy is pretty much that project. Whether it is feature complete,
robust and maintained enough for your use-cases, I have no idea, but even
if not -- you'll probably be better off contributing to that effort than
starting all over with trying to make an GPU_based OPenGL back-end.

However -- maybe there is another option:

Taking full advantage of GPUs does require a full restructuring, but maybe
there are other ways to get better performance -- for instance, optimizing
the transform code, etc:

Using the GPU with PyCuda or [what the heck is the name of the more
general GPU-using lib??]

using numba

Maybe there is still room for Cython, etc....

In short, profiling MPL carefully, to see where the performance
bottlenecks are:

With modern hardware, actually rendering stuff is no longer the slow part
of visualization. Rather, it's pushing data to the renderer, transforming
data etc.

This is why to take advantage of the GPU, you need to do the
transformations, etc on the GPU -- which the MPL architecture doesn't make
easy by dropping in a new back-end.

Which is why VisPy built a new architecture from the bottom up.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at lists.sourceforge.net
matplotlib-devel List Signup and Options

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170922/e0aa10c5/attachment-0001.html&gt;