public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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

  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