<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    That would be redundant. GDS handling has always worked in the way
    that the storage is thrown away after an IB.<br>
    <br>
    My LRU patch set should have helped with GDS out of memory errors,
    but I'm not sure how far along we are with rebasing
    amd-staging-drm-next.<br>
    <br>
    Christian.<br>
    <br>
    <div class="moz-cite-prefix">Am 08.07.22 um 16:58 schrieb Marek
      Olšák:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAAxE2A6CV+t9k4VG_zc5uf8qYK07Db0kqChYH0C9MB-TK7MU8g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">Christian, should we set this flag for GDS too?
        Will it help with GDS OOM failures?
        <div dir="auto"><br>
        </div>
        <div dir="auto">Marek</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri., May 13, 2022, 07:26
          Christian König, <<a
            href="mailto:ckoenig.leichtzumerken@gmail.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">Exactly
          that's what we can't do.<br>
          <br>
          See the kernel must always be able to move things to GTT or
          discard. So <br>
          when you want to guarantee that something is in VRAM you must
          at the <br>
          same time say you can discard it if it can't.<br>
          <br>
          Christian.<br>
          <br>
          Am 13.05.22 um 10:43 schrieb Pierre-Eric Pelloux-Prayer:<br>
          > Hi Marek, Christian,<br>
          ><br>
          > If the main feature for Mesa of
          AMDGPU_GEM_CREATE_DISCARDABLE is <br>
          > getting the best placement, maybe we should have 2
          separate flags:<br>
          >   * AMDGPU_GEM_CREATE_DISCARDABLE: indicates to the
          kernel that it can <br>
          > discards the content on eviction instead of preserving it<br>
          >   * AMDGPU_GEM_CREATE_FORCE_BEST_PLACEMENT (or <br>
          > AMDGPU_GEM_CREATE_NO_GTT_FALLBACK ? or
          AMDGPU_CREATE_GEM_AVOID_GTT?): <br>
          > tells the kernel that this bo really needs to be in VRAM<br>
          ><br>
          ><br>
          > Pierre-Eric<br>
          ><br>
          > On 13/05/2022 00:17, Marek Olšák wrote:<br>
          >> Would it be better to set the VM_ALWAYS_VALID flag to
          have a greater <br>
          >> guarantee that the best placement will be chosen?<br>
          >><br>
          >> See, the main feature is getting the best placement,
          not being <br>
          >> discardable. The best placement is a hw design
          requirement due to <br>
          >> using memory for uses that are expected to have
          performance similar <br>
          >> to onchip SRAMs. We need to make sure the best
          placement is <br>
          >> guaranteed if it's VRAM.<br>
          >><br>
          >> Marek<br>
          >><br>
          >> On Thu., May 12, 2022, 03:26 Christian König, <br>
          >> <<a href="mailto:ckoenig.leichtzumerken@gmail.com"
            target="_blank" rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>
          <br>
          >> <mailto:<a
            href="mailto:ckoenig.leichtzumerken@gmail.com"
            target="_blank" rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>>>
          wrote:<br>
          >><br>
          >>     Am 12.05.22 um 00:06 schrieb Marek Olšák:<br>
          >>>     3rd question: Is it worth using this on APUs?<br>
          >><br>
          >>     It makes memory management somewhat easier when
          we are really OOM.<br>
          >><br>
          >>     E.g. it should also work for GTT allocations and
          when the core <br>
          >> kernel says "Hey please free something up or I will
          start the <br>
          >> OOM-killer" it's something we can easily throw away.<br>
          >><br>
          >>     Not sure how many of those buffers we have, but
          marking <br>
          >> everything which is temporary with that flag is
          probably a good idea.<br>
          >><br>
          >>><br>
          >>>     Thanks,<br>
          >>>     Marek<br>
          >>><br>
          >>>     On Wed, May 11, 2022 at 5:58 PM Marek Olšák
          <<a href="mailto:maraeo@gmail.com" target="_blank"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">maraeo@gmail.com</a> <br>
          >>> <mailto:<a href="mailto:maraeo@gmail.com"
            target="_blank" rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">maraeo@gmail.com</a>>>
          wrote:<br>
          >>><br>
          >>>         Will the kernel keep all discardable
          buffers in VRAM if VRAM <br>
          >>> is not overcommitted by discardable buffers, or
          will other buffers <br>
          >>> also affect the placement of discardable buffers?<br>
          >>><br>
          >><br>
          >>     Regarding the eviction pressure the buffers will
          be handled like <br>
          >> any other buffer, but instead of preserving the
          content it is just <br>
          >> discarded on eviction.<br>
          >><br>
          >>><br>
          >>>         Do evictions deallocate the buffer, or do
          they keep an <br>
          >>> allocation in GTT and only the copy is skipped?<br>
          >>><br>
          >><br>
          >>     It really deallocates the backing store of the
          buffer, just keeps <br>
          >> a dummy page array around where all entries are NULL.<br>
          >><br>
          >>     There is a patch set on the mailing list to make
          this a little <br>
          >> bit more efficient, but even using the dummy page
          array should only <br>
          >> have a few bytes overhead.<br>
          >><br>
          >>     Regards,<br>
          >>     Christian.<br>
          >><br>
          >>><br>
          >>>         Thanks,<br>
          >>>         Marek<br>
          >>><br>
          >>>         On Wed, May 11, 2022 at 3:08 AM Marek
          Olšák <br>
          >>> <<a href="mailto:maraeo@gmail.com"
            target="_blank" rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">maraeo@gmail.com</a>
          <mailto:<a href="mailto:maraeo@gmail.com" target="_blank"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">maraeo@gmail.com</a>>>
          wrote:<br>
          >>><br>
          >>>             OK that sounds good.<br>
          >>><br>
          >>>             Marek<br>
          >>><br>
          >>>             On Wed, May 11, 2022 at 2:04 AM
          Christian König <br>
          >>> <<a
            href="mailto:ckoenig.leichtzumerken@gmail.com"
            target="_blank" rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>
          <br>
          >>> <mailto:<a
            href="mailto:ckoenig.leichtzumerken@gmail.com"
            target="_blank" rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">ckoenig.leichtzumerken@gmail.com</a>>>
          wrote:<br>
          >>><br>
          >>>                 Hi Marek,<br>
          >>><br>
          >>>                 Am 10.05.22 um 22:43 schrieb
          Marek Olšák:<br>
          >>>>                 A better flag name would be:<br>
          >>>>                
          AMDGPU_GEM_CREATE_BEST_PLACEMENT_OR_DISCARD<br>
          >>><br>
          >>>                 A bit long for my taste and I
          think the best <br>
          >>> placement is just a side effect.<br>
          >>><br>
          >>>><br>
          >>>>                 Marek<br>
          >>>><br>
          >>>>                 On Tue, May 10, 2022 at 4:13
          PM Marek Olšák <br>
          >>>> <<a href="mailto:maraeo@gmail.com"
            target="_blank" rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">maraeo@gmail.com</a>
          <mailto:<a href="mailto:maraeo@gmail.com" target="_blank"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">maraeo@gmail.com</a>>>
          wrote:<br>
          >>>><br>
          >>>>                     Does this really
          guarantee VRAM placement? The <br>
          >>>> code doesn't say anything about that.<br>
          >>>><br>
          >>><br>
          >>>                 Yes, see the code here:<br>
          >>><br>
          >>>><br>
          >>>>                         diff --git <br>
          >>>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
          <br>
          >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
          >>>>                         index
          8b7ee1142d9a..1944ef37a61e 100644<br>
          >>>>                         --- <br>
          >>>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
          >>>>                         +++ <br>
          >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c<br>
          >>>>                         @@ -567,6 +567,7 @@
          int <br>
          >>>> amdgpu_bo_create(struct amdgpu_device *adev,<br>
          >>>>                                        
          bp->domain;<br>
          >>>>                                
          bo->allowed_domains = <br>
          >>>> bo->preferred_domains;<br>
          >>>>                                 if
          (bp->type != ttm_bo_type_kernel &&<br>
          >>>>                         +         
           !(bp->flags & <br>
          >>>> AMDGPU_GEM_CREATE_DISCARDABLE) &&<br>
          >>>>                                    
          bo->allowed_domains == <br>
          >>>> AMDGPU_GEM_DOMAIN_VRAM)<br>
          >>>> bo->allowed_domains |=
          AMDGPU_GEM_DOMAIN_GTT;<br>
          >>>><br>
          >>><br>
          >>>                 The only case where this could be
          circumvented is <br>
          >>> when you try to allocate more than physically
          available on an APU.<br>
          >>><br>
          >>>                 E.g. you only have something like
          32 MiB VRAM and <br>
          >>> request 64 MiB, then the GEM code will catch the
          error and fallback <br>
          >>> to GTT (IIRC).<br>
          >>><br>
          >>>                 Regards,<br>
          >>>                 Christian.<br>
          >>><br>
          >><br>
          <br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>