Mock ICD fails some simple operations

[null77]

The Mock ICD works well for a few simple use cases but breaks down on some workloads.

One simple example is allocating and writing to a buffer larger than 0x1000. This will trigger errors. I think handling arbitrary sizes should be something the Mock ICD should be able to support without too much trouble.

A second example is mapping memory ranges. After a first map call that writes to the data, the memory is discarded and subsequent map calls return junk data. It seems plausible for the Mock ICD to store some state associated with the device memory.

In both cases the application on top of the Mock ICD needs to know specifically that it is running on top of the mock ICD to work without errors. This seems counter to the intent of the mock ICD. It should be basically invisible apart from not executing commands.

@tobine @ShabbyX @y-novikov fyi

[tobine]

For historical context note that the original motivation for the Mock ICD was to allow validation layer tests to be run. That goal made cutting corners such as these reasonable.
Now that Mock ICD has spun into Tools repo by itself and is being used more broadly it makes sense to add these enhancements. Let me know if there's any time pressure, otherwise I've added this to my queue following some higher priority work.

[null77]

Yep, sounds good. Thanks Tobin.

[KarenGhavam-lunarG]

Now that swiftshader exists, it probably makes more sense to see if that path is a solution.

The Mock ICD was not ever intended for the use case of this original issue.

[null77]

Hey Karen,

SwiftShader's current set of uses do not include making a mock ICD. The Mock ICD could more easily be extended to cover a slightly more robust use case than SwiftShader could be reorganized to support dropping command streams. I think we should leave this open as a feature request as there's a pretty solid need for a mock ICD in the ecosystem.

[KarenGhavam-lunarG]

Ok. I will leave open for now.

[null77]

Thank you!

[rumblehhh]

Has there been anymore recent investigation into any of the limitations of the Mock ICD that @null77 pointed out?

A second example is mapping memory ranges. After a first map call that writes to the data, the memory is discarded and subsequent map calls return junk data. It seems plausible for the Mock ICD to store some state associated with the device memory.

This seems to play havoc when combined with VMAs VMA_DEBUG_DETECT_CORRUPTION feature which wasn't immediately obvious

[charles-lunarg]

Unfortunately no, I haven't had time to modify Mock ICD since my focus has been on the loader.
I'd be happy to review/accept any PR's that come in however.