https://bugs.documentfoundation.org/show_bug.cgi?id=160783
Julien Nabet <serval2...@yahoo.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikekagan...@hotmail.com,
| |noelgran...@gmail.com
--- Comment #4 from Julien Nabet <serval2...@yahoo.fr> ---
I kept digging and noticed this commit (2020-02-12)
2b702f7436acf6883b41508277441e5ea0a53d51
which includes this change:
static bool isVulkanBlacklisted(const VkPhysicalDeviceProperties& props)
{
static const char* const types[]
= { "other", "integrated", "discrete", "virtual", "cpu", "??" }; //
VkPhysicalDeviceType
+ OUString driverVersion = OUString::number(props.driverVersion >> 22) + "."
+ + OUString::number((props.driverVersion >> 12) &
0x3ff) + "."
+ + OUString::number(props.driverVersion & 0xfff);
+ OUString vendorId = "0x" + OUString::number(props.vendorID, 16);
+ OUString deviceId = "0x" + OUString::number(props.deviceID, 16);
SAL_INFO("vcl.skia",
"Vulkan API version: "
<< (props.apiVersion >> 22) << "." << ((props.apiVersion >>
12) & 0x3ff) << "."
- << (props.apiVersion & 0xfff) << ", driver version: "
- << (props.driverVersion >> 22) << "." <<
((props.driverVersion >> 12) & 0x3ff)
- << "." << (props.driverVersion & 0xfff) << std::hex << ",
vendor: 0x"
- << props.vendorID << ", device: 0x" << props.deviceID <<
std::dec
- << ", type: " << types[std::min<unsigned>(props.deviceType,
SAL_N_ELEMENTS(types))]
+ << (props.apiVersion & 0xfff) << ", driver version: " <<
driverVersion
+ << ", vendor: " << vendorId << ", device: " << deviceId << ",
type: "
+ << types[std::min<unsigned>(props.deviceType,
SAL_N_ELEMENTS(types) - 1)]
<< ", name: " << props.deviceName);
- return false;
+ return DriverBlocklist::IsDeviceBlocked(getBlacklistFile(), driverVersion,
vendorId, deviceId);
}
so before this commit, we used apiVersion, afterwards, we started to use
driverVersion.
For api version, Skia uses this macro:
#define VK_MAKE_VERSION(major, minor, patch) \
(((major) << 22) | ((minor) << 12) | (patch))
in addition with these:
#define VK_VERSION_MAJOR(version) ((uint32_t)(version) >> 22)
#define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
#define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
it corresponds well with the LO part:
146 static OUString versionAsString(uint32_t version)
147 {
148 return OUString::number(version >> 22) + "." +
OUString::number((version >> 12) & 0x3ff) + "."
149 + OUString::number(version & 0xfff);
150 }
but driverVersion uses this one:
#define GR_GL_DRIVER_VER(major, minor, point) ((static_cast<uint64_t>(major) <<
32) | \
(static_cast<uint64_t>(minor) <<
16) | \
static_cast<uint64_t>(point))
So I suppose LO should be adapted.
But a last thing, in Skia we got:
typedef struct VkPhysicalDeviceProperties {
uint32_t apiVersion;
uint32_t driverVersion;
uint32_t vendorID;
uint32_t deviceID;
VkPhysicalDeviceType deviceType;
char
deviceName[VK_MAX_PHYSICAL_DEVICE_NAME_SIZE];
uint8_t pipelineCacheUUID[VK_UUID_SIZE];
VkPhysicalDeviceLimits limits;
VkPhysicalDeviceSparseProperties sparseProperties;
} VkPhysicalDeviceProperties;
apiVersion is uint32_t ok, but driverVersion is uint64_t when reading the
macro.
So even if we change LO part, it seems there's a bug in Skia, doesn't it?
Noel/Mike: perhaps one of you might be interested in this one?
--
You are receiving this mail because:
You are the assignee for the bug.
