> MapD uses Vega to drive the rendering engine directly on the result set of a SQL query without ever requiring the data to leave the GPU
How big is the dataset? If it can't ever leave the GPU then it is at most a few GB? Unless there are several GPUs at play then it's N * (a few GB). If there are a few GPUs at play then this dataset would fit into DDR3 RAM on a single mainstream Xeon node, or entirely into MCDRAM on a Xeon Phi node.
MapD customers typically run our product on multiple servers with multiple GPUs per node. So 4 servers with 8 Nvidia P40s each has 4X192GB = 768GB of VRAM. Note MapD compresses data and also keeps data in CPU RAM as needed. Even two servers with these GPUs or 4 servers with gamer GPUs is enough to query and visualize an 11B record shipping dataset without a hitch (https://www.mapd.com/demos/ships), a demo running on four servers with 8 Nvidia 1080 Tis each.
Other customers with smaller datasets (i.e. less than a few hundred million records) are able to run with a single GPU.
We're not going after petabyte size datasets (where <100ms querying is rarely important), so ability to scale has rarely been an issue.
I would love to see some comparisons to other mpp in memory databases as, and I mean this with all due respect, it's difficult to gauge what the impact of GPUs are. Have you benchmarked against anything like Memsql? Also, do you mind if I ask where you got the ship data from?
Note that although we can run on CPU, CPUs do not have the graphics pipeline and the memory bandwidth necessary for interactive server-side visualizations like this.
I'm making $86 an hour working from home. I was shocked when my neighbour told me she was averaging $95 but I see how it works now. I feel so much freedom now that I'm my own boss. This is what I do, ===http://www.millionaireprofit.cf/
- ( 3 ) -
Do you use Pascal's unified memory for over-provisioning?
Since Maxwell only supports unified virtual memory addresses with the host upto the VRAM limit.
MapD predates good virtual (unified) memory support on GPUs and so we built our own caching mechanism where each GPU has its own buffer pool and pulls from a CPU buffer pool (i.e a network of buffer pools). This approach still has the advantage of giving us a lot of control of where we put data, how much we leave for other processes, as well as allowing us to pin data in VRAM on a specific GPU.
AMD are working[1][2] on a graphics card that includes a 1TB SSD, which appears to your application as having 1TB of RAM and then just swaps to the SSD. I would say that's a pretty good approach to enabling virtual memory on the GPU - you get really fast swapping and you don't tax the PCI bus and CPU with moving data to and from GPU RAM. No release date AFAIK sadly.
@tmostak large dataset visualisation like this looks great, but one of the most appealing parts of Vega for me is interaction. It's just as easy with Vega to create composite interactions for filtering and navigating data as it is to visualise it. Is there any scope for this type of architecture to support more than just serving rendered PNGs? (Can it do that at 60fps? :P)
We've considered video rendering using the H264 encoders on the GPU, another approach might be to create a format that has all info needed for interactions and that could be deciphered on the frontend (i.e in WebGL). So it's something we're definitely looking at.
We already do provide some support for hover interactions in our charting library on top of Vega, but it would be nicer to do this in Vega.
Right now customers still get a lot of value from server-side rendering simply bc we can render visualizations of billions of records interactively and in real time, which is difficult or impossible to achieve in other platforms without some sort of
pre-computation.
Thanks for your reply, and yes I can imagine your tools are already very useful. Are there any examples of real-time online? It would be interesting to see what your SoTA is!
We do support real-time ingest (helped by the fact that we do not need to index on insert). The only example we have online of that now is our Tweetmap demo (https://www.mapd.com/demos/tweetmap/)
We separated the analytics from rendering at Graphistry, connecting GPUs on both ends. You'll notice most of their visualizations aren't showing much geometry in the client: Leveraging that, we aim for 15fps+ on datasets 100X+ bigger than normal stuff in browsers, and soon, even more. And we're looking into including MapD as part of our backend GPU analytics stack... so, yes!
And if you're into visualization engineering like that, we're hiring :)
A lot of these visualisations would benefit greatly by using 2d or 3d kernel density estimates instead of a simple scatter plot. See for example: https://youtu.be/Xz_7Ej6JsMY
How big is the dataset? If it can't ever leave the GPU then it is at most a few GB? Unless there are several GPUs at play then it's N * (a few GB). If there are a few GPUs at play then this dataset would fit into DDR3 RAM on a single mainstream Xeon node, or entirely into MCDRAM on a Xeon Phi node.
Please correct me if I'm wrong.
Other customers with smaller datasets (i.e. less than a few hundred million records) are able to run with a single GPU.
We're not going after petabyte size datasets (where <100ms querying is rarely important), so ability to scale has rarely been an issue.
[1] https://www.amd.com/en-us/press-releases/Pages/amd-radeon-pr...
[2] https://www.youtube.com/watch?v=g-8pMM2wV7k
We already do provide some support for hover interactions in our charting library on top of Vega, but it would be nicer to do this in Vega.
Right now customers still get a lot of value from server-side rendering simply bc we can render visualizations of billions of records interactively and in real time, which is difficult or impossible to achieve in other platforms without some sort of pre-computation.
And if you're into visualization engineering like that, we're hiring :)