public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Animesh Manna <animesh.manna@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v2 02/15] drm/i915/dsb: DSB context creation.
Date: Mon, 21 Oct 2019 15:41:04 +0530	[thread overview]
Message-ID: <998ad164-4eac-e5a9-50e9-99632d238c81@intel.com> (raw)
In-Reply-To: <55b39daa-fae6-cb1d-0280-9677c57fd242@linux.intel.com>



On 10/17/2019 8:08 PM, Tvrtko Ursulin wrote:
>
> On 17/10/2019 14:53, Animesh Manna wrote:
>> On 10/17/2019 6:39 PM, Tvrtko Ursulin wrote:
>>> On 17/10/2019 13:52, Animesh Manna wrote:
>>>> On 10/17/2019 2:05 PM, Tvrtko Ursulin wrote:
>>>>> On 22/08/2019 13:09, Chris Wilson wrote:
>>>>>> Quoting Animesh Manna (2019-08-22 13:05:06)
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> On 8/21/2019 11:41 PM, Chris Wilson wrote:
>>>>>>>> Quoting Animesh Manna (2019-08-21 07:32:22)
>>>>>>>>> +       vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 
>>>>>>>>> PIN_MAPPABLE);
>>>>>>>> Only this (currently) still requires struct_mutex
>>>>>>>
>>>>>>> Sure will add.
>>>>>>>>
>>>>>>>> Does it have to mappable? Is that the HW constraint?
>>>>>>>
>>>>>>> Yes, as per HW design need a cpu mapped buffer to write 
>>>>>>> opcode+data from
>>>>>>> driver.
>>>>>>
>>>>>> PIN_MAPPABLE refers to the iomem aperture portion of the Global 
>>>>>> GTT (i.e.
>>>>>> the low 64-512MiB). You never use a GGTT mmap for your CPU 
>>>>>> access, so the
>>>>>> placement should be entirely dictated by the DSB requirements. If 
>>>>>> you
>>>>>> don't need to be in the low region, don't force it to be, so we have
>>>>>> less congestion for the objects that have to be placed in that 
>>>>>> region.
>>>>>
>>>>> I was doing a mini audit of what uses the aperture these days and 
>>>>> noticed this code has been merged in the meantime, but AFAICS this 
>>>>> question from Chris hasn't been answered? At least not on the 
>>>>> mailing list. So does it need to be in the aperture region or not?
>>>>
>>>> Hi,
>>>>
>>>> Based on recommendation from H/w team used PIN_MAPPABLE, not very 
>>>> sure about internal details.
>>>
>>> What did the recommendation exactly say? That it has to be in GGTT 
>>> or aperture?
>>
>> It said:
>> "GMM to allocate buffer from global GTT, get CPU mapped address as 
>> well (not stolen memory) ... ".
>
> So it's possible you don't need PIN_MAPPABLE.

As per I remember from initial discussion from h/w team DSB is not cache 
coherent. Due to that we have used I915_MAP_WC during mapping the buffer 
and want to keep the buffer in aperture region.
Could not find the discussion thread as it was quiet old like around 
initial enablement of DSB feature.

>
>
> Do we have some test coverage for this? In other words if I send a 
> patch which removes it, will we know if the feature is healthy?

Gamma lut programming is enabled through DSB. kms_color igt is having 
the coverage for this.

Not sure cache coherence issue is easily reproducible or not, will go 
with expert's opinion.

Regards,
Animesh

>
> Regards,
>
> Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-10-21 10:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21  6:32 [PATCH v2 00/15] DSB enablement Animesh Manna
2019-08-21  6:32 ` [PATCH v2 01/15] drm/i915/dsb: feature flag added for display state buffer Animesh Manna
2019-08-21  6:32 ` [PATCH v2 02/15] drm/i915/dsb: DSB context creation Animesh Manna
2019-08-21 18:11   ` Chris Wilson
2019-08-22 12:05     ` Animesh Manna
2019-08-22 12:09       ` Chris Wilson
2019-10-17  8:35         ` Tvrtko Ursulin
2019-10-17 12:52           ` Animesh Manna
2019-10-17 13:09             ` Tvrtko Ursulin
2019-10-17 13:53               ` Animesh Manna
2019-10-17 14:38                 ` Tvrtko Ursulin
2019-10-21 10:11                   ` Animesh Manna [this message]
2019-10-21 10:18                     ` Chris Wilson
2019-08-21  6:32 ` [PATCH v2 03/15] drm/i915/dsb: single register write function for DSB Animesh Manna
2019-08-21  6:32 ` [PATCH v2 04/15] drm/i915/dsb: Added enum for reg write capability Animesh Manna
2019-08-22 12:57   ` Jani Nikula
2019-08-21  6:32 ` [PATCH v2 05/15] drm/i915/dsb: Indexed register write function for DSB Animesh Manna
2019-08-21 18:27   ` Chris Wilson
2019-08-22 12:06     ` Animesh Manna
2019-08-21  6:32 ` [PATCH v2 06/15] drm/i915/dsb: Update i915_write to call dsb-write Animesh Manna
2019-08-21 18:29   ` Chris Wilson
2019-08-22 13:11     ` Jani Nikula
2019-08-21  6:32 ` [PATCH v2 07/15] drm/i915/dsb: Register definition of DSB registers Animesh Manna
2019-08-21  6:32 ` [PATCH v2 08/15] drm/i915/dsb: Check DSB engine status Animesh Manna
2019-08-21  6:32 ` [PATCH v2 09/15] drm/i915/dsb: functions to enable/disable DSB engine Animesh Manna
2019-08-21  6:32 ` [PATCH v2 10/15] drm/i915/dsb: function to trigger workload execution of DSB Animesh Manna
2019-08-21 18:43   ` Chris Wilson
2019-08-22 12:07     ` Animesh Manna
2019-08-21  6:32 ` [PATCH v2 11/15] drm/i915/dsb: function to destroy DSB context Animesh Manna
2019-08-21 18:45   ` Chris Wilson
2019-08-21  6:32 ` [PATCH v2 12/15] drm/i915/dsb: Early prepare of dsb context Animesh Manna
2019-08-21  6:32 ` [PATCH v2 13/15] drm/i915/dsb: Cleanup of DSB context Animesh Manna
2019-08-21  6:32 ` [PATCH v2 14/15] drm/i915/dsb: Documentation for DSB Animesh Manna
2019-08-21  6:32 ` [PATCH v2 15/15] drm/i915/dsb: Enable gamma lut programming using DSB Animesh Manna
2019-08-22 13:23   ` Jani Nikula
2019-08-22 14:45     ` Animesh Manna
2019-08-21  7:11 ` ✗ Fi.CI.CHECKPATCH: warning for DSB enablement. (rev2) Patchwork
2019-08-21  7:12 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-08-21  7:32 ` ✓ Fi.CI.BAT: success " Patchwork
2019-08-21 18:46 ` ✗ Fi.CI.IGT: failure " 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=998ad164-4eac-e5a9-50e9-99632d238c81@intel.com \
    --to=animesh.manna@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@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