On 21/04/17 09:01 AM, Marek Olšák wrote: > On Thu, Apr 20, 2017 at 9:44 PM, gregory hainaut > <gregory.hain...@gmail.com> wrote: >> On Thu, 20 Apr 2017 20:01:00 +0200 >> Marek Olšák <mar...@gmail.com> wrote: >> >>> On Thu, Apr 20, 2017 at 6:53 PM, gregory hainaut >>> <gregory.hain...@gmail.com> wrote: >>>> On Thu, 20 Apr 2017 11:57:08 +0200 >>>> Marek Olšák <mar...@gmail.com> wrote: >>>> >>>>> On Thu, Apr 20, 2017 at 10:28 AM, gregory hainaut >>>>> <gregory.hain...@gmail.com> wrote: >>>>>> On Thu, 20 Apr 2017 12:29:11 +0900 >>>>>> Michel Dänzer <mic...@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@entry=0xdef24f58, >>>> st=st@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
