[Mesa-dev] [PATCH v4 0/3] asynchronous pbo transfer with glthread

[Michel Dänzer]

On 15/04/17 05:08 PM, gregory hainaut wrote:
> On Sat, 15 Apr 2017 00:50:15 +0200
> Dieter Nützel <Dieter at 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 <Dieter at 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