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.
>
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 Lifsh
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/to
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
> > rend
should be some way to create an
explicit fence/semaphore from userspace and later signal it. This
seems to conflict with the requirement for a sync_file to complete in
finite time, since the user process could be stopped or killed.
Any ideas?
Jacob Lifshay
One idea for Marge-bot (don't know if you already do this):
Rust-lang has their bot (bors) automatically group together a few merge
requests into a single merge commit, which it then tests, then, then the
tests pass, it merges. This could help reduce CI runs to once a day (or
some other rate). If t
