On 2018-09-10 9:02 p.m., Marek Olšák wrote:
> On Mon, Sep 10, 2018 at 10:45 AM, Michel Dänzer wrote:
>> On 2018-09-07 9:01 p.m., Marek Olšák wrote:
>>> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer wrote:
On 2018-09-07 4:31 p.m., Marek Olšák wrote:
> On Fri, Sep 7, 2018, 4:34 AM Michel
On Mon, Sep 10, 2018 at 10:45 AM, Michel Dänzer wrote:
> On 2018-09-07 9:01 p.m., Marek Olšák wrote:
>> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer wrote:
>>> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
> On 2018-09-06 10:56 p.m.,
On 2018-09-07 9:01 p.m., Marek Olšák wrote:
> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer wrote:
>> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
>>> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
On 2018-09-06 10:56 p.m., Axel Davy wrote:
> I fear if we begin to do the work
On Fri, Sep 7, 2018 at 3:34 PM, Alan Swanson wrote:
> On Fri, 2018-09-07 at 15:01 -0400, Marek Olšák wrote:
>> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer
>> wrote:
>> > On 2018-09-07 4:31 p.m., Marek Olšák wrote:
>> > >
>> > > I don't think the performance can be worse than it is right now.
On Fri, 2018-09-07 at 15:01 -0400, Marek Olšák wrote:
> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer
> wrote:
> > On 2018-09-07 4:31 p.m., Marek Olšák wrote:
> > >
> > > I don't think the performance can be worse than it is right now.
> >
> > In the worst case, all processes using OpenGL (or
I'm changing the initial L3 cache number to this:
+static unsigned L3_cache_number;
+static once_flag init_cache_number_flag = ONCE_FLAG_INIT;
+
+static void
+util_init_cache_number(void)
+{
+ /* Get a semi-random number. */
+ int64_t t = os_time_get_nano();
+ L3_cache_number = (t ^ (t >>
On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer wrote:
> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
>> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
>>> On 2018-09-06 10:56 p.m., Axel Davy wrote:
>>>
I fear if we begin to do the work manually, there won't be interest to
do that in
On 2018-09-07 4:31 p.m., Marek Olšák wrote:
> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
>> On 2018-09-06 10:56 p.m., Axel Davy wrote:
>>
>>> I fear if we begin to do the work manually, there won't be interest to
>>> do that in the kernel,
>>> and thus all applications will need to include
On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer wrote:
> On 2018-09-06 10:56 p.m., Axel Davy wrote:
> > Yeah by pinning to cores, I meant to group of cores.
> >
> > I think a reasonable policy would be for the kernel to put all threads
> > of a given process on the same L3
> > as long as the number
On 2018-09-06 10:56 p.m., Axel Davy wrote:
> Yeah by pinning to cores, I meant to group of cores.
>
> I think a reasonable policy would be for the kernel to put all threads
> of a given process on the same L3
> as long as the number of threads is lower than the L3 group size.
> When there is more
On Thu, Sep 6, 2018 at 5:54 PM, Roland Scheidegger wrote:
> Am 06.09.2018 um 22:56 schrieb Axel Davy:
>> Yeah by pinning to cores, I meant to group of cores.
>>
>> I think a reasonable policy would be for the kernel to put all threads
>> of a given process on the same L3
>> as long as the number
Am 06.09.2018 um 22:56 schrieb Axel Davy:
> Yeah by pinning to cores, I meant to group of cores.
>
> I think a reasonable policy would be for the kernel to put all threads
> of a given process on the same L3
> as long as the number of threads is lower than the L3 group size.
> When there is more
Mesa/RadeonSI already has a lot of threads. My CPU has 8C/16T, but if
you debug glxgears, you'll see 21 threads in that process with
radeonsi. They are mostly shader compiler threads.
Games have a bunch of threads too.
Only a small number of threads really need be pinned to one L3 cache.
Those
Yeah by pinning to cores, I meant to group of cores.
I think a reasonable policy would be for the kernel to put all threads
of a given process on the same L3
as long as the number of threads is lower than the L3 group size.
When there is more threads I guess it'd need heuristics to pick which
Actually, you make a good point about the kernel, but the kernel has
no visibility into which threads need to be coupled together. So the
kernel can't do anything.
Marek
On Thu, Sep 6, 2018 at 2:24 PM, Marek Olšák wrote:
> I think you are missing the point. This series doesn't pin threads to
>
I think you are missing the point. This series doesn't pin threads to
cores. It pins threads to one L3, which can have 4 or 8 cores.
Marek
On Thu, Sep 6, 2018 at 5:22 AM, Axel Davy wrote:
> Hi Marek,
>
> Shouldn't this core pinning be handled by the kernel ?
>
> Else all multithreaded games (or
Hi Marek,
Shouldn't this core pinning be handled by the kernel ?
Else all multithreaded games (or applications) need an update.
I also see a risk in applications handling the core pinning: several
intensive applications
may pin the same cores. The kernel would be able to switch automatically
Hi,
When the Ryzen CPUs were launched, they didn't perform very well in
games, and it took a while before games were patched. Guess what,
Mesa drivers have suffered from the same inefficincies until now.
The AMD Zen architecture has multiple core complexes (CCX) where each
CCX has e.g. 4C/8T and
18 matches
Mail list logo
