Yes please, I think that is the best way out for qemu.
Alex
On Mon, 17 Jun 2019 at 11:35, Marco Felsch wrote:
> On 19-06-14 15:37, Alexander Kanavin wrote:
> > On Fri, 14 Jun 2019 at 15:36, Burton, Ross
> wrote:
> >
> > > > Dropping the swrast dependency will not help though, as it is
> provid
On 19-06-14 15:37, Alexander Kanavin wrote:
> On Fri, 14 Jun 2019 at 15:36, Burton, Ross wrote:
>
> > > Dropping the swrast dependency will not help though, as it is provided
> > by the mesa-megadriver package, which will continue to include swrast as
> > long as it is enabled in the mesa recipe.
On Fri, 14 Jun 2019 at 15:36, Burton, Ross wrote:
> > Dropping the swrast dependency will not help though, as it is provided
> by the mesa-megadriver package, which will continue to include swrast as
> long as it is enabled in the mesa recipe. mesa-megadriver is also pulled in
> through other dep
On Fri, 14 Jun 2019 at 14:34, Alexander Kanavin wrote:
>
> On Fri, 14 Jun 2019 at 15:26, wrote:
>>
>> I guess if we can track down where the swrast dependency is coming and
>> and change things to avoid it, that would probably be ok.
>
>
> As Ross said, qemu bsp has this:
>
> XSERVER ?= "xserver-
On Fri, 14 Jun 2019 at 15:26, wrote:
> I guess if we can track down where the swrast dependency is coming and
> and change things to avoid it, that would probably be ok.
>
As Ross said, qemu bsp has this:
XSERVER ?= "xserver-xorg \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
'
I think the only qemus where we do anything mesa-related are kvm-enabled
x86 ones. So in that sense it doesn't matter which drivers are shipped for
other qemu targets.
Alex
On Fri, 14 Jun 2019 at 15:16, Burton, Ross wrote:
> On Fri, 14 Jun 2019 at 13:46, Alexander Kanavin
> wrote:
> > I would
On Fri, 2019-06-14 at 15:05 +0200, Alexander Kanavin wrote:
> I guess the patch needs a small tweak so that swrast remains enabled,
> but becomes optional. Then Marco can set packageconfig exactly as he
> wants.
I guess if we can track down where the swrast dependency is coming and
and change thin
On Fri, 14 Jun 2019 at 13:46, Alexander Kanavin wrote:
> I would rather replace swrast with virgl in the qemu machine configs.
> Currently it's pulled in implicitly via the megadriver package which has
> virgl included because it is enabled by default in the mesa recipe. From what
> I can see b
I guess the patch needs a small tweak so that swrast remains enabled, but
becomes optional. Then Marco can set packageconfig exactly as he wants.
The second patch is fine as it is, I think. Only qemu implements virgl device
at the moment.
Alex
> On 14 Jun 2019, at 14.50, richard.pur...@linuxfo
On Fri, 2019-06-14 at 14:34 +0200, Marco Felsch wrote:
> On 19-06-14 13:11, richard.pur...@linuxfoundation.org wrote:
> > On Fri, 2019-06-14 at 14:04 +0200, Marco Felsch wrote:
> > > Anyway thats
> > > interessting. IMHO it isn't a good solution to rely on that fact
> > > that
> > > the package ha
I tend to agree with Marco: I am not sure there is a use case for swrast
anymore, not even as a fallback. About the only thing it is useful for is
glxgears. On real hardware you want the real driver without fallbacks, on
qemu you want virgl.
I would rather replace swrast with virgl in the qemu mac
On 19-06-14 13:11, richard.pur...@linuxfoundation.org wrote:
> On Fri, 2019-06-14 at 14:04 +0200, Marco Felsch wrote:
> > On 19-06-14 11:55, Richard Purdie wrote:
> > > On Thu, 2019-06-13 at 19:54 +0200, Marco Felsch wrote:
> > > > Most of the time we are compiling for embedded targets which have
>
On Fri, 2019-06-14 at 14:04 +0200, Marco Felsch wrote:
> On 19-06-14 11:55, Richard Purdie wrote:
> > On Thu, 2019-06-13 at 19:54 +0200, Marco Felsch wrote:
> > > Most of the time we are compiling for embedded targets which have
> > > dedicated hardware combinations. Enabling swrast by default isn'
Hi Richard,
On 19-06-14 11:55, Richard Purdie wrote:
> On Thu, 2019-06-13 at 19:54 +0200, Marco Felsch wrote:
> > Most of the time we are compiling for embedded targets which have
> > dedicated hardware combinations. Enabling swrast by default isn't a
> > good
> > solution for such devices because
On Thu, 2019-06-13 at 19:54 +0200, Marco Felsch wrote:
> Most of the time we are compiling for embedded targets which have
> dedicated hardware combinations. Enabling swrast by default isn't a
> good
> solution for such devices because if the hardware render node has an
> issue or doesn't support a
Sure, follow-up patch is fine with me.
On Thu, Jun 13, 2019 at 8:38 PM Marco Felsch
wrote:
> Hi Martin,
>
> On 19-06-13 20:17, Martin Jansa wrote:
> > Looks like nice cleanup, but is someone still using llvm 3.2 or older?
>
> I don't know but I learned to avoid breaking changes.
>
> > With PACKA
Hi Martin,
On 19-06-13 20:17, Martin Jansa wrote:
> Looks like nice cleanup, but is someone still using llvm 3.2 or older?
I don't know but I learned to avoid breaking changes.
> With PACKAGECONFIG for almost each gallium driver it might be easier to get
> rid
> of GALLIUMDRIVERS_LLVM33, GALLIUM
Looks like nice cleanup, but is someone still using llvm 3.2 or older?
With PACKAGECONFIG for almost each gallium driver it might be easier to get
rid
of GALLIUMDRIVERS_LLVM33, GALLIUMDRIVERS_LLVM33_ENABLED, GALLIUMDRIVERS_LLVM
variables and use just GALLIUMDRIVERS.
In worst case scenario people
Most of the time we are compiling for embedded targets which have
dedicated hardware combinations. Enabling swrast by default isn't a good
solution for such devices because if the hardware render node has an
issue or doesn't support a special format/request Mesa will fallback to
the software render
19 matches
Mail list logo
