On Mon, May 19, 2014 at 11:43 PM, Anthony Cowley wrote:

...

On May 20, 2014, at 12:20 AM, Michael Baker wrote:

I'm using OpenGLRaw and I'm getting 3 frames per second trying to draw 8000 triangles. When I profile the application, I see that almost all of the time is taken by a call to CGLFlushDrawable, which is apparently OSX's function for swapping the back buffer to the front buffer.

Can you put the code somewhere so we can take a look? OpenGL offers 8000 ways to draw 8000 triangles.

Anthony

...

Has anyone else run into a problem like this? I seem to recall a thread

a while ago about a Haskell specific OpenGL performance issue, but I can't find it now.

...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Here's the code https://gist.github.com/MichaelBaker/4429c93f2aca04bc79bb. I think I have everything important in there. Line 53 is the one that causes the slow down. I guess some things to note are that "Triangle" is Storable and the vector I'm creating on line 14 and writing to on line 47 is a mutable storable vector. Also, thanks Alp, I'll look into this when I get home. Although I don't think my computer has more than one graphics card (it's a Macbook Air).

On May 20, 2014, at 11:36 AM, Michael Baker wrote:

...

On Mon, May 19, 2014 at 11:43 PM, Anthony Cowley wrote:

...

On May 20, 2014, at 12:20 AM, Michael Baker wrote:

I'm using OpenGLRaw and I'm getting 3 frames per second trying to draw 8000 triangles. When I profile the application, I see that almost all of the time is taken by a call to CGLFlushDrawable, which is apparently OSX's function for swapping the back buffer to the front buffer.

Can you put the code somewhere so we can take a look? OpenGL offers 8000 ways to draw 8000 triangles.

Anthony

...

Has anyone else run into a problem like this? I seem to recall a thread a while ago about a Haskell specific OpenGL performance issue, but I can't find it now. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Here's the code https://gist.github.com/MichaelBaker/4429c93f2aca04bc79bb. I think I have everything important in there. Line 53 is the one that causes the slow down. I guess some things to note are that "Triangle" is Storable and the vector I'm creating on line 14 and writing to on line 47 is a mutable storable vector.

I would avoid setting the buffer data every frame like this. You should create your VBO once, then map it, update the data, and unmap it every frame if all your geometry really does change every frame. Don't use a list for your geometry if you can avoid it. Consider using VAOs to keep track of enabled attributes, etc. Unsurprisingly, I'd recommend taking a look at the vinyl-gl tutorial for most of those considerations, though I don't think I say anything about mapping buffers there. Anthony

Also, thanks Alp, I'll look into this when I get home. Although I don't think my computer has more than one graphics card (it's a Macbook Air).

On Wed, May 21, 2014 at 6:53 PM, Michael Baker wrote:

I've added a VAO and reduced the inner loop to only a call to glDrawArrays which renders 8000 triangles (24000 vertices). The gameFrame function now benchmarks at ~86ms on my machine. I would expect it to be ~16ms because of vsync. I've pared down the entire project into this buildable cabal project of three files, most of which is OpenGL boilerplate: https://github.com/MichaelBaker/haskell-opengl.

Awesome. Thanks! I'm taking a look now. I'll let you know if I figure out anything. Jason

On May 21, 2014, at 9:53 PM, Michael Baker wrote:

I've added a VAO and reduced the inner loop to only a call to glDrawArrays which renders 8000 triangles (24000 vertices). The gameFrame function now benchmarks at ~86ms on my machine. I would expect it to be ~16ms because of vsync. I've pared down the entire project into this buildable cabal project of three files, most of which is OpenGL boilerplate: https://github.com/MichaelBaker/haskell-opengl. Running it benchmarks the problem area. For what it's worth, I also tried using glBufferSubData to update the vertex data, but that had no effect.

As a side note, vinyl-gl looks like a nice library. I'll definitely look into using it if I can ever get this basic example working.

That's some pretty serious antialiasing you're asking for, there (16x). Is that intentional? Anthony

Em 21-05-2014 22:53, Michael Baker escreveu:

I've added a VAO and reduced the inner loop to only a call to glDrawArrays which renders 8000 triangles (24000 vertices). The gameFrame function now benchmarks at ~86ms on my machine. I would expect it to be ~16ms because of vsync. I've pared down the entire project into this buildable cabal project of three files, most of which is OpenGL boilerplate: https://github.com/MichaelBaker/haskell-opengl. Running it benchmarks the problem area. For what it's worth, I also tried using glBufferSubData to update the vertex data, but that had no effect.

Your program is segfaulting for me on Linux: $ cabal clean $ cabal configure --disable-executable-stripping --ghc-option=-debug [...] $ cabal build [...] $ LC_ALL=C valgrind ./dist/build/opengl/opengl ==21335== Memcheck, a memory error detector ==21335== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==21335== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==21335== Command: ./dist/build/opengl/opengl ==21335== warming up estimating clock resolution... mean is 38.15961 us (20001 iterations) found 583 outliers among 19999 samples (2.9%) 328 (1.6%) high mild 254 (1.3%) high severe estimating cost of a clock call... mean is 1.177577 us (66 iterations) found 3 outliers among 66 samples (4.5%) 2 (3.0%) high mild 1 (1.5%) high severe benchmarking gameFrame ==21335== Invalid read of size 8 ==21335== at 0x4C2CB30: memcpy@GLIBC_2.2.5 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==21335== by 0x5C1E1A4: ??? (in /usr/lib/nvidia/libGL.so.337.19) ==21335== by 0x5DC2: ??? ==21335== by 0xFF2FFFFFFFF: ??? ==21335== by 0xFEF: ??? ==21335== by 0xFEF: ??? ==21335== by 0xAC4285F: ??? ==21335== by 0x5EF4BB5: _XSend (in /usr/lib/libX11.so.6.3.0) ==21335== by 0xAE456DF: ??? ==21335== by 0xAE460A7: ??? ==21335== by 0x5DC2F: ??? ==21335== by 0xAE455EF: ??? ==21335== Address 0xfe8 is not stack'd, malloc'd or (recently) free'd ==21335== ==21335== ==21335== Process terminating with default action of signal 11 (SIGSEGV) ==21335== Access not within mapped region at address 0xFE8 ==21335== at 0x4C2CB30: memcpy@GLIBC_2.2.5 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==21335== by 0x5C1E1A4: ??? (in /usr/lib/nvidia/libGL.so.337.19) ==21335== by 0x5DC2: ??? ==21335== by 0xFF2FFFFFFFF: ??? ==21335== by 0xFEF: ??? ==21335== by 0xFEF: ??? ==21335== by 0xAC4285F: ??? ==21335== by 0x5EF4BB5: _XSend (in /usr/lib/libX11.so.6.3.0) ==21335== by 0xAE456DF: ??? ==21335== by 0xAE460A7: ??? ==21335== by 0x5DC2F: ??? ==21335== by 0xAE455EF: ??? ==21335== If you believe this happened as a result of a stack ==21335== overflow in your program's main thread (unlikely but ==21335== possible), you can try to increase the size of the ==21335== main thread stack using the --main-stacksize= flag. ==21335== The main thread stack size used in this run was 8388608. ==21335== ==21335== HEAP SUMMARY: ==21335== in use at exit: 1,222,944 bytes in 665 blocks ==21335== total heap usage: 5,445 allocs, 4,780 frees, 78,290,922 bytes allocated ==21335== ==21335== LEAK SUMMARY: ==21335== definitely lost: 10,752 bytes in 12 blocks ==21335== indirectly lost: 0 bytes in 0 blocks ==21335== possibly lost: 519,934 bytes in 2 blocks ==21335== still reachable: 692,258 bytes in 651 blocks ==21335== suppressed: 0 bytes in 0 blocks ==21335== Rerun with --leak-check=full to see details of leaked memory ==21335== ==21335== For counts of detected and suppressed errors, rerun with: -v ==21335== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 2) Falha de segmentação (imagem do núcleo gravada) $ gdb ./dist/build/opengl/opengl GNU gdb (GDB) 7.7.1 [...] Reading symbols from ./dist/build/opengl/opengl...(no debugging symbols found)...done. (gdb) run Starting program: /tmp/haskell-opengl/dist/build/opengl/opengl warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". warming up estimating clock resolution... mean is 1.346329 us (640001 iterations) found 4071 outliers among 639999 samples (0.6%) 3860 (0.6%) high severe estimating cost of a clock call... mean is 81.51352 ns (10 iterations) found 1 outliers among 10 samples (10.0%) 1 (10.0%) high mild benchmarking gameFrame Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5c5ece0 in _wordcopy_fwd_aligned () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff5c5ece0 in _wordcopy_fwd_aligned () from /usr/lib/libc.so.6 #1 0x00007ffff5c595f5 in __memmove_sse2 () from /usr/lib/libc.so.6 #2 0x00007ffff6dff1a5 in ?? () from /usr/lib/libGL.so.1 #3 0x00007ffff6e01ada in ?? () from /usr/lib/libGL.so.1 #4 0x0000000000407b91 in ceGc_info () #5 0x0000000000000000 in ?? () Cheers, -- Felipe.

You're expecting too much from your graphics hardware. The total area of the triangles that you are drawing covers approximately 80 million pixels (they overlap a lot). If one uses non-overlapping triangles (with a total area close to 60k pixels)

Ah, ok. So the problem is that I'm trying to render too many fragments, rather than too many triangles. So if I had a lot of small triangles, or a few big ones, I would be fine. However, I've got a lot of big ones, which is slow. I'll try reducing the total area of the triangles I'm rendering. Is there some benchmark or tool I could have used to figure that out? Something that would show me the time spent filling fragments vs the time spent processing triangles vs time spent uploading data to the graphics card?

For the sake of posterity I want to let everyone know that decreasing the anti-aliasing samples and decreasing the total visible area being rendered solved the problem. Thank you everyone for your help!