[libre-riscv-dev] LD/ST address matcher

Luke Kenneth Casson Leighton lkcl at lkcl.net
Mon Jun 3 23:50:45 BST 2019


On Mon, Jun 3, 2019 at 7:50 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Mon, Jun 3, 2019, 07:38 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:

> > Jacob, what sort of LD/ST profile can we expect from Kazan? The reason for
> > asking is because the simplest algorithm is to check bits 4 through 15 or
> > so and ignore the bottom 4 bits and everything 16 or above.
> >
> I would expect a general computing profile with the addition of common
> alternating loads and stores to addresses that are separated by a multiple
> of 1MiB or so,

 if it's *exactly* 1MB then yes that becomes a problem.  if however
it's off by 16 bytes, that's not a problem because by checking bits 4
to 11 it produces the miss.

 from what Mitch said, the performance seems unaffected because the
regularity of data accesses just isn't that high in general computing.

 however with the GPU load, if it is *guaranteed* that there will be
batches of LDs to addresses separated *exactly* by 1MiB followed by
batches of STs to addresses separated by *exactly* 1MiB, then checking
only bits 4-11 will definitely not be enough.

(LDs cannot be done at the same time as STs, no matter what, so that's
not the issue)

 can you please confirm: will the Vulkan API produce batches of LDs in
quick succession that are *exactly* on a 1MiB boundary?  if so, i'm
curious to know why, and if it can be avoided.

l.



More information about the libre-riscv-dev mailing list