On 2019-04-02 4:00 p.m., Michel Dänzer wrote: > On 2019-04-02 2:57 p.m., Marek Olšák wrote: >> On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer <mic...@daenzer.net> wrote: >>> On 2019-04-02 12:39 a.m., Marek Olšák wrote: >>>> On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely <jan.ves...@rutgers.edu> >>> wrote: >>>>> On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: >>>>>> Does the attached patch fix the copy-buffer test? >>>>> >>>>> it does thanks. >>>>> Won't the compute only context still need some synchronization? >>>>> Is there anything else to guarantee that the data is in place after >>>>> return from resource_copy_region ? >>>> >>>> The synchronization is the same on gfx and compute rings. >>> >>> BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 >>> ? It does indicate some kind of synchronization issue between >>> si_resource_copy_region using a compute ring and other operations using >>> a GFX ring. >> >> Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK. > > That bugzilla comment is about the GTK menu issue, not about xterm. > Anyway, I doubt GTK uses OpenCL either, and neither does glamor, so it > was probably an invalid bisect result then.
Apparently not, after all: https://bugs.freedesktop.org/110355 Looks like there is some issue with si_compute_copy_image, even if it doesn't use a compute ring. -- Earthling Michel Dänzer | https://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
