From: Dave Gordon <david.s.gordon@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
Intel-gfx@lists.freedesktop.org,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code
Date: Fri, 22 Jul 2016 14:59:27 +0100 [thread overview]
Message-ID: <579226BF.8010208@intel.com> (raw)
In-Reply-To: <579216DD.1070503@linux.intel.com>
On 22/07/16 13:51, Tvrtko Ursulin wrote:
>
> On 22/07/16 13:42, Dave Gordon wrote:
>> On 21/07/16 14:46, Tvrtko Ursulin wrote:
>>> On 21/07/16 14:31, Chris Wilson wrote:
>>>> On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote:
>>>>>
>>>>> On 21/07/16 13:59, Chris Wilson wrote:
>>>>>> On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote:
>>>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>>
>>>>>>> Static table wastes space for invalid combinations and
>>>>>>> engines which are not supported by Gen6 (legacy semaphores).
>>>>>>>
>>>>>>> Replace it with a function devised by Dave Gordon.
>>>>>>>
>>>>>>> I have verified that it generates the same mappings between
>>>>>>> mbox selectors and signalling registers.
>>>>>>
>>>>>> So just how big was that table? How big are the functions replacing
>>>>>> it?
>>>>>
>>>>> With I915_NUM_ENGINES of 5 table is 5 * 5 * (2 * 4) = 200 bytes.
>>>>>
>>>>> With the patch .text grows by 144 bytes here and .rodata shrinks by
>>>>> 256. So a net gain of 112 bytes with my config. Conclusion is that
>>>>> as long as we got five engines it is not that interesting to get rid
>>>>> of the table.
>>
>> Since the semaphore matrix is only relevant to a specific gen, you could
>> remove it from the multi-generational engine-list and instead just have
>> it in the gen-specific code that needs it. That way it won't continue to
>> grow as new engines are added. The one gen that needs it is fixed at
>> 4x4, so it could just be a 16-byte lookup table, or 32 bits
>> (0b11001001_10110001_00101101_10010011) if you really want to save space
>> ;-)
>
> Not so much save space today as prevent from it exploding in the future.
>
> Rewriting the table to use hw_ids sounds like the best idea so far so
> I'll go with that.
>
> Regards,
>
> Tvrtko
+ * This distilled to integers looks like this:
+ *
+ * | 0 | 1 | 2 | 3
+ * --+-----+-----+-----+-----
+ * 0 | -1 | 0 | 2 | 1
+ * 1 | 2 | -1 | 0 | 1
+ * 2 | 0 | 2 | -1 | 1
+ * 3 | 2 | 1 | 0 | -1
static unsigned int sem_wait_mbox(unsigned int x, unsigned int y)
{
const unsigned int z = 0b11000110011110000100111001100011;
return (z >> (8*y + 2*x)) & 3;
}
x
0 1 2 3
-------
0: 3 0 2 1
y 1: 2 3 0 1
2: 0 2 3 1
3: 2 1 0 3
No complicated code, and hardly any table :)
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-07-22 13:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-21 9:31 [PATCH] drm/i915: Replace gen6 semaphore signal table with code Tvrtko Ursulin
2016-07-21 9:58 ` ✗ Ro.CI.BAT: failure for " Patchwork
2016-07-21 10:14 ` [PATCH] " Ville Syrjälä
2016-07-21 11:56 ` Dave Gordon
2016-07-21 13:23 ` Tvrtko Ursulin
2016-07-21 11:59 ` [PATCH v2] " Tvrtko Ursulin
2016-07-21 12:00 ` [PATCH v3] " Tvrtko Ursulin
2016-07-21 12:59 ` Chris Wilson
2016-07-21 13:16 ` Tvrtko Ursulin
2016-07-21 13:19 ` Tvrtko Ursulin
2016-07-21 13:31 ` Chris Wilson
2016-07-21 13:46 ` Tvrtko Ursulin
2016-07-21 14:34 ` Chris Wilson
2016-07-22 12:42 ` Dave Gordon
2016-07-22 12:51 ` Tvrtko Ursulin
2016-07-22 13:59 ` Dave Gordon [this message]
2016-07-21 12:22 ` ✗ Ro.CI.BAT: failure for drm/i915: Replace gen6 semaphore signal table with code (rev2) Patchwork
2016-07-21 12:44 ` ✗ Ro.CI.BAT: failure for drm/i915: Replace gen6 semaphore signal table with code (rev3) 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=579226BF.8010208@intel.com \
--to=david.s.gordon@intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=chris@chris-wilson.co.uk \
--cc=tvrtko.ursulin@intel.com \
--cc=tvrtko.ursulin@linux.intel.com \
/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