[3/9] drm/vmwgfx: Fix subresource updates with new contexts

Commit Message

Zack Rusin June 9, 2021, 5:23 p.m. UTC

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.

Signed-off-by: Zack Rusin <[e-mail]>
Reviewed-by: Roland Scheidegger <[e-mail]>
Reviewed-by: Martin Krastev <[e-mail]>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Comments

Thomas Hellström (Intel) June 10, 2021, 6:49 a.m. UTC | #1

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?

Thanks,

Thomas

Zack Rusin June 10, 2021, 4:59 p.m. UTC | #2

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

Patch

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 0835468bb2ee..47c03a276515 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -1872,7 +1872,6 @@  static void vmw_surface_dirty_range_add(struct vmw_resource *res, size_t start,
 static int vmw_surface_dirty_sync(struct vmw_resource *res)
 {
 	struct vmw_private *dev_priv = res->dev_priv;
-	bool has_dx = 0;
 	u32 i, num_dirty;
 	struct vmw_surface_dirty *dirty =
 		(struct vmw_surface_dirty *) res->dirty;
@@ -1899,7 +1898,7 @@  static int vmw_surface_dirty_sync(struct vmw_resource *res)
 	if (!num_dirty)
 		goto out;
 
-	alloc_size = num_dirty * ((has_dx) ? sizeof(*cmd1) : sizeof(*cmd2));
+	alloc_size = num_dirty * ((has_sm4_context(dev_priv)) ? sizeof(*cmd1) : sizeof(*cmd2));
 	cmd = VMW_CMD_RESERVE(dev_priv, alloc_size);
 	if (!cmd)
 		return -ENOMEM;
@@ -1917,7 +1916,7 @@  static int vmw_surface_dirty_sync(struct vmw_resource *res)
 		 * DX_UPDATE_SUBRESOURCE is aware of array surfaces.
 		 * UPDATE_GB_IMAGE is not.
 		 */
-		if (has_dx) {
+		if (has_sm4_context(dev_priv)) {
 			cmd1->header.id = SVGA_3D_CMD_DX_UPDATE_SUBRESOURCE;
 			cmd1->header.size = sizeof(cmd1->body);
 			cmd1->body.sid = res->id;