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

[Samuel Thibault]

Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit:
> 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? 

But you need hardware (virtual or physical) to run these drivers
again.

> > > 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?

? No
The std and cirrus drivers work just fine with qemu.

> That can maybe be possible when rumpdisk is working properly!?

That has nothing to do at all with disks.

> > > 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.

dri cannot work. You changes in libdrm only introduced some stub
interface. Actual drm implementation is needed to get any kind of direct
rendering working

> > (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?

Even for Linux system that should just work well enough.
And theorically not worse that gettid(), actually.

Samuel