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

Tue Apr 25 09:14:42 UTC 2017

Hello,

I did more tests on my side. DRI3 + recent stack is fine. Older
(Debian Jessie, ~2y old) XCB hangs/deadlock. So all DRI3 drivers
should be fine (typically AMD). And all applications that called
XInitThread soon enough. So yeah I think we can merge it. Note: I
don't have commit access.

Nouveau doesn't use DRI3 by default. So I'm looking to use XCB for
dri2GetBuffer* operations. I copied the code from EGL/X11. So far it
isn't a success. The dri2_drawable pdraw object is correctly populated
with good value but I have tons of piglit failure. Debug is on-going
but I'm afraid that it might not be possible to use XCB.

Best Regads,
Gregory

On 4/25/17, Dieter Nützel <Dieter at nuetzel-hh.de> wrote:
> Am 21.04.2017 12:11, schrieb Marek Olšák:
>> FWIW, I think this series can land, because glthread is not enabled by
>> default, and the libX11 issue is unrelated.
>>
>> Marek
>
>
> Gregory?
>
> For the series:
>
> Tested-by: Dieter Nützel <Dieter at nuetzel-hh.de>
>
> On Turks XT (6670).
>
> Dieter
>
>> On Apr 21, 2017 4:22 AM, "Michel Dänzer" <michel at daenzer.net> wrote:
>>
>>> On 21/04/17 09:01 AM, Marek Olšák wrote:
>>>> On Thu, Apr 20, 2017 at 9:44 PM, gregory hainaut
>>>> <gregory.hainaut at gmail.com> wrote:
>>>>> On Thu, 20 Apr 2017 20:01:00 +0200
>>>>> Marek Olšák <maraeo at gmail.com> wrote:
>>>>>
>>>>>> On Thu, Apr 20, 2017 at 6:53 PM, gregory hainaut
>>>>>> <gregory.hainaut at gmail.com> wrote:
>>>>>>> On Thu, 20 Apr 2017 11:57:08 +0200
>>>>>>> Marek Olšák <maraeo at gmail.com> wrote:
>>>>>>>
>>>>>>>> On Thu, Apr 20, 2017 at 10:28 AM, gregory hainaut
>>>>>>>> <gregory.hainaut at gmail.com> wrote:
>>>>>>>>> On Thu, 20 Apr 2017 12:29:11 +0900
>>>>>>>>> Michel Dänzer <michel at daenzer.net> wrote:
>>>>>>>>>
>>>>>>>>>> On 20/04/17 01:54 AM, Gregory Hainaut wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please find the latest version that include a small fix for
>>> hash deletion. I
>>>>>>>>>>> think the series is good now. Please review/ack it.
>>>>>>>>>>
>>>>>>>>>> I'm afraid I have to NACK it. As discussed in the v4 cover
>>> letter
>>>>>>>>>> thread, Mesa's glthread cannot make any libX11 API calls.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello Michel,
>>>>>>>>>
>>>>>>>>> Just to be sure we are on the same line, let's me do a
>>> summary.
>>>>>>>>>
>>>>>>>>> PCSX2 does the following bad pattern
>>>>>>>>> 1/ no call to XInitThread
>>>>>>>>> 2/ XGetGeometry to get the size of the surface
>>>>>>>>> 3/ glDrawArray into the default framebuffer 0 (the window,
>>> I'm not sure how to call it)
>>>>>>>>> => which seem to call DRI2GetBuffersWithFormat under the
>>> hood. I guess to get the
>>>>>>>>> associated buffer of the window.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So far it was (kind of) working fine because PCSX2 does tons
>>> of PBO transfer. So glthread
>>>>>>>>> was mostly synchronous.
>>>>>>>>>
>>>>>>>>> This series removes the (useless) PBO transfer
>>> synchronization. So now glthread is really
>>>>>>>>> asynchronous and the above bad pattern crash as expected.
>>>>>>>>>
>>>>>>>>> I didn't add any libX11 API call on the patches. And I don't
>>> think we can remvove the DRI stuff.
>>>>>>>>>
>>>>>>>>> Hum, I don't know what will be the impact on the perf but
>>> potentially we can force a synchronization
>>>>>>>>> when there is a draw to framebuffer 0.
>>>>>>>>
>>>>>>>> Can you send us the backtrace when DRI2GetBuffersWithFormat is
>>> called
>>>>>>>> by glDrawArrays?
>>>>>>>>
>>>>>>>> Marek
>>>>>>>
>>>>>>> Hello Marek, Michel,
>>>>>>>
>>>>>>> Here the full backtrace.
>>>>>>>
>>>>>>> #0  DRI2GetBuffersWithFormat (dpy=0xc6307e48,
>>> drawable=104857784, width=0xdef348c0, height=0xdef348c4,
>>> attachments=0xdcc15c88, count=1, outCount=0xdcc15c74) at dri2.c:464
>>>>>>> #1  0xf05bac45 in dri2GetBuffersWithFormat
>>> (driDrawable=0xdef348a8, width=0xdef348c0, height=0xdef348c4,
>>> attachments=0xdcc15c88, count=1, out_count=0xdcc15c74,
>>> loaderPrivate=0xdefc6ef0) at dri2_glx.c:894
>>>>>>> #2  0xe3ec3111 in dri2_drawable_get_buffers (count=<synthetic
>>> pointer>, atts=0xdef252f8, drawable=0xdefc7b08) at dri2.c:285
>>>>>>> #3  dri2_allocate_textures (ctx=0xdef15928,
>>> drawable=0xdefc7b08, statts=0xdef252f8, statts_count=2) at
>>> dri2.c:480
>>>>>>> #4  0xe3ebcbb0 in dri_st_framebuffer_validate
>>> (stctx=0xdef4ab10, stfbi=0xdefc7b08, statts=0xdef252f8, count=2,
>>> out=0xdcc15d78) at dri_drawable.c:83
>>>>>>> #5  0xe3d37afc in st_framebuffer_validate
>>> (stfb=stfb at entry=0xdef24f58, st=st at entry=0xdef4ab10) at
>>> state_tracker/st_manager.c:189
>>>>>>> Note "print stfb->Base->Name" give me 0
>>>>>>> #6  0xe3d38649 in st_manager_validate_framebuffers
>>> (st=0xdef4ab10) at state_tracker/st_manager.c:869
>>>>>>> #7  0xe3cd0580 in st_validate_state (st=0xdef4ab10,
>>> pipeline=ST_PIPELINE_RENDER) at state_tracker/st_atom.c:174
>>>>>>> #8  0xe3cf935d in st_draw_vbo (ctx=0xdef7f8f8,
>>> prims=0xdcc15f40, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
>>> min_index=39911, max_index=39914, tfb_vertcount=0x0, stream=0,
>>> indirect=0x0) at state_tracker/st_draw.c:191
>>>>>>> #9  0xe3caf35e in vbo_draw_arrays (baseInstance=0,
>>> numInstances=1, count=4, start=39911, mode=5, ctx=0xdef7f8f8) at
>>> vbo/vbo_exec_array.c:427
>>>>>>> #10 vbo_exec_DrawArrays (mode=5, start=39911, count=4) at
>>> vbo/vbo_exec_array.c:575
>>>>>>> #11 0xe3be4f07 in _mesa_unmarshal_DrawArrays (ctx=0xdef7f8f8,
>>> cmd=0xc41574b0) at main/marshal_generated.c:26644
>>>>>>> #12 _mesa_unmarshal_dispatch_cmd (ctx=0xdef7f8f8,
>>> cmd=0xc41574b0) at main/marshal_generated.c:42457
>>>>>>> #13 0xe3ba8af0 in glthread_unmarshal_batch (release_batch=true,
>>> batch=0xc4157410, ctx=0xdef7f8f8) at main/glthread.c:64
>>>>>>> #14 glthread_worker (data=0xdef7f8f8) at main/glthread.c:110
>>>>>>>
>>>>>>>
>>>>>>>> If this DRI2GetBuffersWithFormat call results in libX11 API
>>> calls on the
>>>>>>>> glthread, that's a bug which needs to be fixed, either by
>>> moving the
>>>>>>>> DRI2GetBuffersWithFormat call to the main thread or (if
>>> possible) by
>>>>>>>> changing DRI2GetBuffersWithFormat to use XCB directly.
>>>>>>
>>>>>> First, we need to understand why it's happening. Does the app
>>> use the
>>>>>> front buffer? Does it ever call glDrawBuffer(GL_FRONT) or
>>>>>> glReadBuffer(GL_FRONT)?
>>>>>
>>>>> Hello Marek,
>>>>>
>>>>> No, I don't use the front buffer. I don't call glDrawBuffer for
>>> the FB 0. So I think,
>>>>> it should use GL_BACK.
>>>>> Hum except if some 3rparty libs do something in my back.
>>>>>
>>>>> In case it have any impact, I'm using either glXSwapIntervalEXT
>>> or glXSwapIntervalMESA (if the former wasn't found)
>>>>> to control Vsync.
>>>>>
>>>>> If I understand you, you expect that DRI2GetBuffersWithFormat
>>> should haven't be called in the first place ?
>>>>
>>>> It's OK for it to get called. We just have to find a way how to
>>> deal
>>>> with it. If that means we have to disable old & slow DRI2 for
>>>> glthread, that's fine. The other option is to sync the first draw
>>> call
>>>> rendering to the default framebuffer.
>>>
>>> FWIW, I think it should be possible to make DRI2GetBuffersWithFormat
>>> use
>>> XCB directly.
>>>
>>> There is other functionality related to events (window geometry
>>> changes,
>>> GLX_INTEL_swap_event, maybe more?) for which DRI2 relies on libX11
>>> specifics and can't use XCB directly. But hopefully that code can
>>> already only run on the main thread.
>>>
>>> --
>>> Earthling Michel Dänzer               |
>>> http://www.amd.com
>>> Libre software enthusiast             |             Mesa and X
>>> developer
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>