On 6/10/21 2:49 AM, Thomas Hellström (Intel) wrote:
Hi,
On 6/9/21 7:23 PM, Zack Rusin wrote:
The has_dx variable was only set during the initialization which
meant that UPDATE_SUBRESOURCE was never used. We were emulating it
with UPDATE_GB_IMAGE but that's always been a stop-gap. Instead
of has_dx which has been deprecated a long time ago we need to check
for whether shader model 4.0 or newer is available to the device.
Stupid question perhaps, but isn't UPDATE_SUBRESOURCE available with
SVGA_CAP_DX regardless of the SM capabilities of the underlying device?
It is, but the extra functionality it provides is a bit pointless on older
contexts. In general we're trying to bundle the features in something more
resembling the windows side, that's not for the purpose of the guest but host
side or more specifically so that the stack is more coherent and vmwgfx isn't
doing something uncommon (i.e. using dx10 features with CAP_DX but without
CAP_DXCONTEXT) where renderers might be asked to do something they've never
been tested for.
We've overloaded the shader model 4.0 naming though in ways that's not ideal, so
has_sm4_context really is CAP_DX & CAP_DXCONTEXT, we should've probably went
with has_d3d10_feature_level, has_d3d11_feature_level, has_gl43_feature_level etc
instead.
z
