Re: Testing direct rendering/more video cards with qemu?

[Svante Signell]

On Tue, 2020-11-17 at 14:22 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 11:41:52 +0100, a ecrit:
> > I managed to build more packages from mesa based on that libdrm is
> > now available. Is there any way to test these packages with qemu?
> 
> Which packages? Those mentioned below in your mail? They don't depend
> that much on the emulated hardware, and rather on the software being
> used.

Testing xorg with the other drivers than default? 

> > qemu-system-x86_64 --help shows
> > -vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none]
> >                 select video card type
> 
> Yes, that's basically all. Apart from the virtual devices meant for
> virtualization, qemu doesn't propose many virtual cards.

Not emulating any of the radeon/nvidia/etc graphics cards then. So Hurd
has to run on real hardware? That can maybe be possible when rumpdisk
is working properly!?

> > Which of these (and xorg* packages) are needed?
> 
> Needed for what?

For testing if some of the dri/drv drivers work on Hurd: e.g. r200,
r300 etc.

> > I had to make a dirty patch for non-linux of libva:va/va_trace.c
> > since gettid() or syscall(__NR_ttid) is not available on GNU/Hurd
> > (or GNU/kFreeBSD. Any ideas on how to make a workaround?
> > pthread_self() does not seem to work: See
> > http://clanguagestuff.blogspot.com/2013/08/gettid-vs-pthreadself.html
> 
> "work" wholy depends what it is used for. gettid is a very linuxish
> thing. What I read from va/va_trace.c looks like it could be very
> fine with using pthread_self().
> 
> (In general, relying on gettid() to provide non-reusable thread ids
> is nonsense: tids do wrap around as well).

So you mean that all calls to gettid() can be replaced with
pthread_self() for non-linux systems?

Thanks!