On Sat, 23 Feb 2019 at 23:30, Adrian Bunk wrote:
> > Probably this is the very first time virgl is built for mips :-)
> >...
>
> Builds fine in Debian:
> https://buildd.debian.org/status/package.php?p=virglrenderer
They don't apply special patches either:
On Fri, Feb 22, 2019 at 08:11:27PM +0100, Alexander Kanavin wrote:
> Probably this is the very first time virgl is built for mips :-)
>...
Builds fine in Debian:
https://buildd.debian.org/status/package.php?p=virglrenderer
> Alex
cu
Adrian
--
"Is there not promise of rain?" Ling Tan
On Sat, 2019-02-23 at 11:57 -0800, Khem Raj wrote:
> On Sat, Feb 23, 2019 at 10:07 AM Richard Purdie
> wrote:
> > On Sat, 2019-02-23 at 09:56 -0800, Khem Raj wrote:
> > > On Fri, Feb 22, 2019 at 11:11 AM Alexander Kanavin
> > > wrote:
> > > > Probably this is the very first time virgl is built
On Sat, Feb 23, 2019 at 10:07 AM Richard Purdie
wrote:
>
> On Sat, 2019-02-23 at 09:56 -0800, Khem Raj wrote:
> > On Fri, Feb 22, 2019 at 11:11 AM Alexander Kanavin
> > wrote:
> > > Probably this is the very first time virgl is built for mips :-)
> > >
> > > Note that it is useful only if you
On Sat, 2019-02-23 at 09:56 -0800, Khem Raj wrote:
> On Fri, Feb 22, 2019 at 11:11 AM Alexander Kanavin
> wrote:
> > Probably this is the very first time virgl is built for mips :-)
> >
> > Note that it is useful only if you intend to run qemu on that
> > platform, so I wonder if we could just
On Fri, Feb 22, 2019 at 11:11 AM Alexander Kanavin
wrote:
>
> Probably this is the very first time virgl is built for mips :-)
>
> Note that it is useful only if you intend to run qemu on that
> platform, so I wonder if we could just blacklist it...
>
I would have thought world build should have
Probably this is the very first time virgl is built for mips :-)
Note that it is useful only if you intend to run qemu on that
platform, so I wonder if we could just blacklist it...
Alex
On Fri, 22 Feb 2019 at 19:54, Khem Raj wrote:
>
> https://errors.yoctoproject.org/Errors/Details/229902/
>
https://errors.yoctoproject.org/Errors/Details/229902/
mips/glibc
On Fri, Feb 22, 2019 at 6:34 AM Alexander Kanavin
wrote:
>
> This component enables hardware-accelerated GL inside QEMU guests.
> For more information, see here:
>
> https://lwn.net/Articles/767970/
>
This component enables hardware-accelerated GL inside QEMU guests.
For more information, see here:
https://lwn.net/Articles/767970/
https://www.collabora.com/news-and-blog/blog/2018/02/12/virtualizing-gpu-access/
https://www.collabora.com/news-and-blog/blog/2018/05/09/gpu-virtualization-update/
Anyway, I sent it upstream:
https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/153
and added to my branch on poky-contrib.
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/virgl-gtk
Alex
On Mon, 11 Feb 2019 at 16:24, Khem Raj wrote:
>
> here is a build failure
here is a build failure with -fuse-ld=gold
https://errors.yoctoproject.org/Errors/Details/222046/
On Sat, Feb 9, 2019 at 9:23 AM Khem Raj wrote:
>
> dump ld.bfd generated .so and see if this symbol is present
>
> On Sat, Feb 9, 2019 at 5:20 AM Martin Jansa wrote:
> >
> > On Sat, Feb 09, 2019
dump ld.bfd generated .so and see if this symbol is present
On Sat, Feb 9, 2019 at 5:20 AM Martin Jansa wrote:
>
> On Sat, Feb 09, 2019 at 11:06:47AM +0100, Alexander Kanavin wrote:
> > On Sat, 9 Feb 2019 at 10:44, Martin Jansa wrote:
> > > Does it need to depend on mesa directly instead of one
On Sat, 9 Feb 2019 at 18:10, Martin Jansa wrote:
>
> It was sent to upstream (somewhere) by the original author, I haven't found
> it on gitlab, so I've asked original author in:
> https://bugs.gentoo.org/571124#c5
Maybe a new merge request is the quickest way to sort this. The patch
was
It was sent to upstream (somewhere) by the original author, I haven't found
it on gitlab, so I've asked original author in:
https://bugs.gentoo.org/571124#c5
Plain poky probably doesn't use gold, that's why you're not seeing it there.
On Sat, Feb 9, 2019 at 5:43 PM Alexander Kanavin
wrote:
>
On Sat, 9 Feb 2019 at 14:19, Martin Jansa wrote:
> The fix from
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/qemu=c29d4ccfe0a5f53c49883e55c2c2bb444997b1cf
> is still applicable and fixes this.
Somehow the issue does not show up in plain poky, but the fix seems
right.
On Sat, Feb 09, 2019 at 11:06:47AM +0100, Alexander Kanavin wrote:
> On Sat, 9 Feb 2019 at 10:44, Martin Jansa wrote:
> > Does it need to depend on mesa directly instead of one of virtual/*
> > providers?
> >
> > It fails to build for targets which use different mesa, e.g. mesa-gl:
> >
> > ERROR:
On Sat, 9 Feb 2019 at 10:44, Martin Jansa wrote:
> Does it need to depend on mesa directly instead of one of virtual/*
> providers?
>
> It fails to build for targets which use different mesa, e.g. mesa-gl:
>
> ERROR: Nothing PROVIDES 'mesa' (but
>
On Fri, Feb 08, 2019 at 03:45:42PM +0100, Alexander Kanavin wrote:
> This component enables hardware-accelerated GL inside QEMU guests.
> For more information, see here:
>
> https://lwn.net/Articles/767970/
> https://www.collabora.com/news-and-blog/blog/2018/02/12/virtualizing-gpu-access/
>
This component enables hardware-accelerated GL inside QEMU guests.
For more information, see here:
https://lwn.net/Articles/767970/
https://www.collabora.com/news-and-blog/blog/2018/02/12/virtualizing-gpu-access/
https://www.collabora.com/news-and-blog/blog/2018/05/09/gpu-virtualization-update/
19 matches
Mail list logo
