VertexArray::draw performance

[korczurekk]

Hi,
Before explaining the actual issue I'd like to point out that I'm actually using D and dsfml instead of raw C++/SFML, but because dsfml is basically a 1:1 wrapper of SFML, I assume the problem that I face to actually emerge from SFML.

I'm drawing a VertexArray with 4.2 billion vertices and it takes… well, a lot of time. Sadly I can't just render it to a RenderTexture once and then draw the result on screen as constant zooming in and out forces me to actually re-render the array.

I did some profiling and found out that the function that takes the most of CPU time is __memcpy_avx_unaligned_erms and basically all of the time it takes is when it's called by copy_array_to_vbo_array.isra.0 from i965_dri.so shared object (.dll but on Linux). I took a quick look at SFML source and saw that it copies the array to GPU on every single drawcall, even if the contents of VertexArray haven't been modified, which is understandable as there may be references to VertexArray's elements that it has no knowledge of, so it has to assume that they have indeed changed to always produce correct results.

Is there some known way to address this issue and keep vertices on GPU that doesn't involve messing with OpenGL? Never bothered to learn it, sadly. If there isn't, what do you think about adding some function like VertexArray::prepare_draw(RenderWindow&, RenderStates) that would copy all the needed data to GPU and prepare a reusable drawable object that wouldn't need to copy anything around?

Thanks for your time,
Kamil

[korczurekk]

Okay, problem solved, hopefully.

I completely overlooked the existence of sf::VertexBuffer, which seems to be a relatively recent addition to SFML and do exactly what I want. While I don't know if it will indeed solve my problem, the premise of my question has become irrelevant. I'll rewrite my code and check its performance then.

[eXpl0it3r]

Did you ever just sit back and think about what you're trying to do here?

Let's say you have a HD display 1920x1080, that makes for ~2mil pixels.
Or maybe you have a 4K screen 4096x2160, that makes for ~8.8mil pixels.

And now you want to draw 4.2 billion vertices (notice this is not pixels, but geometry)?
You know that's somewhere in the realms of 84GB of RAM?
And then you want this to all be rendered by a Intel 965G chip?

Or maybe you just wrote something random?

[korczurekk]

It's a curve* densely packed in a square 600x600 with the top-left corner at (0, 0). When rendered with the default view it simply fills entire window with it, but the point is that you can zoom in to see how exactly it behaves in a given place.

I obviously can't pre-render it for reasons that you described. Oh, and I tested it, works fine with sf::VertexBuffer. It's not that much better, but enough.

*Hilbert's curve to be precise. I'm testing how well it maps pairs (x, y) to a single real number and parametric equations describing its shape are surprisingly hard to grasp and even harder to use when you want to check some kinds of properties. A graph like this one helps a lot when you're analyzing this kind of stuff.

//edit: And the GPU… well, it's kind of embarrassing to say this, but I'd feel defeated if I switched the dedicated NVidia card just because Intel couldn't do the job. 

//edit2: And yeah, 4.2 billion seems like a lot now, looks like I'm bad at copying stuff into my calculator. Turns out to be about 67 million.