FIFO is re-initialized while vmx is processing it. To fix this issue,
I suggest metalkit SVGA_SetMode should handle mode transitions and
new function SVGA_Enable should initialize the FIFO.
Otherwise the bunnies are all black with the D3D backend and the
software renderer backend.
GL backend apparently interprets a zero light range differently, and
draws them white even without this change.
but couldn't release immediately since they depended on virtual GPU features
which were not yet publicly released in any products. This checkin moves those
features from our internal repository to the open source repository. Future
development on these tests and examples will take place directly in the open
source repository.
The primary feature added by this patch is 'Screen Object', a new dynamic
display management extension supported by Workstation 7.0 and Fusion 3.0.
See the README for a quick explanation.
Newer versions of GCC have additional strict alias checking,
and so the refdriver's IRQ handler would fail to compile.
Work around this problem (and avoid unwanted compiler
optimizations to boot) by using memcpy instead of struct
assignment.
There's been a longstanding bug in the IRQ handling code
in the Metalkit version of the SVGA reference driver, which
occasionally caused tests to hang.
I looked at the disassembly of SVGA_WaitForIRQ and friends, and
I found one big problem and one smaller problem:
The 'switchContext' flag is used to tell the IRQ handler
whether it should branch to the saved context or not. This
value *must* be written before we halt, or we can deadlock.
Unfortunately, the value wasn't marked as 'volatile', and the
compiler was optimizing out this assignment entirely! This
means that 'flags' will never get set, and we'll be in an
infinite loop.
Given this bug, I'm not sure why WaitForIRQ ever worked.
It's possible that we were fine if the IRQ had already arrived
by the time WaitForIRQ was called, but we'd deadlock if we
actually ended up waiting. If this is the case, it also means
that fence-stress isn't doing a very good job of stressing the
IRQ code.
The other, much less severe problem: The stack frames for
WaitForIRQInternal and SaveContext may have been partially
overlapping, since gcc was allocating 0x10 bytes on the
stack before calling SaveContext. The proper solution is
probably just to rewrite all of this in assembly, but for
now I just increased the number of padding words on the
stack by adding extra NULL parameters to WaitForIRQInternal.
