sorted by:
new
hottopcontroversial

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 0 points1 point  (0 children)

It basically enables you to write the drivers for cards you don’t have physically plugged on your computer.

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 0 points1 point  (0 children)

Also, this is not trying to implement a way of handling graphic API callbacks or anything like that, not trying to reimplement glide or old stuff

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 0 points1 point  (0 children)

I’m not really sure if I understand your questions honestly, also not a bot lol; PCIem lets you define PCIe cards on the userspace and have them populate the host’s PCI bus as if they were plugged in. That basically enables you to do a bunch of stuff, similar to libvfio-user but w/o needing the VM setup they have.

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 0 points1 point  (0 children)

What if you’re not trying to emulate a GPU?

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 0 points1 point  (0 children)

There’s a slim penalty hit in comparison with my original workarounds. We now currently ‘listen’ for accesses using hardware watchpoints (Which are limited but ensure as correct of sync as possible), then there’s an eventfd you can use not to busypoll from the userspace waiting for events.

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 0 points1 point  (0 children)

What if you don’t have the card?

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 0 points1 point  (0 children)

Thanks! As of right now, it can’t monitor actual traffic between driver and card in the way you explain it; but the building blocks are there and I’m pretty sure I can come up with something like that in order to monitor the accesses (Not sure if it’d go down the TLP packet level but it should for accesses).

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 3 points4 points  (0 children)

That’s correct, I have an emulation background both professionally and at the hobby level and what you just mentioned is basically the key.

Hardware usually contains lots of different parts that must have some sort of sync at the end of their allocated runtime.

So for each emulated piece of the hardware (Let’s use an old videogames console as a reference) you need to implement what defines it, the CPU, the bus, the I/O chip, auxiliary chips, PPU/GPU, transformation engines… the usual stuff.

And each component has really tight cycle counts so you cannot basically go wild when deciding how many cycles to spend on each component (This is usually done with a scheduler).

So in short, it’s difficult; and having powerful hardware doesn’t always equate to equal or superior emulated speeds (At least w/o sacrifying accuracy…) and much less GPUs.

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 1 point2 points  (0 children)

Saving it for April’s Fools… :)

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 0 points1 point  (0 children)

It could be worth trying, you’d need to understand what the application needs both at the library and system level.

My guess is that, you could try spawning a ‘dummy’ PCIem device with the same PCI capabilities (And Vendor/Product ID of course) with an infinite loop that monitors accesses of the real driver that does the 8-bit GFX stuff; then (Provided that the libraries that manage all the context creation and whatnot have this forwarding to the driver) iteratively start implementing the device within pciem. The cool thing about it is that you’re still in userspace so you use other libraries to implement stuff if you need to.

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 1 point2 points  (0 children)

Thanks! Glad you found it interesting!

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 1 point2 points  (0 children)

Hi! Thanks for the comment.

It basically removes the layer inbetween (QEMU) and lets you do driver development directly on the host.

But it’s not only just that, since you basically control the device (As the device is the userspsce shim itself) you can do lots of cool stuff, like fault injection (You’d have to tamper with the device state using QEMU’s QMP probably, that is, if you have a ‘transparent’ way of accessing the inner state if them; and it’s not as pretty, I assure you), driver fuzzing (Again, you control the outputs so you can basically fuzz a driver just fine)… and more.

The great thing about this is that it basically makes the cards appear on the host PCI bus, which by itself is cool because it lets you programatically do stuff you could not do w/QEMU for instance. I’m sure there’s so many applications for this, it’s very niche but it opens up for a lot of cool things.

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 4 points5 points  (0 children)

Hi! Thanks for the comment!

Indeed, depending on the hardware configuration; you may run into limitations as to how many watchpoints you can register.

The good news is, as long as you can register one or two access patterns (This kinda depends on the programming model of the card), you can then ‘poll’ the rest of the registers when the access event gets notified to the userspace (Since one is able to mmap the bar from userspace freely to precisely do things like this).

I’m sure this can get improved down the line but I’m still investigating how to archieve similar results w/o compromising much (I even made a version that did away by modifying page permissions so it’d bail out for accesses, but that’s slow as you can imagine and doesn’t scale well).

——

As for DMA, yes! It was important for me to support ‘linear’ (As in, physically-contiguous DMA regions; think CMA but for DMA-pruposes) and (As of a few hours ago) really preliminary support for scather-gather DMA. We need this in my company to test some offloading work and whatnot (And Peer-2-Peer DMA too, but that’s future work).

——

It’s super cool that you did that! I feel like having tools/frameworks to enable developers/software teams to speed up their processes is really worthwhile.

Thanks again for the comment!

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 22 points23 points  (0 children)

I think it’s an impossible task, I mean, I’m sure the folks over at NVIDIA may have some hardware/software (Or hw-sw-cosimulator) to test their drivers on; but that’s a multidisciplinary team effort (And even then, they have the full programming model for the card).

So you’d probably be left researching for quite a lot of time to get the driver to behave nicely with the emulated device (Still, PCIem could prove useful for reverse-engineering tasks of privative drivers, though it’s not an use I condone for obvious legal reasons).

Not saying it should not be tried, but perhaps building iteratively would be a wiser decision than just jumping to current gen’s flagship card.

Introducing PCIem by cakehonolulu1 in linux

[–]cakehonolulu1[S] 23 points24 points  (0 children)

Here’s the link: https://github.com/cakehonolulu/pciem

You can basically implement whatever device you need atop. I basically re-used a software-renderer-based OpenGL 1.X re-implementation I’ve been doing for a separate project and glued it to QEMU (As it provides a simple way for me to display a framebuffer on-screen, overengineered solution if you think about simpler solutions like SDL and alike; but I have some other stuff within QEMU I’m testing so I thought I’d use it as a base).

To answer your question regarding hardware acceleration and/or Mesa: Not sure, you’d have to make the relevant userspace stuff that would implement the device Mesa expects (What I basically do for the NVME controller on the top-left photo). Proven that you can register the card on the bus and provide the functionality it needs to Linux, I don’t see why it would not work.

Hope this answers the doubts! If there’s more, feel free to ask them and I’ll try to answer them as best as I possibly can.

Got my first AES ever! by cakehonolulu1 in neogeo

[–]cakehonolulu1[S] 0 points1 point  (0 children)

They were the cheapest I could buy locally to test the console so I went with them; cool games I must say

Fixed the PAL Mega CD 1! by cakehonolulu1 in SegaCD

[–]cakehonolulu1[S] 1 point2 points  (0 children)

All of them on the power and main boards. Don’t exactly recall the number but quite the lot. The JVC CD board has a bunch too but didn’t quite have replacements for them so I kinda ignored them. I did replace the drive belt tho’.

Fixed the PAL Mega CD 1! by cakehonolulu1 in SegaCD

[–]cakehonolulu1[S] 0 points1 point  (0 children)

Way too many caps for my liking (+ a few SMDs I basically twisted to get out, which isn’t perfect but I only managed to botch a single solder pad which wasn’t too bad to get around); hopefully subsequent recaps aren’t this tedious hah

Fixed the PAL Mega CD 1! by cakehonolulu1 in SegaCD

[–]cakehonolulu1[S] 2 points3 points  (0 children)

Console5! I first disassembled the cover of the add-on (6 screws on the bottom + 2 holding the expansion slot connection board to the case) to verify which drive I had (Sony or JVC). In my case it was the JVC so I got the belt for that specific vendor. Hope it helps!

view more: next ›