On Tue, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but nee
On Wed, Mar 18, 2020 at 11:05:48AM +0100, Michel Dänzer wrote:
> On 2020-03-17 6:21 p.m., Lucas Stach wrote:
> > That's one of the issues with implicit sync that explicit may solve:
> > a single client taking way too much time to render something can
> > block the whole pipeline up until the disp
On Tue, Mar 17, 2020 at 12:18:47PM -0500, Jason Ekstrand wrote:
> On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay
> wrote:
> >
> > One related issue with explicit sync using sync_file is that combined
> > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> > rendering in userspace (lik
Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote:
> > Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> > > One related issue with explicit sync using sync_file is that combined
> > > CPUs/GPUs (the CPU cores *are*
Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks)
Am Dienstag, den 17.03.2020, 11:33 -0400 schrieb Nicolas Dufresne:
> Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > Hi Jason,
> >
> > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > > On Wed, M
Le mercredi 18 mars 2020 à 11:05 +0100, Michel Dänzer a écrit :
> On 2020-03-17 6:21 p.m., Lucas Stach wrote:
> > That's one of the issues with implicit sync that explicit may solve:
> > a single client taking way too much time to render something can
> > block the whole pipeline up until the dis
On 2020-03-17 6:21 p.m., Lucas Stach wrote:
> That's one of the issues with implicit sync that explicit may solve:
> a single client taking way too much time to render something can
> block the whole pipeline up until the display flip. With explicit
> sync the compositor can just decide to use t
On Tue, Mar 17, 2020 at 11:35 PM Jason Ekstrand wrote:
>
> On Wed, Mar 18, 2020 at 12:20 AM Jacob Lifshay
> wrote:
> >
> > The main issue with doing everything immediately is that a lot of the
> > function calls that games expect to take a very short time (e.g.
> > vkQueueSubmit) would instead t
On Wed, Mar 18, 2020 at 12:20 AM Jacob Lifshay wrote:
>
> On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote:
> >
> > On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay
> > wrote:
> > >
> > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> > > >
> > > > Am Dienstag, den 17.03.2020, 10:59 -0
On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote:
>
> On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay
> wrote:
> >
> > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> > >
> > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > > > I think I found a userspace-accessible
On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay wrote:
>
> On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> >
> > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > > I think I found a userspace-accessible way to create sync_files and
> > > dma_fences that would fulfill the re
On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
>
> Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > I think I found a userspace-accessible way to create sync_files and
> > dma_fences that would fulfill the requirements:
> > https://github.com/torvalds/linux/blob/master/driv
On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote:
>
> Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> > One related issue with explicit sync using sync_file is that combined
> > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> > rendering in userspace (like llvmp
On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay wrote:
>
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but ne
One related issue with explicit sync using sync_file is that combined
CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
rendering in userspace (like llvmpipe but for Vulkan and with extra
instructions for GPU tasks) but need to synchronize with other
drivers/processes is that there shou
On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote:
> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> > The synchronization works because the Mesa driver waits for idle (drains
> > the GFX pipeline) at the end of command buffers and there is only 1
> > graphics queue, so everything is ordered.
> >
On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> The synchronization works because the Mesa driver waits for idle (drains
> the GFX pipeline) at the end of command buffers and there is only 1
> graphics queue, so everything is ordered.
>
> The GFX pipeline runs asynchronously to the command buffer, m
The synchronization works because the Mesa driver waits for idle (drains
the GFX pipeline) at the end of command buffers and there is only 1
graphics queue, so everything is ordered.
The GFX pipeline runs asynchronously to the command buffer, meaning the
command buffer only starts draws and doesn'
Could you elaborate. If there's something missing from my mental model of
how implicit sync works, I'd like to have it corrected. People continue
claiming that AMD is somehow special but I have yet to grasp what makes it
so. (Not that anyone has bothered to try all that hard to explain it.)
There is no synchronization between processes (e.g. 3D app and compositor)
within X on AMD hw. It works because of some hacks in Mesa.
Marek
On Wed, Mar 11, 2020 at 1:31 PM Jason Ekstrand wrote:
> All,
>
> Sorry for casting such a broad net with this one. I'm sure most people
> who reply will g
21 matches
Mail list logo
