> > + /**
> > +* @max_segment:
> > +*
> > +* Max size for scatter list segments. When unset the default
> > +* (SCATTERLIST_MAX_SEGMENT) is used.
> > +*/
> > + size_t max_segment;
>
> Is there no better place for this then "at the bottom"? drm_device is a
> huge structure,
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTERLIST_MAX_SEGMENT.
Also add max_segment field to drm driver and pass it to
drm_prime_pages_to_sg() calls in drivers and helpers.
v2: place max_segment in d
Hello all,
Thought I'd chime in here. While I can't speak to the issue the GitLab
reporter was experiencing, I can say that I get some performance hit
(expected) from this when using multiple monitors with DRI_PRIME. When
the second monitor is active (with something rendering to it with
relative
On Sun, 6 Sep 2020 at 18:54, Christian König
wrote:
>
> Am 03.08.19 um 02:09 schrieb Andi Kleen:
> > From: Andi Kleen
> >
> > I got tired of seeing a lot of radeon-crt kernel threads in ps on my
> > workstation, one for each CPU and one for each display, which never use any
> > CPU time.
> > Sur
On Sun, Sep 6, 2020 at 4:54 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 03.08.19 um 02:09 schrieb Andi Kleen:
> > From: Andi Kleen
> >
> > I got tired of seeing a lot of radeon-crt kernel threads in ps on my
> > workstation, one for each CPU and one for each display, which
Am 03.08.19 um 02:09 schrieb Andi Kleen:
From: Andi Kleen
I got tired of seeing a lot of radeon-crt kernel threads in ps on my
workstation, one for each CPU and one for each display, which never use any CPU
time.
Surely a single kernel thread is enough to handle the display.
NAK, radeon bloc
