[igt-dev] [PATCH i-g-t v2 01/10] lib/igt_dummyload: add igt_cork

[Chris Wilson]

Quoting Antonio Argenziano (2018-02-12 21:28:39)
> 
> 
> On 10/02/18 01:26, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-02-09 23:38:56)
> >> From: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> >>
> >> The "cork" bo (imported bo with attached fence) is used in several
> >> tests to stall execution. Moving it to a common place makes the codebase
> >> cleaner.
> >>
> >> Note that the actual test updates is done in follow up patches as it is
> >> simpler to do in one go after one more common function is added in the
> >> next patch.
> >>
> >> v2: don't use new/free naming, don't use dynamic alloc (Chris)
> >>
> >> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> >> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> >> ---
> > Should have a comment here explaining that the reason we keep fence and
> > call vgem_fence_signal (as it would be autosignalled by close()) is so
> > that we catch when the fence timed-out.
> > 
> > Now, we could set this up with sw_sync (as used in a few other places
> > for corking) to avoid that timeout. Iirc, I suggested the library
> > routines provide both, since both are in use.
> 
> Are you suggesting two function, one per method or expose one interface 
> and use a parameter to chose between the two methods.

I think it can be a single interface, with different flags passed to the
constructor. The trick is that for vgem it returns a handle the caller
plugs into an execobjf, but for sw_sync it returns an explict fence.
Slightly different paths through the uabi (both for execbuf, IPC and
KMS).

> Also, do you think 
> we should let the user chose which corking method to use when measuring 
> ring size?

No, the choice in plugging doesn't affect the measurement. The only
argument there would be serendipitous bug discover through small
interface changes. But for the intended purpose of the tests it doesn't
matter.
-Chris