From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 1/8] lib/igt_dummyload: add igt_cork
Date: Wed, 18 Oct 2017 08:49:24 -0700 [thread overview]
Message-ID: <8489e98d-d648-10cd-bf42-b8929c993c08@intel.com> (raw)
In-Reply-To: <2562eecf-eabc-3317-9e0b-7fe62f33164d@intel.com>
On 13/10/17 09:37, Daniele Ceraolo Spurio wrote:
>
>
> On 13/10/17 01:31, Chris Wilson wrote:
>> Quoting Chris Wilson (2017-10-12 23:57:38)
>>> Quoting Daniele Ceraolo Spurio (2017-10-12 23:27:27)
>>>> +igt_cork_t *igt_cork_new(int fd);
>>>
>>> _new does not imply plugged.
>>>
>>>> +void igt_cork_signal(igt_cork_t *cork);
>>>
>>> When have you signaled a cork?
>>>
>>>> +void igt_cork_free(int fd, igt_cork_t *cork);
>>>
>>> _free does not imply unplug.
>>
>> To be clear the verbs are to plug and unplug a queue/schedule. Cork is a
>> reference to TCP_CORK which does the same thing, but plug/unplug are
>> more commonplace (at least in kernel code).
>>
>> I don't see any reason why we need a malloc here.
>> -Chris
>>
>
> I added the malloc just to use the same approach as the spin_batch, I'll
> get rid of it.
> My concern with the existing plug/unplug scheme was that the plug()
> function in the various tests didn't really plug anything but just
> created the bo and that was slightly confusing.
> What do you think of going with:
>
> struct igt_cork {
> int device;
> uint32_t handle;
> uint32_t fence;
> };
>
> struct igt_cork igt_cork_create(int fd);
> void igt_cork_unplug(struct igt_cork *cork);
> void igt_cork_close(int fd, struct igt_cork *cork);
> void igt_cork_unplug_and_close(int fd, struct igt_cork *cork);
>
> The plug() function is still missing, as we do the actual plugging by
> adding the object to the execbuf and I don't think that would be clean
> to wrap in the library. I thought of adding something like
> "get_plugging_handle()" to return cork->handle and make it more explicit
> that that handle was responsible for the plugging but it seemed a bit
> overkill.
>
> Daniele
>
Hi Chris,
any feedback on this?
Thanks,
Daniele
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-10-18 15:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 22:27 [PATCH i-g-t 0/8] extract cork and ring measure code Daniele Ceraolo Spurio
2017-10-12 22:27 ` [PATCH i-g-t 1/8] lib/igt_dummyload: add igt_cork Daniele Ceraolo Spurio
2017-10-12 22:48 ` Chris Wilson
2017-10-12 22:55 ` Chris Wilson
2017-10-12 22:57 ` Chris Wilson
2017-10-13 8:31 ` Chris Wilson
2017-10-13 16:37 ` Daniele Ceraolo Spurio
2017-10-18 15:49 ` Daniele Ceraolo Spurio [this message]
2017-10-18 16:04 ` Chris Wilson
2017-10-18 16:50 ` Daniele Ceraolo Spurio
2017-10-19 18:12 ` Chris Wilson
2017-10-19 20:15 ` Daniele Ceraolo Spurio
2017-10-12 22:27 ` [PATCH i-g-t 2/8] lib/igt_gt: add intel_measure_ring_size Daniele Ceraolo Spurio
2017-10-12 22:27 ` [PATCH i-g-t 3/8] tests/gem_exec_schedule: use new common functions Daniele Ceraolo Spurio
2017-10-12 22:27 ` [PATCH i-g-t 4/8] tests/gem_exec_fence: " Daniele Ceraolo Spurio
2017-10-12 22:27 ` [PATCH i-g-t 5/8] tests/gem_exec_latency: " Daniele Ceraolo Spurio
2017-10-12 22:27 ` [PATCH i-g-t 6/8] tests/gem_wait: use igt_cork Daniele Ceraolo Spurio
2017-10-12 22:27 ` [PATCH i-g-t 7/8] tests/gem_exec_await: use intel_measure_ring_size Daniele Ceraolo Spurio
2017-10-12 22:27 ` [PATCH i-g-t 8/8] tests/gem_ringfill: " Daniele Ceraolo Spurio
2017-10-12 22:48 ` ✓ Fi.CI.BAT: success for extract cork and ring measure code Patchwork
2017-10-12 23:12 ` [PATCH i-g-t 0/8] " Chris Wilson
2017-10-13 5:32 ` ✓ Fi.CI.IGT: success for " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8489e98d-d648-10cd-bf42-b8929c993c08@intel.com \
--to=daniele.ceraolospurio@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox