qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] AVX support for TCG


From: Nick Renieris
Subject: Re: [Qemu-devel] AVX support for TCG
Date: Sun, 30 Dec 2018 22:51:55 +0200

Στις Σάβ, 29 Δεκ 2018 στις 10:24 μ.μ., ο/η Richard Henderson
<address@hidden> έγραψε:
> I did have a beginner in mind when guessing 4 months.  Don't take that as a
> fully speced out answer, but it may well be that full avx2 support cannot be
> done within the 3 months of gsoc.  I would certainly expect avx512 to take 
> even
> longer.

Right, that's ok.
Bit of context, the reason I'm interested in this feature (other than
GSoC potential and general interest) is Orbital, a Sony PlayStation 4
emulator that implements a QEMU fork. Normally we use virtualization
as anything else would be too slow, but TCG would help with debugging
and such.
The PS4's APU doesn't support AVX2 or AVX-512 so I'd be fine if I
didn't have enough time to implement them.

> The tcg-op-gvec.h infrastructure allows for the different modes that avx+mmx
> allows:
>
> (1) 64-bit operations,
> (2) 128-bit operations, modifying only the low 128 bits,
> (3) 128-bit operations, zeroing bits beyond the first 128,
> (4) N*128-bit operations, zeroing bits beyond the first N*128.

I assume you mean 256-bit ops on (2) and (3), and N*256 on (4)? Low
128 bits of a 128-bit number is just the number.

> so we should not need a great proliferation of helper functions, merely a
> re-organization of what we have now.

So, I would need to implement every SSE instruction that isn't
SSE_SPECIAL at the moment, using tcg-op-gvec.h? Or more instructions
than that?

Assuming I do this for SSE and AVX, I would not need to touch anything
else like the TCG back-end, as every gvec/vec op is already
implemented for i386, correct?

PS: I'm 'vel0city' on IRC, if that'd be more convenient.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]