ic
/
magnum
mirror of https://github.com/mosra/magnum.git
6
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
9464 Commits
21 Branches
19 Tags
70 MiB
Tree: 63cb469b29
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '63cb469b29'
${ noResults }
magnum/src/Magnum/Vk/Test/DeviceVkTest.cpp

1226 lines
54 KiB
Raw Normal View History Unescape

Vk: device creation.
6 years ago
/*
This file is part of Magnum.
Copyright © 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019,
Updated copyright year.
5 years ago
2020, 2021 Vladimír Vondruš <mosra@centrum.cz>
Vk: device creation.
6 years ago
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
*/
#include <sstream>
Vk: rework {Extension,Layer}Properties internals using ArrayTuple. These were implemented long before ArrayTuple was a thing and while the allocation saving optimization makes sense, the implementation is way too error prone. This also means Array (and thus <new> and other heavy shit) isn't included in the headers, which leads to further slimming of compile times across the library.
6 years ago
#include <Corrade/Containers/Array.h>
Vk: DeviceCreateInfo::addQueues() overload taking QueueFlags directly. More convenient to use since one doesn't have to explicitly store a DeviceProperties instance to call pickQueueFamily() on it and then move it to DeviceCreateInfo to keep it efficient. This required a slight redesign of how DeviceProperties are stored in DeviceCreateInfo, now we need the instance to be always valid (but it can get never used). The wrap() API isn't doing any extra work so this won't add any inefficiency.
6 years ago
#include <Corrade/Containers/Optional.h>
Vk: device creation.
6 years ago
#include <Corrade/Containers/StringStl.h>
#include <Corrade/TestSuite/Compare/Numeric.h>
#include <Corrade/Utility/DebugStl.h>
#include <Corrade/Utility/FormatStl.h>
Vk: put CreateInfo structures to dedicated headers. After I implemented the render pass wrapper, seeing how the RenderPassCreateInfo structure and its dependencies were HUGE compared to the actual tiny and lean RenderPass, I felt uneasy dragging their definition along to every place where a RenderPass gets used. It's not as bad with the others, but as new extensions are implemented I expect that to get the same. This change makes it easier for me to accept that Image.h / Buffer.h depends on Memory.h. There isn't a real measurable difference when building Magnum itself (50 ms out of 7 seconds for the Vk library alone), but that's because most of the code (and tests) needs the CreateInfo structures anyway.
5 years ago
#include "Magnum/Vk/DeviceCreateInfo.h"
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
#include "Magnum/Vk/DeviceFeatures.h"
Vk: device creation.
6 years ago
#include "Magnum/Vk/DeviceProperties.h"
#include "Magnum/Vk/Extensions.h"
#include "Magnum/Vk/ExtensionProperties.h"
#include "Magnum/Vk/Handle.h"
Vk: put CreateInfo structures to dedicated headers. After I implemented the render pass wrapper, seeing how the RenderPassCreateInfo structure and its dependencies were HUGE compared to the actual tiny and lean RenderPass, I felt uneasy dragging their definition along to every place where a RenderPass gets used. It's not as bad with the others, but as new extensions are implemented I expect that to get the same. This change makes it easier for me to accept that Image.h / Buffer.h depends on Memory.h. There isn't a real measurable difference when building Magnum itself (50 ms out of 7 seconds for the Vk library alone), but that's because most of the code (and tests) needs the CreateInfo structures anyway.
5 years ago
#include "Magnum/Vk/InstanceCreateInfo.h"
Vk: device creation.
6 years ago
#include "Magnum/Vk/LayerProperties.h"
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
#include "Magnum/Vk/Queue.h"
Vk: device creation.
6 years ago
#include "Magnum/Vk/Result.h"
#include "Magnum/Vk/Version.h"
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
#include "Magnum/Vk/VulkanTester.h"
Vk: device creation.
6 years ago
Vk: expose and implement KHR_portability_subset.
5 years ago
#include "Magnum/Vk/Implementation/DeviceFeatures.h"
/* for deviceFeaturesPortabilitySubset() */
Vk: device creation.
6 years ago
#include "MagnumExternal/Vulkan/flextVkGlobal.h"
namespace Magnum { namespace Vk { namespace Test { namespace {
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
struct DeviceVkTest: VulkanTester {
Vk: device creation.
6 years ago
explicit DeviceVkTest();
void createInfoConstruct();
void createInfoConstructNoImplicitExtensions();
void createInfoExtensions();
Vk: rename DeviceVkTest test case for clarity. Was copied from InstanceVkTest where it's for both layers and extensions. Not here.
5 years ago
void createInfoExtensionsCopiedStrings();
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
void createInfoFeatures();
void createInfoFeaturesReplaceExternal();
void createInfoFeaturesReplacePrevious();
void createInfoFeaturesEnableAllResetAll();
void createInfoFeaturesNothingInCoreFeatures();
Vk: device creation.
6 years ago
void createInfoNoQueuePriorities();
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
void createInfoWrongQueueOutputCount();
Vk: DeviceCreateInfo wasn't properly movable. Interestingly I didn't run into this until now. Doing what I just learned while implementing the RenderPass.
5 years ago
void createInfoConstructCopy();
void createInfoConstructMove();
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
void createInfoRvalue();
Vk: device creation.
6 years ago
void construct();
Vk: DeviceCreateInfo::addQueues() overload taking QueueFlags directly. More convenient to use since one doesn't have to explicitly store a DeviceProperties instance to call pickQueueFamily() on it and then move it to DeviceCreateInfo to keep it efficient. This required a slight redesign of how DeviceProperties are stored in DeviceCreateInfo, now we need the instance to be always valid (but it can get never used). The wrap() API isn't doing any extra work so this won't add any inefficiency.
6 years ago
void constructQueueFromFlags();
Vk: device creation.
6 years ago
void constructExtensions();
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
void constructFeatures();
void constructFeaturesFromExtensions();
Vk: Device(..., const DeviceCreateInfo&) wasn't covered. Interestingly enough, apparently I was always constructing it in-place in the Device constructor. Which leads me to the next issue...
5 years ago
void constructDeviceCreateInfoConstReference();
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
void constructTransferDeviceProperties();
Vk: device creation.
6 years ago
void constructExtensionsCommandLineDisable();
void constructExtensionsCommandLineEnable();
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
void constructWorkaroundsCommandLineDisable();
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
void constructMultipleQueues();
void constructRawQueue();
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
void constructFeatureNotSupported();
void constructFeatureWithoutExtension();
Vk: device creation.
6 years ago
void constructNoQueue();
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
Vk: expose and implement KHR_portability_subset.
5 years ago
void constructNoPortability();
void constructNoPortabilityEnablePortabilityFeatures();
void constructPortability();
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
void tryCreateAlreadyCreated();
void tryCreateUnknownExtension();
Vk: device creation.
6 years ago
void wrap();
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
void wrapAlreadyCreated();
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
Vk: device creation.
6 years ago
void populateGlobalFunctionPointers();
};
struct {
const char* nameDisable;
const char* nameEnable;
Containers::Array<const char*> argsDisable, argsEnable;
bool driverVersionSupported, debugMarkerEnabled, maintenance1Enabled;
const char* log;
} ConstructCommandLineData[] {
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
/* Shouldn't print anything about device/version, enabled layers/exts if
quiet output is enabled. */
Vk: device creation.
6 years ago
{"quiet", "quiet, enabled extensions",
Containers::array({"", "--magnum-log", "quiet"}),
Containers::array({"", "--magnum-log", "quiet",
"--magnum-enable-extensions", "VK_EXT_debug_marker VK_KHR_maintenance1"}),
true, true, true,
""},
{"", "enabled extensions", nullptr,
Containers::array({"",
"--magnum-enable-extensions", "VK_EXT_debug_marker VK_KHR_maintenance1"}),
true, true, true,
Vk: print also driver info in Device creation log. Just the device alone isn't enough if we can have multiple drivers for it.
4 years ago
"Device: {}, Vulkan {}.{}{}\n"
"Device driver: {}, {}\n"
Vk: device creation.
6 years ago
"Enabled device extensions:\n"
" VK_EXT_debug_marker\n"
" VK_KHR_maintenance1\n"},
{"forced version", "forced version, enabled extensions",
Containers::array({"",
"--magnum-vulkan-version", "1.0"}),
Containers::array({"",
"--magnum-vulkan-version", "1.0",
"--magnum-enable-extensions", "VK_EXT_debug_marker VK_KHR_maintenance1"}),
false, true, true,
Vk: print also driver info in Device creation log. Just the device alone isn't enough if we can have multiple drivers for it.
4 years ago
"Device: {}, Vulkan 1.0\n"
"Device driver: {4}, {5}\n"
Vk: device creation.
6 years ago
"Enabled device extensions:\n"
" VK_EXT_debug_marker\n"
" VK_KHR_maintenance1\n"},
{"disabled one extension", "enabled one extension",
Containers::array({"",
"--magnum-disable-extensions", "VK_EXT_debug_marker"}),
Containers::array({"",
"--magnum-enable-extensions", "VK_KHR_maintenance1"}),
true, false, true,
Vk: print also driver info in Device creation log. Just the device alone isn't enough if we can have multiple drivers for it.
4 years ago
"Device: {}, Vulkan {}.{}{}\n"
"Device driver: {}, {}\n"
Vk: device creation.
6 years ago
"Enabled device extensions:\n"
" VK_KHR_maintenance1\n"},
{"disabled extensions", "",
Containers::array({"",
"--magnum-disable-extensions", "VK_EXT_debug_marker VK_KHR_maintenance1"}),
nullptr,
true, false, false,
Vk: print also driver info in Device creation log. Just the device alone isn't enough if we can have multiple drivers for it.
4 years ago
"Device: {}, Vulkan {}.{}{}\n"
"Device driver: {}, {}\n"},
Vk: device creation.
6 years ago
};
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
struct {
const char* name;
bool shouldPassAlways;
Containers::Array<const char*> args;
const char* log;
} ConstructWorkaroundsCommandLineData[] {
Vk: work around crashy vkGetDeviceQueue2() on SwiftShader.
4 years ago
{"default", false,
Containers::array({"",
/* Have to force version to 1.0 because on 1.1 SwiftShader requires
the "swiftshader-crashy-getdevicequeue2" workaround, they can't
be all disabled */
"--magnum-vulkan-version", "1.0"}),
"Device: {}, Vulkan 1.0\n"
Vk: print also driver info in Device creation log. Just the device alone isn't enough if we can have multiple drivers for it.
4 years ago
"Device driver: {}, {}\n"
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
"Using device driver workarounds:\n"
Vk: patch SPIR-V binaries on load on SwiftShader as a workaround. The things I get to do here. Wow.
5 years ago
" swiftshader-image-copy-extent-instead-of-layers\n"
" swiftshader-spirv-multi-entrypoint-conflicting-locations\n"},
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
/* Shouldn't print anything if quiet output is enabled */
{"quiet", true,
Containers::array({"",
"--magnum-log", "quiet"}),
""},
{"disabled workarounds", true,
Containers::array({"",
Vk: work around crashy vkGetDeviceQueue2() on SwiftShader.
4 years ago
/* Have to force version to 1.0 because on 1.1 SwiftShader requires
the "swiftshader-crashy-getdevicequeue2" workaround, they can't
be all disabled */
"--magnum-vulkan-version", "1.0",
Vk: patch SPIR-V binaries on load on SwiftShader as a workaround. The things I get to do here. Wow.
5 years ago
"--magnum-disable-workarounds", "swiftshader-image-copy-extent-instead-of-layers swiftshader-spirv-multi-entrypoint-conflicting-locations"}),
Vk: work around crashy vkGetDeviceQueue2() on SwiftShader.
4 years ago
"Device: {}, Vulkan 1.0\n"
Vk: print also driver info in Device creation log. Just the device alone isn't enough if we can have multiple drivers for it.
4 years ago
"Device driver: {}, {}\n"}
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
};
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
DeviceVkTest::DeviceVkTest(): VulkanTester{NoCreate} {
Vk: device creation.
6 years ago
addTests({&DeviceVkTest::createInfoConstruct,
&DeviceVkTest::createInfoConstructNoImplicitExtensions,
&DeviceVkTest::createInfoExtensions,
Vk: rename DeviceVkTest test case for clarity. Was copied from InstanceVkTest where it's for both layers and extensions. Not here.
5 years ago
&DeviceVkTest::createInfoExtensionsCopiedStrings,
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
&DeviceVkTest::createInfoFeatures,
&DeviceVkTest::createInfoFeaturesReplaceExternal,
&DeviceVkTest::createInfoFeaturesReplacePrevious,
&DeviceVkTest::createInfoFeaturesEnableAllResetAll,
&DeviceVkTest::createInfoFeaturesNothingInCoreFeatures,
Vk: device creation.
6 years ago
&DeviceVkTest::createInfoNoQueuePriorities,
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
&DeviceVkTest::createInfoWrongQueueOutputCount,
Vk: DeviceCreateInfo wasn't properly movable. Interestingly I didn't run into this until now. Doing what I just learned while implementing the RenderPass.
5 years ago
&DeviceVkTest::createInfoConstructCopy,
&DeviceVkTest::createInfoConstructMove,
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
&DeviceVkTest::createInfoRvalue,
Vk: device creation.
6 years ago
&DeviceVkTest::construct,
Vk: DeviceCreateInfo::addQueues() overload taking QueueFlags directly. More convenient to use since one doesn't have to explicitly store a DeviceProperties instance to call pickQueueFamily() on it and then move it to DeviceCreateInfo to keep it efficient. This required a slight redesign of how DeviceProperties are stored in DeviceCreateInfo, now we need the instance to be always valid (but it can get never used). The wrap() API isn't doing any extra work so this won't add any inefficiency.
6 years ago
&DeviceVkTest::constructQueueFromFlags,
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
&DeviceVkTest::constructExtensions,
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
&DeviceVkTest::constructFeatures,
&DeviceVkTest::constructFeaturesFromExtensions,
Vk: Device(..., const DeviceCreateInfo&) wasn't covered. Interestingly enough, apparently I was always constructing it in-place in the Device constructor. Which leads me to the next issue...
5 years ago
&DeviceVkTest::constructDeviceCreateInfoConstReference,
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
&DeviceVkTest::constructTransferDeviceProperties});
Vk: device creation.
6 years ago
addInstancedTests({&DeviceVkTest::constructExtensionsCommandLineDisable,
&DeviceVkTest::constructExtensionsCommandLineEnable},
Containers::arraySize(ConstructCommandLineData));
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
addInstancedTests({&DeviceVkTest::constructWorkaroundsCommandLineDisable},
Containers::arraySize(ConstructWorkaroundsCommandLineData));
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
addTests({&DeviceVkTest::constructMultipleQueues,
&DeviceVkTest::constructRawQueue,
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
&DeviceVkTest::constructFeatureNotSupported,
&DeviceVkTest::constructFeatureWithoutExtension,
Vk: device creation.
6 years ago
&DeviceVkTest::constructNoQueue,
Vk: expose and implement KHR_portability_subset.
5 years ago
&DeviceVkTest::constructNoPortability,
&DeviceVkTest::constructNoPortabilityEnablePortabilityFeatures,
&DeviceVkTest::constructPortability,
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
&DeviceVkTest::tryCreateAlreadyCreated,
&DeviceVkTest::tryCreateUnknownExtension,
Vk: device creation.
6 years ago
&DeviceVkTest::wrap,
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
&DeviceVkTest::wrapAlreadyCreated,
Vk: device creation.
6 years ago
&DeviceVkTest::populateGlobalFunctionPointers});
}
using namespace Containers::Literals;
void DeviceVkTest::createInfoConstruct() {
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
DeviceCreateInfo info{pickDevice(instance())};
Vk: device creation.
6 years ago
CORRADE_VERIFY(info->sType);
CORRADE_VERIFY(!info->pNext);
/* Extensions might or might not be enabled */
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
CORRADE_VERIFY(!info->pEnabledFeatures);
Vk: device creation.
6 years ago
}
void DeviceVkTest::createInfoConstructNoImplicitExtensions() {
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
DeviceCreateInfo info{pickDevice(instance()), DeviceCreateInfo::Flag::NoImplicitExtensions};
Vk: device creation.
6 years ago
CORRADE_VERIFY(info->sType);
CORRADE_VERIFY(!info->pNext);
/* No extensions enabled as we explicitly disabled that */
CORRADE_VERIFY(!info->ppEnabledExtensionNames);
CORRADE_COMPARE(info->enabledExtensionCount, 0);
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
CORRADE_VERIFY(!info->pEnabledFeatures);
Vk: device creation.
6 years ago
}
void DeviceVkTest::createInfoExtensions() {
if(std::getenv("MAGNUM_DISABLE_EXTENSIONS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_EXTENSIONS environment variable set");
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
DeviceCreateInfo info{pickDevice(instance()), DeviceCreateInfo::Flag::NoImplicitExtensions};
Vk: device creation.
6 years ago
CORRADE_VERIFY(!info->ppEnabledExtensionNames);
CORRADE_COMPARE(info->enabledExtensionCount, 0);
info.addEnabledExtensions<Extensions::KHR::maintenance1>();
CORRADE_VERIFY(info->ppEnabledExtensionNames);
CORRADE_COMPARE(info->enabledExtensionCount, 1);
/* The pointer should be to the global data */
CORRADE_COMPARE(static_cast<const void*>(info->ppEnabledExtensionNames[0]),
Extensions::KHR::maintenance1::string().data());
info.addEnabledExtensions({
Extensions::KHR::draw_indirect_count{},
Extensions::KHR::get_memory_requirements2{}
});
CORRADE_COMPARE(info->enabledExtensionCount, 3);
/* The pointer should be to the global data */
CORRADE_COMPARE(static_cast<const void*>(info->ppEnabledExtensionNames[0]),
Extensions::KHR::maintenance1::string().data());
CORRADE_COMPARE(static_cast<const void*>(info->ppEnabledExtensionNames[1]),
Extensions::KHR::draw_indirect_count::string().data());
CORRADE_COMPARE(static_cast<const void*>(info->ppEnabledExtensionNames[2]),
Extensions::KHR::get_memory_requirements2::string().data());
}
Vk: rename DeviceVkTest test case for clarity. Was copied from InstanceVkTest where it's for both layers and extensions. Not here.
5 years ago
void DeviceVkTest::createInfoExtensionsCopiedStrings() {
Vk: VK_KHR_create_renderpass depends on KHR_maintenance2 and multiview. The validation layer complained. So enable these two implicitly as well if we're on 1.0. And since those are now disabled in certain test runs to test related code paths, DeviceVkTest needs to be updated to skip affected tests if this happens.
5 years ago
if(std::getenv("MAGNUM_DISABLE_EXTENSIONS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_EXTENSIONS environment variable set");
Vk: device creation.
6 years ago
Containers::StringView globalButNotNullTerminated = "VK_KHR_maintenance25"_s.except(1);
Containers::String localButNullTerminated = Extensions::KHR::draw_indirect_count::string();
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
DeviceCreateInfo info{pickDevice(instance()), DeviceCreateInfo::Flag::NoImplicitExtensions};
Vk: device creation.
6 years ago
info.addEnabledExtensions({
globalButNotNullTerminated,
localButNullTerminated
});
CORRADE_COMPARE(info->enabledExtensionCount, 2);
CORRADE_COMPARE(info->ppEnabledExtensionNames[0], globalButNotNullTerminated);
CORRADE_VERIFY(info->ppEnabledExtensionNames[0] != globalButNotNullTerminated.data());
CORRADE_COMPARE(info->ppEnabledExtensionNames[1], localButNullTerminated);
CORRADE_VERIFY(info->ppEnabledExtensionNames[1] != localButNullTerminated.data());
}
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
void DeviceVkTest::createInfoFeatures() {
DeviceProperties properties = pickDevice(instance());
/* We don't use the structure for anything, so we don't need to check if
the structure is actually supported */
DeviceCreateInfo info{properties};
info.setEnabledFeatures(DeviceFeature::RobustBufferAccess|DeviceFeature::SamplerYcbcrConversion);
/* If we have Vulkan 1.1 on both instance and the device or KHR_gpdp2 is
enabled on the instance, pNext chain will be filled as appropriate */
if((instance().isVersionSupported(Version::Vk11) && properties.isVersionSupported(Version::Vk11)) || instance().isExtensionEnabled<Extensions::KHR::get_physical_device_properties2>()) {
CORRADE_VERIFY(!info->pEnabledFeatures);
CORRADE_VERIFY(info->pNext);
const auto& features2 = *static_cast<const VkPhysicalDeviceFeatures2*>(info->pNext);
CORRADE_COMPARE(features2.sType, VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2);
CORRADE_VERIFY(features2.features.robustBufferAccess);
CORRADE_VERIFY(features2.pNext);
const auto& samplerYcbcrConversionFeatures = *static_cast<const VkPhysicalDeviceSamplerYcbcrConversionFeatures*>(features2.pNext);
CORRADE_COMPARE(samplerYcbcrConversionFeatures.sType, VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_YCBCR_CONVERSION_FEATURES);
CORRADE_VERIFY(samplerYcbcrConversionFeatures.samplerYcbcrConversion);
/* Otherwise just the pEnabledFeatures will be enabled */
} else {
CORRADE_VERIFY(!info->pNext);
CORRADE_VERIFY(info->pEnabledFeatures);
CORRADE_VERIFY(info->pEnabledFeatures->robustBufferAccess);
}
}
void DeviceVkTest::createInfoFeaturesNothingInCoreFeatures() {
DeviceProperties properties = pickDevice(instance());
DeviceCreateInfo info{properties};
info.setEnabledFeatures(DeviceFeature::SamplerYcbcrConversion|DeviceFeature::ImagelessFramebuffer);
/* If we have Vulkan 1.1 on both instance and the device or KHR_gpdp2 is
enabled on the instance, pNext chain will be filled as appropriate */
if((instance().isVersionSupported(Version::Vk11) && properties.isVersionSupported(Version::Vk11)) || instance().isExtensionEnabled<Extensions::KHR::get_physical_device_properties2>()) {
CORRADE_VERIFY(!info->pEnabledFeatures);
CORRADE_VERIFY(info->pNext);
const auto& imagelessFramebufferFeatures = *static_cast<const VkPhysicalDeviceImagelessFramebufferFeatures*>(info->pNext);
CORRADE_COMPARE(imagelessFramebufferFeatures.sType, VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGELESS_FRAMEBUFFER_FEATURES);
CORRADE_VERIFY(imagelessFramebufferFeatures.imagelessFramebuffer);
const auto& samplerYcbcrConversionFeatures = *static_cast<const VkPhysicalDeviceSamplerYcbcrConversionFeatures*>(imagelessFramebufferFeatures.pNext);
CORRADE_COMPARE(samplerYcbcrConversionFeatures.sType, VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_YCBCR_CONVERSION_FEATURES);
CORRADE_VERIFY(samplerYcbcrConversionFeatures.samplerYcbcrConversion);
/* Otherwise nothing is enabled as there's nowhere to connect that */
} else {
CORRADE_VERIFY(!info->pNext);
CORRADE_VERIFY(!info->pEnabledFeatures);
}
}
void DeviceVkTest::createInfoFeaturesReplaceExternal() {
DeviceProperties properties = pickDevice(instance());
VkPhysicalDeviceFeatures2 features{};
features.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2;
VkAttachmentReference2 somethingAfter{};
somethingAfter.pNext = &features;
DeviceCreateInfo info{properties};
info->pNext = &somethingAfter;
info->pEnabledFeatures = &features.features;
info.setEnabledFeatures(DeviceFeature::RobustBufferAccess);
/* Then, if we have Vulkan 1.1 on both instance and the device or KHR_gpdp2
is enabled on the instance, pNext will be filled and pEnabledFeatures
reset */
if((instance().isVersionSupported(Version::Vk11) && properties.isVersionSupported(Version::Vk11)) || instance().isExtensionEnabled<Extensions::KHR::get_physical_device_properties2>()) {
CORRADE_VERIFY(!info->pEnabledFeatures);
CORRADE_VERIFY(info->pNext);
const auto& features2 = *static_cast<const VkPhysicalDeviceFeatures2*>(info->pNext);
CORRADE_COMPARE(features2.sType, VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2);
CORRADE_VERIFY(features2.features.robustBufferAccess);
/* The original chain should be preserved after */
CORRADE_COMPARE(features2.pNext, &somethingAfter);
/* Otherwise the pNext chain will be preserved and pEnabledFeatures
replaced with own instance */
} else {
CORRADE_VERIFY(info->pEnabledFeatures);
CORRADE_VERIFY(info->pEnabledFeatures != &features.features);
CORRADE_VERIFY(info->pEnabledFeatures->robustBufferAccess);
}
/* No changes to the original chain, even though it has a features on its
own (that's user error) */
CORRADE_COMPARE(somethingAfter.pNext, &features);
}
void DeviceVkTest::createInfoFeaturesReplacePrevious() {
DeviceProperties properties = pickDevice(instance());
VkAttachmentReference2 somethingAfter{};
DeviceCreateInfo info{properties};
info->pNext = &somethingAfter;
info.setEnabledFeatures(DeviceFeature::RobustBufferAccess);
/* If we have Vulkan 1.1 on both instance and the device or KHR_gpdp2 is
enabled on the instance, pNext chain will be filled as appropriate */
if((instance().isVersionSupported(Version::Vk11) && properties.isVersionSupported(Version::Vk11)) || instance().isExtensionEnabled<Extensions::KHR::get_physical_device_properties2>()) {
CORRADE_VERIFY(!info->pEnabledFeatures);
CORRADE_VERIFY(info->pNext);
const auto& features2 = *static_cast<const VkPhysicalDeviceFeatures2*>(info->pNext);
CORRADE_COMPARE(features2.sType, VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2);
CORRADE_VERIFY(features2.features.robustBufferAccess);
/* The original chain should be preserved after */
CORRADE_COMPARE(features2.pNext, &somethingAfter);
/* Otherwise the pNext chain will be preserved and pEnabledFeatures
replaced with own instance */
} else {
CORRADE_COMPARE(info->pNext, &somethingAfter);
CORRADE_VERIFY(info->pEnabledFeatures);
CORRADE_VERIFY(info->pEnabledFeatures->robustBufferAccess);
}
/* Setting a different non-core feature */
info.setEnabledFeatures(DeviceFeature::ImagelessFramebuffer);
if((instance().isVersionSupported(Version::Vk11) && properties.isVersionSupported(Version::Vk11)) || instance().isExtensionEnabled<Extensions::KHR::get_physical_device_properties2>()) {
CORRADE_VERIFY(!info->pEnabledFeatures);
CORRADE_VERIFY(info->pNext);
const auto& imagelessFramebufferFeatures = *static_cast<const VkPhysicalDeviceImagelessFramebufferFeatures*>(info->pNext);
CORRADE_COMPARE(imagelessFramebufferFeatures.sType, VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGELESS_FRAMEBUFFER_FEATURES);
CORRADE_VERIFY(imagelessFramebufferFeatures.imagelessFramebuffer);
/* The original chain should still be preserved after, without the
structures from the previous case getting in the way */
CORRADE_COMPARE(imagelessFramebufferFeatures.pNext, &somethingAfter);
/* Otherwise the pNext chain will still be preserved and pEnabledFeatures
empty */
} else {
CORRADE_COMPARE(info->pNext, &somethingAfter);
CORRADE_VERIFY(!info->pEnabledFeatures);
}
/* Setting no features, everything should be fully discarded, and the
original chain still kept. This doesn't have any difference between
versions. */
info.setEnabledFeatures({});
CORRADE_COMPARE(info->pNext, &somethingAfter);
CORRADE_VERIFY(!info->pEnabledFeatures);
CORRADE_VERIFY(!somethingAfter.pNext);
}
void DeviceVkTest::createInfoFeaturesEnableAllResetAll() {
DeviceProperties properties = pickDevice(instance());
if((!instance().isVersionSupported(Version::Vk11) || !properties.isVersionSupported(Version::Vk11)) && !instance().isExtensionEnabled<Extensions::KHR::get_physical_device_properties2>())
CORRADE_SKIP("Neither Vulkan 1.1 nor KHR_get_physical_device_properties2 is supported, can't test");
VkAttachmentDescription2 somethingAfter{};
somethingAfter.sType = VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2;
DeviceCreateInfo info{properties};
info->pNext = &somethingAfter;
/* This should populate a huge chain of structures */
info.setEnabledFeatures(~DeviceFeatures{});
CORRADE_VERIFY(info->pNext != &somethingAfter);
CORRADE_VERIFY(!somethingAfter.pNext);
/* And this should disconnect them all again. If this fails, it means the
resetting code path got out of sync with the structure list. Sorry,
there's not really a better way how to show *where* it got wrong. */
info.setEnabledFeatures({});
CORRADE_COMPARE(info->pNext, &somethingAfter);
CORRADE_VERIFY(!somethingAfter.pNext);
}
Vk: device creation.
6 years ago
void DeviceVkTest::createInfoNoQueuePriorities() {
#ifdef CORRADE_NO_ASSERT
CORRADE_SKIP("CORRADE_NO_ASSERT defined, can't test assertions");
#endif
std::ostringstream out;
Error redirectError{&out};
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
DeviceCreateInfo{pickDevice(instance())}.addQueues(0, {}, {});
Vk: device creation.
6 years ago
CORRADE_COMPARE(out.str(), "Vk::DeviceCreateInfo::addQueues(): at least one queue priority has to be specified\n");
}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
void DeviceVkTest::createInfoWrongQueueOutputCount() {
#ifdef CORRADE_NO_ASSERT
CORRADE_SKIP("CORRADE_NO_ASSERT defined, can't test assertions");
#endif
std::ostringstream out;
Error redirectError{&out};
Queue a{NoCreate}, b{NoCreate};
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
DeviceCreateInfo{pickDevice(instance())}.addQueues(0, {0.0f, 1.0f, 0.3f}, {a, b});
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
CORRADE_COMPARE(out.str(), "Vk::DeviceCreateInfo::addQueues(): expected 3 outuput queue references but got 2\n");
}
Vk: DeviceCreateInfo wasn't properly movable. Interestingly I didn't run into this until now. Doing what I just learned while implementing the RenderPass.
5 years ago
void DeviceVkTest::createInfoConstructCopy() {
Test: adapt to a less shitty CORRADE_COMPARE().
5 years ago
CORRADE_VERIFY(!std::is_copy_constructible<DeviceCreateInfo>{});
CORRADE_VERIFY(!std::is_copy_assignable<DeviceCreateInfo>{});
Vk: DeviceCreateInfo wasn't properly movable. Interestingly I didn't run into this until now. Doing what I just learned while implementing the RenderPass.
5 years ago
}
void DeviceVkTest::createInfoConstructMove() {
if(std::getenv("MAGNUM_DISABLE_EXTENSIONS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_EXTENSIONS environment variable set");
Queue queue{NoCreate};
DeviceCreateInfo a{pickDevice(instance()), DeviceCreateInfo::Flag::NoImplicitExtensions};
a.addQueues(0, {0.35f}, {queue})
.addEnabledExtensions<Extensions::KHR::get_memory_requirements2,
Extensions::KHR::bind_memory2>();
DeviceCreateInfo b{std::move(a)};
CORRADE_COMPARE(a->enabledExtensionCount, 0);
CORRADE_VERIFY(!a->ppEnabledExtensionNames);
CORRADE_COMPARE(a->queueCreateInfoCount, 0);
CORRADE_VERIFY(!a->pQueueCreateInfos);
CORRADE_COMPARE(b->enabledExtensionCount, 2);
CORRADE_VERIFY(b->ppEnabledExtensionNames);
CORRADE_COMPARE(b->ppEnabledExtensionNames[1], "VK_KHR_bind_memory2"_s);
CORRADE_COMPARE(b->queueCreateInfoCount, 1);
CORRADE_VERIFY(b->pQueueCreateInfos);
CORRADE_COMPARE(b->pQueueCreateInfos[0].pQueuePriorities[0], 0.35f);
DeviceCreateInfo c{{}, {}};
c = std::move(b);
CORRADE_COMPARE(b->enabledExtensionCount, 0);
CORRADE_VERIFY(!b->ppEnabledExtensionNames);
CORRADE_COMPARE(b->queueCreateInfoCount, 0);
CORRADE_VERIFY(!b->pQueueCreateInfos);
CORRADE_COMPARE(c->enabledExtensionCount, 2);
CORRADE_VERIFY(c->ppEnabledExtensionNames);
CORRADE_COMPARE(c->ppEnabledExtensionNames[1], "VK_KHR_bind_memory2"_s);
CORRADE_COMPARE(c->queueCreateInfoCount, 1);
CORRADE_VERIFY(c->pQueueCreateInfos);
CORRADE_COMPARE(c->pQueueCreateInfos[0].pQueuePriorities[0], 0.35f);
}
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
void DeviceVkTest::createInfoRvalue() {
Vk: DeviceCreateInfo::addQueues() overload taking QueueFlags directly. More convenient to use since one doesn't have to explicitly store a DeviceProperties instance to call pickQueueFamily() on it and then move it to DeviceCreateInfo to keep it efficient. This required a slight redesign of how DeviceProperties are stored in DeviceCreateInfo, now we need the instance to be always valid (but it can get never used). The wrap() API isn't doing any extra work so this won't add any inefficiency.
6 years ago
/* Verify that there actually are graphics queues so we don't exit inside
addQueues() */
CORRADE_VERIFY(pickDevice(instance()).tryPickQueueFamily(QueueFlag::Graphics));
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
Float zero[1]{};
Vk: DeviceCreateInfo::addQueues() overload taking QueueFlags directly. More convenient to use since one doesn't have to explicitly store a DeviceProperties instance to call pickQueueFamily() on it and then move it to DeviceCreateInfo to keep it efficient. This required a slight redesign of how DeviceProperties are stored in DeviceCreateInfo, now we need the instance to be always valid (but it can get never used). The wrap() API isn't doing any extra work so this won't add any inefficiency.
6 years ago
Queue a{NoCreate}, b{NoCreate}, c{NoCreate}, d{NoCreate};
Containers::Reference<Queue> referenceA[1]{a};
Containers::Reference<Queue> referenceC[1]{c};
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
VkDeviceQueueCreateInfo rawQueueInfo{};
rawQueueInfo.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
rawQueueInfo.pQueuePriorities = zero;
rawQueueInfo.queueFamilyIndex = 0;
rawQueueInfo.queueCount = 1;
DeviceCreateInfo&& info = DeviceCreateInfo{pickDevice(instance())}
.addEnabledExtensions(Containers::ArrayView<const Containers::StringView>{})
.addEnabledExtensions(std::initializer_list<Containers::StringView>{})
.addEnabledExtensions(Containers::ArrayView<const Extension>{})
.addEnabledExtensions(std::initializer_list<Extension>{})
.addEnabledExtensions<>()
Vk: DeviceCreateInfo::addQueues() overload taking QueueFlags directly. More convenient to use since one doesn't have to explicitly store a DeviceProperties instance to call pickQueueFamily() on it and then move it to DeviceCreateInfo to keep it efficient. This required a slight redesign of how DeviceProperties are stored in DeviceCreateInfo, now we need the instance to be always valid (but it can get never used). The wrap() API isn't doing any extra work so this won't add any inefficiency.
6 years ago
.addQueues(0, zero, referenceA)
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
.addQueues(0, {0.0f}, {b})
Vk: DeviceCreateInfo::addQueues() overload taking QueueFlags directly. More convenient to use since one doesn't have to explicitly store a DeviceProperties instance to call pickQueueFamily() on it and then move it to DeviceCreateInfo to keep it efficient. This required a slight redesign of how DeviceProperties are stored in DeviceCreateInfo, now we need the instance to be always valid (but it can get never used). The wrap() API isn't doing any extra work so this won't add any inefficiency.
6 years ago
.addQueues(QueueFlag::Graphics, zero, referenceC)
.addQueues(QueueFlag::Graphics, {0.0f}, {d})
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
.addQueues(rawQueueInfo);
/* Just to test something, main point is that the above compiles, links and
returns a &&. Can't test anything related to the contents because the
destructor gets called at the end of the expression. */
CORRADE_VERIFY(&info);
}
Vk: device creation.
6 years ago
void DeviceVkTest::construct() {
if(std::getenv("MAGNUM_VULKAN_VERSION"))
CORRADE_SKIP("Can't test with the MAGNUM_VULKAN_VERSION environment variable set");
{
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
DeviceProperties deviceProperties = pickDevice(instance());
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
Queue queue{NoCreate};
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
Device device{instance(), DeviceCreateInfo{deviceProperties}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
.addQueues(0, {0.0f}, {queue})
Vk: device creation.
6 years ago
};
CORRADE_VERIFY(device.handle());
/* Device function pointers should be populated */
CORRADE_VERIFY(device->CreateBuffer);
CORRADE_COMPARE(device.handleFlags(), HandleFlag::DestroyOnDestruction);
Vk: rework device property fetching. Today I spent six hours wrongly convincing myself that it's a driver bug when vkGetPhysicalDeviceProperties2() is null on a 1.1 instance for a 1.0 physical device. It's not a bug, it's me not reading specs carefully. This commit thus basically moves all Instance-level extension-dependent state to DeviceProperties, because it's actually device-dependent. Which makes the DeviceProperties class quite heavy and thus it's good it was readied to be transferred all the way to a Device instance a few commits back -- I don't really want to do all the dispatch, string processing, sorting and other mess more times than strictly necessary. In addition, DeviceProperties::apiVersion() got renamed to version() and a new isVersionSupported() API got added, mirroring what's on Device itself; plus thanks to the chicken-and-egg problem of having to call vkGetPhysicalDeviceProperties() twice, the device version and other things can now be retrieved in a slightly more efficient way.
6 years ago
CORRADE_COMPARE(device.version(), deviceProperties.version());
Vk: device creation.
6 years ago
/* Device version is supported */
Vk: rework device property fetching. Today I spent six hours wrongly convincing myself that it's a driver bug when vkGetPhysicalDeviceProperties2() is null on a 1.1 instance for a 1.0 physical device. It's not a bug, it's me not reading specs carefully. This commit thus basically moves all Instance-level extension-dependent state to DeviceProperties, because it's actually device-dependent. Which makes the DeviceProperties class quite heavy and thus it's good it was readied to be transferred all the way to a Device instance a few commits back -- I don't really want to do all the dispatch, string processing, sorting and other mess more times than strictly necessary. In addition, DeviceProperties::apiVersion() got renamed to version() and a new isVersionSupported() API got added, mirroring what's on Device itself; plus thanks to the chicken-and-egg problem of having to call vkGetPhysicalDeviceProperties() twice, the device version and other things can now be retrieved in a slightly more efficient way.
6 years ago
CORRADE_VERIFY(device.isVersionSupported(deviceProperties.version()));
Vk: device creation.
6 years ago
CORRADE_VERIFY(!device.isVersionSupported(Version::None));
/* No extensions are enabled by default ... */
CORRADE_VERIFY(!device.isExtensionEnabled<Extensions::EXT::debug_marker>());
/* ... and thus also no function pointers loaded */
CORRADE_VERIFY(!device->CmdDebugMarkerInsertEXT);
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
/* The queue should be also filled in */
CORRADE_VERIFY(queue.handle());
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
/* Device properties should be lazy-populated and different from the
above instances because we didn't transfer the ownership */
CORRADE_COMPARE(device.properties().name(), deviceProperties.name());
CORRADE_VERIFY(&device.properties().properties() != &deviceProperties.properties());
Vk: device creation.
6 years ago
}
/* Shouldn't crash or anything */
CORRADE_VERIFY(true);
}
Vk: DeviceCreateInfo::addQueues() overload taking QueueFlags directly. More convenient to use since one doesn't have to explicitly store a DeviceProperties instance to call pickQueueFamily() on it and then move it to DeviceCreateInfo to keep it efficient. This required a slight redesign of how DeviceProperties are stored in DeviceCreateInfo, now we need the instance to be always valid (but it can get never used). The wrap() API isn't doing any extra work so this won't add any inefficiency.
6 years ago
void DeviceVkTest::constructQueueFromFlags() {
DeviceProperties deviceProperties = pickDevice(instance());
/* Verify that there actually are graphics queues so we don't exit after */
CORRADE_VERIFY(deviceProperties.tryPickQueueFamily(QueueFlag::Graphics));
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{deviceProperties}
.addQueues(QueueFlag::Graphics, {0.0f}, {queue})};
CORRADE_VERIFY(device.handle());
/* The queue should be filled in like usual */
CORRADE_VERIFY(queue.handle());
}
Vk: device creation.
6 years ago
void DeviceVkTest::constructExtensions() {
if(std::getenv("MAGNUM_DISABLE_EXTENSIONS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_EXTENSIONS environment variable set");
if(!enumerateLayerProperties().isSupported("VK_LAYER_KHRONOS_validation"))
CORRADE_SKIP("VK_LAYER_KHRONOS_validation not supported, can't test");
/* Creating a dedicated instance so we can pass custom args and enable
layers & exts independently */
Instance instance{InstanceCreateInfo{}
.addEnabledLayers({"VK_LAYER_KHRONOS_validation"})
/* Needed by VK_EXT_debug_marker */
.addEnabledExtensions<Extensions::EXT::debug_report>()
};
DeviceProperties deviceProperties = pickDevice(instance);
ExtensionProperties extensions = deviceProperties.enumerateExtensionProperties({"VK_LAYER_KHRONOS_validation"});
if(!extensions.isSupported<Extensions::EXT::debug_marker>())
CORRADE_SKIP("VK_EXT_debug_marker not supported, can't test");
if(!extensions.isSupported<Extensions::KHR::maintenance1>())
CORRADE_SKIP("VK_KHR_maintenance1 not supported, can't test");
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
Queue queue{NoCreate};
Vk: device creation.
6 years ago
Device device{instance, DeviceCreateInfo{deviceProperties}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
.addQueues(0, {0.0f}, {queue})
Vk: device creation.
6 years ago
.addEnabledExtensions({
Extensions::EXT::debug_marker::string(),
"VK_KHR_maintenance1"_s
})};
CORRADE_VERIFY(device.handle());
/* Extensions should be reported as enabled ... */
CORRADE_VERIFY(device.isExtensionEnabled<Extensions::EXT::debug_marker>());
CORRADE_VERIFY(device.isExtensionEnabled(Extensions::KHR::maintenance1{}));
/* ... and function pointers loaded */
CORRADE_VERIFY(device->CmdDebugMarkerInsertEXT);
CORRADE_VERIFY(device->TrimCommandPoolKHR);
}
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
void DeviceVkTest::constructFeatures() {
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{pickDevice(instance())}
.addQueues(0, {0.0f}, {queue})
/* RobustBufferAccess is guaranteed to be supported always, no need to
check anything */
.setEnabledFeatures(DeviceFeature::RobustBufferAccess)};
CORRADE_VERIFY(device.handle());
Vk: expose and implement KHR_portability_subset.
5 years ago
/* Features should be reported as enabled. Exclude portability subset
features that get implicitly marked as enabled on devices w/o
KHR_portability_subset. */
CORRADE_COMPARE(device.enabledFeatures() & ~Implementation::deviceFeaturesPortabilitySubset(), DeviceFeature::RobustBufferAccess);
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
}
void DeviceVkTest::constructFeaturesFromExtensions() {
DeviceProperties properties = pickDevice(instance());
if(!properties.enumerateExtensionProperties().isSupported<Extensions::KHR::sampler_ycbcr_conversion>())
CORRADE_SKIP("VK_KHR_sampler_ycbcr_conversion not supported, can't test");
if(!(properties.features() & DeviceFeature::SamplerYcbcrConversion))
CORRADE_SKIP("SamplerYcbcrConversion feature not supported, can't test");
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{properties}
.addQueues(0, {0.0f}, {queue})
.addEnabledExtensions<Extensions::KHR::sampler_ycbcr_conversion>()
/* RobustBufferAccess is guaranteed to be supported always, no need to
check anything */
.setEnabledFeatures(DeviceFeature::RobustBufferAccess|DeviceFeature::SamplerYcbcrConversion)};
CORRADE_VERIFY(device.handle());
Vk: expose and implement KHR_portability_subset.
5 years ago
/* Features should be reported as enabled. Exclude portability subset
features that get implicitly marked as enabled on devices w/o
KHR_portability_subset. */
CORRADE_COMPARE(device.enabledFeatures() & ~Implementation::deviceFeaturesPortabilitySubset(), DeviceFeature::RobustBufferAccess|DeviceFeature::SamplerYcbcrConversion);
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
}
Vk: Device(..., const DeviceCreateInfo&) wasn't covered. Interestingly enough, apparently I was always constructing it in-place in the Device constructor. Which leads me to the next issue...
5 years ago
void DeviceVkTest::constructDeviceCreateInfoConstReference() {
Queue queue{NoCreate};
DeviceProperties deviceProperties = pickDevice(instance());
DeviceCreateInfo info{deviceProperties};
info.addQueues(0, {0.0f}, {queue});
/* Just to verify the overload taking const DeviceProperties& works as
well (most of the above tests verified a move) */
Device device{instance(), info};
CORRADE_VERIFY(device.handle());
/* Device properties should be lazy-populated and different from the
above instances because we didn't transfer the ownership here either */
CORRADE_COMPARE(device.properties().name(), deviceProperties.name());
CORRADE_VERIFY(&device.properties().properties() != &deviceProperties.properties());
}
Vk: it's inevitable, DeviceProperties are going to stay forever. I have more and more cases where I need to query device properties later down the road (memory capabilities, device name, ...) and leaving all this up to the user / making this impossible to do in the library internals is complicating everything too much. Since there's a shitton of device properties with a new bag of props coming with every other new extension, I expect the queries to get quite involved / complicated over time (chaining 100s structs and such), so let's design this upfront in a way that can avoid reqpeatedly querying the same thing just because we needlessly discarded a fully populated instance before. It also means the users don't need to drag their own DeviceProperties instance along anymore and can just let the Device take care of that. Unfortunately the only nice way to make this work with DeviceCreateInfo method chaining is to add & and && overloads for each. But it's quite easy to test that all of them work and properly return a r-value reference so it shouldn't be too much of a maintenance nightmare.
6 years ago
void DeviceVkTest::constructTransferDeviceProperties() {
DeviceProperties deviceProperties = pickDevice(instance());
const void* vkProperties = &deviceProperties.properties();
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{std::move(deviceProperties)}
.addQueues(0, {0.0f}, {queue})
};
/* Device properties should be the same address as in the original instance
because the ownership got transferred through */
CORRADE_COMPARE(&device.properties().properties(), vkProperties);
}
Vk: device creation.
6 years ago
void DeviceVkTest::constructExtensionsCommandLineDisable() {
auto&& data = ConstructCommandLineData[testCaseInstanceId()];
setTestCaseDescription(data.nameDisable);
if(std::getenv("MAGNUM_VULKAN_VERSION"))
CORRADE_SKIP("Can't test with the MAGNUM_VULKAN_VERSION environment variable set");
if(std::getenv("MAGNUM_DISABLE_LAYERS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_LAYERS environment variable set");
if(std::getenv("MAGNUM_DISABLE_EXTENSIONS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_EXTENSIONS environment variable set");
if(!enumerateLayerProperties().isSupported("VK_LAYER_KHRONOS_validation"))
CORRADE_SKIP("VK_LAYER_KHRONOS_validation not supported, can't test");
/* Creating a dedicated instance so we can pass custom args and enable
layers independently */
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
Instance instance2{InstanceCreateInfo{Int(data.argsDisable.size()), data.argsDisable}
Vk: device creation.
6 years ago
.addEnabledLayers({"VK_LAYER_KHRONOS_validation"})
/* Needed by VK_EXT_debug_marker */
.addEnabledExtensions<Extensions::EXT::debug_report>()
};
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
DeviceProperties deviceProperties = pickDevice(instance2);
Vk: device creation.
6 years ago
ExtensionProperties extensions = deviceProperties.enumerateExtensionProperties({"VK_LAYER_KHRONOS_validation"});
if(!extensions.isSupported<Extensions::EXT::debug_marker>())
CORRADE_SKIP("VK_EXT_debug_marker not supported, can't test");
if(!extensions.isSupported<Extensions::KHR::maintenance1>())
CORRADE_SKIP("VK_KHR_maintenance1 not supported, can't test");
std::ostringstream out;
Debug redirectOutput{&out};
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
Queue queue{NoCreate};
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
Device device{instance2, DeviceCreateInfo{deviceProperties, DeviceCreateInfo::Flag::NoImplicitExtensions}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
.addQueues(0, {0.0f}, {queue})
Vk: device creation.
6 years ago
.addEnabledExtensions<
Extensions::EXT::debug_marker,
Extensions::KHR::maintenance1
>()};
CORRADE_VERIFY(device.handle());
Vk: rework device property fetching. Today I spent six hours wrongly convincing myself that it's a driver bug when vkGetPhysicalDeviceProperties2() is null on a 1.1 instance for a 1.0 physical device. It's not a bug, it's me not reading specs carefully. This commit thus basically moves all Instance-level extension-dependent state to DeviceProperties, because it's actually device-dependent. Which makes the DeviceProperties class quite heavy and thus it's good it was readied to be transferred all the way to a Device instance a few commits back -- I don't really want to do all the dispatch, string processing, sorting and other mess more times than strictly necessary. In addition, DeviceProperties::apiVersion() got renamed to version() and a new isVersionSupported() API got added, mirroring what's on Device itself; plus thanks to the chicken-and-egg problem of having to call vkGetPhysicalDeviceProperties() twice, the device version and other things can now be retrieved in a slightly more efficient way.
6 years ago
CORRADE_COMPARE(device.isVersionSupported(deviceProperties.version()), data.driverVersionSupported);
Vk: device creation.
6 years ago
CORRADE_COMPARE(device.isExtensionEnabled<Extensions::EXT::debug_marker>(), data.debugMarkerEnabled);
CORRADE_COMPARE(device.isExtensionEnabled<Extensions::KHR::maintenance1>(), data.maintenance1Enabled);
/** @todo cleanup when Debug::toString() or some similar utility exists */
Vk: rework device property fetching. Today I spent six hours wrongly convincing myself that it's a driver bug when vkGetPhysicalDeviceProperties2() is null on a 1.1 instance for a 1.0 physical device. It's not a bug, it's me not reading specs carefully. This commit thus basically moves all Instance-level extension-dependent state to DeviceProperties, because it's actually device-dependent. Which makes the DeviceProperties class quite heavy and thus it's good it was readied to be transferred all the way to a Device instance a few commits back -- I don't really want to do all the dispatch, string processing, sorting and other mess more times than strictly necessary. In addition, DeviceProperties::apiVersion() got renamed to version() and a new isVersionSupported() API got added, mirroring what's on Device itself; plus thanks to the chicken-and-egg problem of having to call vkGetPhysicalDeviceProperties() twice, the device version and other things can now be retrieved in a slightly more efficient way.
6 years ago
UnsignedInt major = versionMajor(deviceProperties.version());
UnsignedInt minor = versionMinor(deviceProperties.version());
UnsignedInt patch = versionPatch(deviceProperties.version());
Vk: device creation.
6 years ago
/* SwiftShader reports just 1.1 with no patch version, special-case that */
Vk: print also driver info in Device creation log. Just the device alone isn't enough if we can have multiple drivers for it.
4 years ago
std::string expected = Utility::formatString(data.log, deviceProperties.name(), major, minor, patch ? Utility::formatString(".{}", patch) : "", deviceProperties.driverName(), deviceProperties.driverInfo());
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
/* The output might contain a device workaround list, cut that away.
That's tested thoroughly in constructWorkaroundsCommandLineDisable(). */
CORRADE_COMPARE(out.str().substr(0, expected.size()), expected);
Vk: device creation.
6 years ago
/* Verify that the entrypoint is actually (not) loaded as expected, to
avoid all the above reporting being just smoke & mirrors */
CORRADE_COMPARE(!!device->CmdDebugMarkerInsertEXT, data.debugMarkerEnabled);
CORRADE_COMPARE(!!device->TrimCommandPoolKHR, data.maintenance1Enabled);
}
void DeviceVkTest::constructExtensionsCommandLineEnable() {
auto&& data = ConstructCommandLineData[testCaseInstanceId()];
setTestCaseDescription(data.nameEnable);
if(std::getenv("MAGNUM_VULKAN_VERSION"))
CORRADE_SKIP("Can't test with the MAGNUM_VULKAN_VERSION environment variable set");
if(std::getenv("MAGNUM_DISABLE_LAYERS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_LAYERS environment variable set");
if(std::getenv("MAGNUM_DISABLE_EXTENSIONS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_EXTENSIONS environment variable set");
if(!enumerateLayerProperties().isSupported("VK_LAYER_KHRONOS_validation"))
CORRADE_SKIP("VK_LAYER_KHRONOS_validation not supported, can't test");
/* Creating a dedicated instance so we can pass custom args and enable
layers independently */
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
Instance instance2{InstanceCreateInfo{Int(data.argsEnable.size()), data.argsEnable}
Vk: device creation.
6 years ago
.addEnabledLayers({"VK_LAYER_KHRONOS_validation"})
/* Needed by VK_EXT_debug_marker */
.addEnabledExtensions<Extensions::EXT::debug_report>()
};
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
DeviceProperties deviceProperties = pickDevice(instance2);
Vk: device creation.
6 years ago
ExtensionProperties extensions = deviceProperties.enumerateExtensionProperties({"VK_LAYER_KHRONOS_validation"});
if(!extensions.isSupported<Extensions::EXT::debug_marker>())
CORRADE_SKIP("VK_EXT_debug_marker not supported, can't test");
if(!extensions.isSupported<Extensions::KHR::maintenance1>())
CORRADE_SKIP("VK_KHR_maintenance1 not supported, can't test");
std::ostringstream out;
Debug redirectOutput{&out};
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
Queue queue{NoCreate};
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
Device device{instance2, DeviceCreateInfo{pickDevice(instance2), DeviceCreateInfo::Flag::NoImplicitExtensions}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
.addQueues(0, {0.0f}, {queue})
Vk: device creation.
6 years ago
/* Nothing enabled by the application */
};
CORRADE_VERIFY(device.handle());
Vk: rework device property fetching. Today I spent six hours wrongly convincing myself that it's a driver bug when vkGetPhysicalDeviceProperties2() is null on a 1.1 instance for a 1.0 physical device. It's not a bug, it's me not reading specs carefully. This commit thus basically moves all Instance-level extension-dependent state to DeviceProperties, because it's actually device-dependent. Which makes the DeviceProperties class quite heavy and thus it's good it was readied to be transferred all the way to a Device instance a few commits back -- I don't really want to do all the dispatch, string processing, sorting and other mess more times than strictly necessary. In addition, DeviceProperties::apiVersion() got renamed to version() and a new isVersionSupported() API got added, mirroring what's on Device itself; plus thanks to the chicken-and-egg problem of having to call vkGetPhysicalDeviceProperties() twice, the device version and other things can now be retrieved in a slightly more efficient way.
6 years ago
CORRADE_COMPARE(device.isVersionSupported(deviceProperties.version()), data.driverVersionSupported);
Vk: device creation.
6 years ago
CORRADE_COMPARE(device.isExtensionEnabled<Extensions::EXT::debug_marker>(), data.debugMarkerEnabled);
CORRADE_COMPARE(device.isExtensionEnabled<Extensions::KHR::maintenance1>(), data.maintenance1Enabled);
/** @todo cleanup when Debug::toString() or some similar utility exists */
Vk: rework device property fetching. Today I spent six hours wrongly convincing myself that it's a driver bug when vkGetPhysicalDeviceProperties2() is null on a 1.1 instance for a 1.0 physical device. It's not a bug, it's me not reading specs carefully. This commit thus basically moves all Instance-level extension-dependent state to DeviceProperties, because it's actually device-dependent. Which makes the DeviceProperties class quite heavy and thus it's good it was readied to be transferred all the way to a Device instance a few commits back -- I don't really want to do all the dispatch, string processing, sorting and other mess more times than strictly necessary. In addition, DeviceProperties::apiVersion() got renamed to version() and a new isVersionSupported() API got added, mirroring what's on Device itself; plus thanks to the chicken-and-egg problem of having to call vkGetPhysicalDeviceProperties() twice, the device version and other things can now be retrieved in a slightly more efficient way.
6 years ago
UnsignedInt major = versionMajor(deviceProperties.version());
UnsignedInt minor = versionMinor(deviceProperties.version());
UnsignedInt patch = versionPatch(deviceProperties.version());
Vk: device creation.
6 years ago
/* SwiftShader reports just 1.1 with no patch version, special-case that */
Vk: print also driver info in Device creation log. Just the device alone isn't enough if we can have multiple drivers for it.
4 years ago
std::string expected = Utility::formatString(data.log, deviceProperties.name(), major, minor, patch ? Utility::formatString(".{}", patch) : "", deviceProperties.driverName(), deviceProperties.driverInfo());
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
/* The output might contain a device workaround list, cut that away.
That's tested thoroughly in constructWorkaroundsCommandLineDisable(). */
CORRADE_COMPARE(out.str().substr(0, expected.size()), expected);
Vk: device creation.
6 years ago
/* Verify that the entrypoint is actually (not) loaded as expected, to
avoid all the above reporting being just smoke & mirrors */
CORRADE_COMPARE(!!device->CmdDebugMarkerInsertEXT, data.debugMarkerEnabled);
CORRADE_COMPARE(!!device->TrimCommandPoolKHR, data.maintenance1Enabled);
}
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
void DeviceVkTest::constructWorkaroundsCommandLineDisable() {
auto&& data = ConstructWorkaroundsCommandLineData[testCaseInstanceId()];
setTestCaseDescription(data.name);
if(std::getenv("MAGNUM_VULKAN_VERSION"))
CORRADE_SKIP("Can't test with the MAGNUM_VULKAN_VERSION environment variable set");
/* Creating a dedicated instance so we can pass custom args */
Instance instance2{InstanceCreateInfo{Int(data.args.size()), data.args}};
DeviceProperties deviceProperties = pickDevice(instance2);
if(!deviceProperties.name().hasPrefix("SwiftShader"_s) && !data.shouldPassAlways)
CORRADE_SKIP("Workarounds only available on SwiftShader, can't test.");
std::ostringstream out;
Debug redirectOutput{&out};
Queue queue{NoCreate};
Device device{instance2, DeviceCreateInfo{deviceProperties, DeviceCreateInfo::Flag::NoImplicitExtensions}
.addQueues(0, {0.0f}, {queue})
};
CORRADE_VERIFY(device.handle());
Vk: work around crashy vkGetDeviceQueue2() on SwiftShader.
4 years ago
CORRADE_COMPARE(out.str(), Utility::formatString(data.log, deviceProperties.name(), deviceProperties.driverName(), deviceProperties.driverInfo()));
Vk: add driver workaround scaffolding and the first one for SwiftShader. Yay? It's funny, what produces correct result causes validation errors. I suppose this will be very similar for all other workarounds.
5 years ago
}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
void DeviceVkTest::constructMultipleQueues() {
/* Find a GPU that has at least two queue families and at least four
queues in one family */
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
Containers::Array<DeviceProperties> deviceProperties = enumerateDevices(instance());
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
DeviceProperties* deviceWithMultipleQueues = nullptr;
UnsignedInt largeFamily = ~UnsignedInt{};
for(DeviceProperties& i: deviceProperties) {
if(i.queueFamilyCount() < 2) continue;
for(UnsignedInt family = 0; family != i.queueFamilyCount(); ++family) {
if(i.queueFamilySize(family) < 4) continue;
largeFamily = family;
break;
}
deviceWithMultipleQueues = &i;
break;
}
if(!deviceWithMultipleQueues || largeFamily == ~UnsignedInt{})
CORRADE_SKIP("No device with at least two queue families and at least four queues in one family found, can't test");
const UnsignedInt otherFamily = largeFamily == 0 ? 1 : 0;
constexpr Float zero = 0.0f;
VkDeviceQueueCreateInfo rawQueueInfo{};
rawQueueInfo.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
rawQueueInfo.pQueuePriorities = &zero;
rawQueueInfo.queueFamilyIndex = otherFamily;
rawQueueInfo.queueCount = 1;
Queue a{NoCreate}, b{NoCreate}, c{NoCreate};
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
Device device{instance(), DeviceCreateInfo{*deviceWithMultipleQueues}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
/* Request a raw queue in the middle of it all to test we skip it when
populating the outputs, and correctly offset the next IDs. According
to the spec we can request each family only once, which makes the
implementation and testing slightly simpler. */
.addQueues(rawQueueInfo)
/* Request multiple queues in a single family to test we correctly loop
over these as well */
.addQueues(largeFamily, {0.5f, 0.75f, 1.0f}, {a, b, c})};
/* All queues should be found and different */
CORRADE_VERIFY(a.handle());
CORRADE_VERIFY(b.handle());
CORRADE_VERIFY(c.handle());
CORRADE_VERIFY(a.handle() != b.handle());
CORRADE_VERIFY(a.handle() != c.handle());
CORRADE_VERIFY(b.handle() != c.handle());
/* Fetching the same queue again should give the same handle */
VkQueue aAgain;
device->GetDeviceQueue(device, largeFamily, 0, &aAgain);
CORRADE_COMPARE(aAgain, a.handle());
/* Fetch the raw queue, should be different from everything else as well */
VkQueue rawQueue;
device->GetDeviceQueue(device, otherFamily, 0, &rawQueue);
CORRADE_VERIFY(rawQueue);
CORRADE_VERIFY(rawQueue != a.handle());
CORRADE_VERIFY(rawQueue != b.handle());
CORRADE_VERIFY(rawQueue != c.handle());
}
void DeviceVkTest::constructRawQueue() {
/* Testing a subset of constructQueues() again because not all drivers
have multiple queues and we want to have the coverage */
constexpr Float zero = 0.0f;
VkDeviceQueueCreateInfo rawQueueInfo{};
rawQueueInfo.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
rawQueueInfo.pQueuePriorities = &zero;
rawQueueInfo.queueFamilyIndex = 0;
rawQueueInfo.queueCount = 1;
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
Device device{instance(), DeviceCreateInfo{pickDevice(instance())}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
.addQueues(rawQueueInfo)};
/* Fetch the raw queue */
VkQueue rawQueue;
device->GetDeviceQueue(device, 0, 0, &rawQueue);
CORRADE_VERIFY(rawQueue);
}
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
void DeviceVkTest::constructFeatureNotSupported() {
DeviceProperties properties = pickDevice(instance());
if(properties.features() & DeviceFeature::SparseBinding)
CORRADE_SKIP("The SparseBinding feature is supported, can't test");
Vk: a bit more robust feature enablement. Because the drivers don't seem to check that features are actually supported for anything beyond VkPhysicalDeviceFeatures2, we have to do that instead. Additionally, we also check if a feature is enabled but the extension that needs it is not (which isn't checked by drivers either).
5 years ago
if(properties.features() & DeviceFeature::SparseResidency16Samples)
CORRADE_SKIP("The SparseResidency16Samples feature is supported, can't test");
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
std::ostringstream out;
Error redirectError{&out};
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{properties}
.addQueues(0, {0.0f}, {queue})
Vk: a bit more robust feature enablement. Because the drivers don't seem to check that features are actually supported for anything beyond VkPhysicalDeviceFeatures2, we have to do that instead. Additionally, we also check if a feature is enabled but the extension that needs it is not (which isn't checked by drivers either).
5 years ago
.setEnabledFeatures(DeviceFeature::SparseBinding|DeviceFeature::SparseResidency16Samples)};
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
CORRADE_COMPARE(out.str(), "Vk::Device::tryCreate(): some enabled features are not supported: Vk::DeviceFeature::SparseBinding|Vk::DeviceFeature::SparseResidency16Samples\n");
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
}
void DeviceVkTest::constructFeatureWithoutExtension() {
DeviceProperties properties = pickDevice(instance());
if((!instance().isVersionSupported(Version::Vk11) || !properties.isVersionSupported(Version::Vk11)) && !instance().isExtensionEnabled<Extensions::KHR::get_physical_device_properties2>())
CORRADE_SKIP("Neither Vulkan 1.1 nor KHR_get_physical_device_properties2 is supported, can't test");
Vk: a bit more robust feature enablement. Because the drivers don't seem to check that features are actually supported for anything beyond VkPhysicalDeviceFeatures2, we have to do that instead. Additionally, we also check if a feature is enabled but the extension that needs it is not (which isn't checked by drivers either).
5 years ago
if(!(properties.features() & DeviceFeature::SamplerYcbcrConversion))
CORRADE_SKIP("The SamplerYcbcrConversion feature is not supported, can't test");
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
Queue queue{NoCreate};
DeviceCreateInfo info{properties};
info.addQueues(0, {0.0f}, {queue})
Vk: a bit more robust feature enablement. Because the drivers don't seem to check that features are actually supported for anything beyond VkPhysicalDeviceFeatures2, we have to do that instead. Additionally, we also check if a feature is enabled but the extension that needs it is not (which isn't checked by drivers either).
5 years ago
.setEnabledFeatures(DeviceFeature::SamplerYcbcrConversion);
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
std::ostringstream out;
Error redirectError{&out};
Device device{instance(), info};
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
CORRADE_COMPARE(out.str(), "Vk::Device::tryCreate(): some enabled features need VK_KHR_sampler_ycbcr_conversion enabled\n");
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
}
Vk: device creation.
6 years ago
void DeviceVkTest::constructNoQueue() {
#ifdef CORRADE_NO_ASSERT
CORRADE_SKIP("CORRADE_NO_ASSERT defined, can't test assertions");
#endif
std::ostringstream out;
Error redirectError{&out};
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
Device device{instance(), DeviceCreateInfo{pickDevice(instance())}};
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
CORRADE_COMPARE(out.str(), "Vk::Device::tryCreate(): needs at least one queue\n");
}
Vk: expose and implement KHR_portability_subset.
5 years ago
void DeviceVkTest::constructNoPortability() {
DeviceProperties properties = pickDevice(instance());
if(properties.enumerateExtensionProperties().isSupported<Extensions::KHR::portability_subset>())
CORRADE_SKIP("KHR_portability_subset supported, can't test");
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{properties}
.addQueues(0, {0.0f}, {queue})
};
/* The extension shouldn't be registered as enabled */
CORRADE_VERIFY(!device.isExtensionEnabled<Extensions::KHR::portability_subset>());
/* All features should be marked as enabled */
CORRADE_COMPARE_AS(device.enabledFeatures(), Implementation::deviceFeaturesPortabilitySubset(),
TestSuite::Compare::GreaterOrEqual);
}
void DeviceVkTest::constructNoPortabilityEnablePortabilityFeatures() {
DeviceProperties properties = pickDevice(instance());
if(properties.enumerateExtensionProperties().isSupported<Extensions::KHR::portability_subset>())
CORRADE_SKIP("KHR_portability_subset supported, can't test");
Device device{NoCreate};
/* Explicitly enabling portability subset features shouldn't do anything
when the portability extension isn't present */
Queue queue{NoCreate};
CORRADE_COMPARE(device.tryCreate(instance(), DeviceCreateInfo{properties}
.addQueues(0, {0.0f}, {queue})
.setEnabledFeatures(Implementation::deviceFeaturesPortabilitySubset())
), Result::Success);
/* All features should be marked as enabled */
CORRADE_COMPARE_AS(device.enabledFeatures(), Implementation::deviceFeaturesPortabilitySubset(),
TestSuite::Compare::GreaterOrEqual);
}
void DeviceVkTest::constructPortability() {
DeviceProperties properties = pickDevice(instance());
if(!properties.enumerateExtensionProperties().isSupported<Extensions::KHR::portability_subset>())
CORRADE_SKIP("KHR_portability_subset not supported, can't test");
/* (Same as in DevicePropertiesVkTest.) Not all features should be marked
as supported... */
CORRADE_VERIFY((properties.features() & Implementation::deviceFeaturesPortabilitySubset()) != Implementation::deviceFeaturesPortabilitySubset());
/* ... but there should be at least one feature */
CORRADE_VERIFY(properties.features() &
Implementation::deviceFeaturesPortabilitySubset());
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{properties}
.addQueues(0, {0.0f}, {queue})
.setEnabledFeatures(properties.features() &
Implementation::deviceFeaturesPortabilitySubset())
};
/* All requested features should be marked as enabled */
CORRADE_COMPARE_AS(device.enabledFeatures(), properties.features() &
Implementation::deviceFeaturesPortabilitySubset(),
TestSuite::Compare::GreaterOrEqual);
}
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
void DeviceVkTest::tryCreateAlreadyCreated() {
#ifdef CORRADE_NO_ASSERT
CORRADE_SKIP("CORRADE_NO_ASSERT defined, can't test assertions");
#endif
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{pickDevice(instance())}
.addQueues(0, {0.0f}, {queue})
};
CORRADE_VERIFY(device.handle());
std::ostringstream out;
Error redirectError{&out};
device.tryCreate(instance(), DeviceCreateInfo{pickDevice(instance())});
CORRADE_COMPARE(out.str(), "Vk::Device::tryCreate(): device already created\n");
}
void DeviceVkTest::tryCreateUnknownExtension() {
Queue queue{NoCreate};
Device device{NoCreate};
std::ostringstream out;
Error redirectError{&out};
CORRADE_COMPARE(device.tryCreate(instance(), DeviceCreateInfo{pickDevice(instance())}
.addQueues(0, {0.0f}, {queue})
.addEnabledExtensions({"VK_this_doesnt_exist"_s})), Result::ErrorExtensionNotPresent);
CORRADE_COMPARE(out.str(), "Vk::Device::tryCreate(): device creation failed: Vk::Result::ErrorExtensionNotPresent\n");
Vk: device creation.
6 years ago
}
void DeviceVkTest::wrap() {
if(std::getenv("MAGNUM_VULKAN_VERSION"))
CORRADE_SKIP("Can't test with the MAGNUM_VULKAN_VERSION environment variable set");
if(std::getenv("MAGNUM_DISABLE_LAYERS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_LAYERS environment variable set");
if(std::getenv("MAGNUM_DISABLE_EXTENSIONS"))
CORRADE_SKIP("Can't test with the MAGNUM_DISABLE_EXTENSIONS environment variable set");
if(!enumerateLayerProperties().isSupported("VK_LAYER_KHRONOS_validation"))
CORRADE_SKIP("VK_LAYER_KHRONOS_validation not supported, can't test");
/* Creating a dedicated instance so we can enable layers independently */
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
Instance instance2{InstanceCreateInfo{}
Vk: device creation.
6 years ago
.addEnabledLayers({"VK_LAYER_KHRONOS_validation"})
/* Needed by VK_EXT_debug_marker */
.addEnabledExtensions<Extensions::EXT::debug_report>()
};
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
DeviceProperties deviceProperties = pickDevice(instance2);
Vk: device creation.
6 years ago
ExtensionProperties extensions = deviceProperties.enumerateExtensionProperties({"VK_LAYER_KHRONOS_validation"});
if(!extensions.isSupported<Extensions::EXT::debug_marker>())
CORRADE_SKIP("VK_EXT_debug_marker not supported, can't test");
if(!extensions.isSupported<Extensions::KHR::maintenance1>())
CORRADE_SKIP("VK_KHR_maintenance1 not supported, can't test");
VkDevice device;
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
Queue queue{NoCreate};
Vk: use the new VulkanTester in Device tests. It's there only to create the instance right now. Not using it to test instance-level functionality right now as we'd be only working around it anyway.
6 years ago
CORRADE_COMPARE(Result(instance2->CreateDevice(deviceProperties,
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
DeviceCreateInfo{pickDevice(instance2)}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
.addQueues(0, {0.0f}, {queue})
Vk: device creation.
6 years ago
.addEnabledExtensions<
Extensions::EXT::debug_marker,
Extensions::KHR::maintenance1
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
>()
/* RobustBufferAccess is guaranteed to be supported always, no need
to check anything */
.setEnabledFeatures(DeviceFeature::RobustBufferAccess),
Vk: device creation.
6 years ago
nullptr, &device)), Result::Success);
CORRADE_VERIFY(device);
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
/* Populating the queue handle is done only from Device itself, so it won't
happen here -- would need to call vkGetDeviceQueue[2] directly */
CORRADE_VERIFY(!queue.handle());
Vk: device creation.
6 years ago
{
/* Wrapping should load the basic function pointers */
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
Device wrapped{NoCreate};
Vk: pass VkPhysicalDevice to Device::wrap(). It's needed in order to access Device::properties(), which is mandatory for the driver workarounds happening in the next commit.
5 years ago
wrapped.wrap(instance2, deviceProperties, device, Version::Vk11, {
Vk: device creation.
6 years ago
Extensions::EXT::debug_marker::string()
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
}, DeviceFeature::RobustBufferAccess, HandleFlag::DestroyOnDestruction);
Vk: device creation.
6 years ago
CORRADE_VERIFY(wrapped->DestroyDevice);
/* Specified version should be reported as supported but higher not
regardless of the actual driver version */
CORRADE_VERIFY(wrapped.isVersionSupported(Version::Vk11));
CORRADE_VERIFY(!wrapped.isVersionSupported(Version::Vk12));
/* Listed extensions should be reported as enabled and function
pointers loaded as well */
CORRADE_VERIFY(wrapped.isExtensionEnabled<Extensions::EXT::debug_marker>());
CORRADE_VERIFY(wrapped->CmdDebugMarkerInsertEXT);
/* Unlisted not, but function pointers should still be loaded as the
actual instance does have the extension enabled */
CORRADE_VERIFY(!wrapped.isExtensionEnabled<Extensions::KHR::maintenance1>());
CORRADE_VERIFY(wrapped->TrimCommandPoolKHR);
Vk: implement Device feature enablement. This was way more pain that initially expected, especially in regards to preserving externally-specified pNext chains without writing to them in any way.
5 years ago
/* Listed features should be reported as enabled */
CORRADE_COMPARE(wrapped.enabledFeatures(), DeviceFeature::RobustBufferAccess);
Vk: test that Device::properties() exist even for wrapped devices. It explodes!!
5 years ago
/* Device properties should be available */
CORRADE_COMPARE(wrapped.properties().handle(), deviceProperties.handle());
Vk: device creation.
6 years ago
/* Releasing won't destroy anything ... */
CORRADE_COMPARE(wrapped.release(), device);
}
/* ...so we can wrap it again, non-owned, and then destroy it manually */
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
Device wrapped{NoCreate};
Vk: pass VkPhysicalDevice to Device::wrap(). It's needed in order to access Device::properties(), which is mandatory for the driver workarounds happening in the next commit.
5 years ago
wrapped.wrap(instance2, deviceProperties, device, Version::Vk10, {}, {});
Vk: device creation.
6 years ago
CORRADE_VERIFY(wrapped->DestroyDevice);
wrapped->DestroyDevice(device, nullptr);
}
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
void DeviceVkTest::wrapAlreadyCreated() {
#ifdef CORRADE_NO_ASSERT
CORRADE_SKIP("CORRADE_NO_ASSERT defined, can't test assertions");
#endif
Queue queue{NoCreate};
Device device{instance(), DeviceCreateInfo{pickDevice(instance())}
.addQueues(0, {0.0f}, {queue})
};
CORRADE_VERIFY(device.handle());
std::ostringstream out;
Error redirectError{&out};
Vk: pass VkPhysicalDevice to Device::wrap(). It's needed in order to access Device::properties(), which is mandatory for the driver workarounds happening in the next commit.
5 years ago
device.wrap(instance(), {}, {}, {}, {}, {});
Vk: make the Device immovable. There was a nasty issue when moving the Device -- because the Queue instances are populated with the Device pointer in the constructor, moving the Device makes the Queue device pointer invalid and those instances are useless. Discovered this when using VulkanTester to test an upcoming Queue::submit() -- until then, the Device pointer in the Queue wasn't really used for anything and so this wasn't known. Making the Device immovable is thus the only sane way to keep the current Queue retrieval workflow, which I'd say is much cleaner than having to manually query the device for queues later using some error-prone indices and whatnot. On the other hand, this finally makes it possible to have a failable device creation, instead of the device creation failing on an assert (or failing silently when CORRADE_NO_ASSERT is defined). This is consistent with how the GL wrapper works. Also, because all device-dependent objects need to keep a pointer to the originating Device in order to access Vulkan function pointers, having it immovable makes it considerably faster. I'll make Instance immovable with tryCreate() next because it seems like a good thing to do there as well.
5 years ago
CORRADE_COMPARE(out.str(), "Vk::Device::wrap(): device already created\n");
}
Vk: device creation.
6 years ago
void DeviceVkTest::populateGlobalFunctionPointers() {
vkDestroyDevice = nullptr;
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
Queue queue{NoCreate};
Vk: this DeviceCreateInfo constructor is garbage. It only adds confusion and can be replaced by only a moderately longer but infinitely more descriptive oneliner. Delete.
6 years ago
Device device{instance(), DeviceCreateInfo{pickDevice(instance())}
Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.
6 years ago
.addQueues(0, {0.0f}, {queue})
Vk: device creation.
6 years ago
};
CORRADE_VERIFY(!vkDestroyDevice);
device.populateGlobalFunctionPointers();
CORRADE_VERIFY(vkDestroyDevice);
CORRADE_VERIFY(vkDestroyDevice == device->DestroyDevice);
}
}}}}
CORRADE_TEST_MAIN(Magnum::Vk::Test::DeviceVkTest)