On 15/04/17 05:08 PM, gregory hainaut wrote: > On Sat, 15 Apr 2017 00:50:15 +0200 > Dieter Nützel <die...@nuetzel-hh.de> wrote: > >> Am 14.04.2017 07:53, schrieb gregory hainaut: >>> On Fri, 14 Apr 2017 05:20:38 +0200 >>> Dieter Nützel <die...@nuetzel-hh.de> wrote: >>> >>>> Am 14.04.2017 02:06, schrieb Dieter Nützel: >>>>> Hello Gregory, >>>>> >>>>> have you tested this with Mesa-demos/tests/pbo 'b' (benchmark)? >>>>> It result in crazy numbers and do not 'return' (one core stays @ 100%). >>>> >>>> This is related to 'mesa_glthread=true'. >>>> If I disable (unset) it, all is fine after 'b' benchmark and 'pbo' >>>> exit >>>> with ESC as expeted. >>>> Crazy numbers stay, maybe counter overrun due to BIG numbers? ;-) >>>> >>>> Hope that helps. >>>> >>>> Dieter >>> >>> Hello Dieter, >>> >>> I tested the demo. There is a pseudo unrelated bug on the exit of the >>> application. >>> >>> Mesa 17.1.0-devel implementation error: In _mesa_DeleteHashTable, >>> found non-freed data >>> >>> I will add a call to a _mesa_HashDeleteAll to fix it. >>> i.e. _mesa_HashDeleteAll(shared->ShadowBufferObjects, dummy_cb, ctx); >>> >>> Now let's go back to the test behavior. The benchmarks will send 4s of >>> asynchronous PBO transfer commands. And then will sync gl_thread which >>> mean the application thread will be blocked until all PBO transfers are >>> done. Gl_thread is faster to dispatch command so you will need to wait >>> more before the thread goes back to real life. >>> >>> On my side, I need to wait around 45 seconds for 6 millions of >>> commands. >>> Result: 6,440,627 reads (gl thread on + PBO patches) >>> Result: 274,960 reads (gl thread off) >>> >>> In your case, "Result: 77,444,412 reads", I hope you're patient. >>> I think you must wait at least 10 minutes. >> >> Now, I was patient... >> Tried 2 times but after ~20 minutes I've killed it at first and attached >> gdb at it during second run. >> >> 0x00007fbda686e9a6 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> (gdb) bt >> #0 0x00007fbda686e9a6 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1 0x00007fbda5359453 in ?? () from /usr/local/lib/dri/r600_dri.so >> #2 0x00007fbda53661f4 in ?? () from /usr/local/lib/dri/r600_dri.so >> #3 0x0000000000401e18 in ?? () >> #4 0x00000000004028c7 in ?? () >> #5 0x00007fbda9925781 in fghRedrawWindow () from >> /usr/lib64/libglut.so.3 >> #6 0x00007fbda9925c08 in ?? () from /usr/lib64/libglut.so.3 >> #7 0x00007fbda9926cf9 in fgEnumWindows () from /usr/lib64/libglut.so.3 >> #8 0x00007fbda9925ce4 in glutMainLoopEvent () from >> /usr/lib64/libglut.so.3 >> #9 0x00007fbda9925d85 in glutMainLoop () from /usr/lib64/libglut.so.3 >> #10 0x00000000004019fc in ?? () >> #11 0x00007fbda957e541 in __libc_start_main () from /lib64/libc.so.6 >> #12 0x0000000000401afa in ?? () >> >> Should I do more or not worth it? >> >> Dieter > > Hello Dieter, > > To be honest, I don't konw how much time you need to wait. 77 millions of > PBO transfer is quite huge. It depends on CPU/Memory/PCIe/VRAM/GPU speed. > > Hum based on the image size (194*188*4), you need to approximately transfer > 10522 GB of data from your GPU... Which is likely around 20 minutes if > PCIe run at full speed. Honestly I will let the application in background > for a couple of hours.
Basically, the application needs to be fixed not to emit an unlimited number of PBO transfers without doing anything which requires synchronizing to the transfers. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
