Remove support for macOS 10.11 and 10.12
Fixed: dawn:1397 Change-Id: I58c899bb58c445d56c544828a52eddd720bc4847 Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/129840 Reviewed-by: Brandon Jones <bajones@chromium.org> Kokoro: Kokoro <noreply+kokoro@google.com> Reviewed-by: Austin Eng <enga@chromium.org> Commit-Queue: Corentin Wallez <cwallez@chromium.org>
This commit is contained in:
parent
161d8abf91
commit
96b61c56fa
|
@ -45,21 +45,12 @@ uint64_t Buffer::QueryMaxBufferLength(id<MTLDevice> mtlDevice) {
|
|||
#if DAWN_PLATFORM_IS(MACOS)
|
||||
// 10.12 and 10.13 have a 1Gb limit.
|
||||
if (@available(macOS 10.12, *)) {
|
||||
// |maxBufferLength| isn't always available on older systems. If available, use
|
||||
// |recommendedMaxWorkingSetSize| instead. We can probably allocate more than this,
|
||||
// but don't have a way to discover a better limit. MoltenVK also uses this heuristic.
|
||||
return 1024 * 1024 * 1024;
|
||||
}
|
||||
// 10.11 has a 256Mb limit
|
||||
if (@available(macOS 10.11, *)) {
|
||||
return 256 * 1024 * 1024;
|
||||
}
|
||||
// 256Mb for other platform if any. (Need to have a return for all branches).
|
||||
return 256 * 1024 * 1024;
|
||||
#else
|
||||
// macOS / tvOS: 256Mb limit in versions without [MTLDevice maxBufferLength]
|
||||
return 256 * 1024 * 1024;
|
||||
#endif
|
||||
|
||||
// 256Mb limit in versions without based on the data in the feature set tables.
|
||||
return 256 * 1024 * 1024;
|
||||
}
|
||||
|
||||
Buffer::Buffer(DeviceBase* dev, const BufferDescriptor* desc) : BufferBase(dev, desc) {}
|
||||
|
|
|
@ -213,7 +213,7 @@ NSRef<MTLRenderPassDescriptor> CreateMTLRenderPassDescriptor(
|
|||
switch (attachmentInfo.storeOp) {
|
||||
case wgpu::StoreOp::Store:
|
||||
descriptor.colorAttachments[i].storeAction =
|
||||
kMTLStoreActionStoreAndMultisampleResolve;
|
||||
MTLStoreActionStoreAndMultisampleResolve;
|
||||
break;
|
||||
case wgpu::StoreOp::Discard:
|
||||
descriptor.colorAttachments[i].storeAction = MTLStoreActionMultisampleResolve;
|
||||
|
|
|
@ -43,10 +43,8 @@ MTLTextureUsage MetalTextureUsage(const Format& format, wgpu::TextureUsage usage
|
|||
// See TextureView::Initialize.
|
||||
// Depth views for depth/stencil textures in Metal simply use the original
|
||||
// texture's format, but stencil views require format reinterpretation.
|
||||
if (@available(macOS 10.12, iOS 10.0, *)) {
|
||||
if (IsSubset(Aspect::Depth | Aspect::Stencil, format.aspects)) {
|
||||
result |= MTLTextureUsagePixelFormatView;
|
||||
}
|
||||
if (IsSubset(Aspect::Depth | Aspect::Stencil, format.aspects)) {
|
||||
result |= MTLTextureUsagePixelFormatView;
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -332,10 +330,8 @@ MTLPixelFormat MetalPixelFormat(const DeviceBase* device, wgpu::TextureFormat fo
|
|||
case wgpu::TextureFormat::Depth16Unorm:
|
||||
if (@available(macOS 10.12, iOS 13.0, *)) {
|
||||
return MTLPixelFormatDepth16Unorm;
|
||||
} else {
|
||||
// TODO(dawn:1181): Allow non-conformant implementation on macOS 10.11
|
||||
UNREACHABLE();
|
||||
}
|
||||
UNREACHABLE();
|
||||
case wgpu::TextureFormat::Stencil8:
|
||||
if (device->IsToggleEnabled(Toggle::MetalUseCombinedDepthStencilFormatForStencil8)) {
|
||||
return MTLPixelFormatDepth32Float_Stencil8;
|
||||
|
@ -1169,19 +1165,8 @@ MaybeError TextureView::Initialize(const TextureViewDescriptor* descriptor) {
|
|||
|
||||
Aspect aspect = SelectFormatAspects(GetFormat(), descriptor->aspect);
|
||||
if (aspect == Aspect::Stencil && textureFormat != MTLPixelFormatStencil8) {
|
||||
if (@available(macOS 10.12, iOS 10.0, *)) {
|
||||
if (textureFormat == MTLPixelFormatDepth32Float_Stencil8) {
|
||||
viewFormat = MTLPixelFormatX32_Stencil8;
|
||||
} else {
|
||||
UNREACHABLE();
|
||||
}
|
||||
} else {
|
||||
// TODO(enga): Add a workaround to back combined depth/stencil textures
|
||||
// with Sampled usage using two separate textures.
|
||||
// Or, consider always using the workaround for D32S8.
|
||||
return DAWN_INTERNAL_ERROR("Cannot create stencil-only texture view of combined "
|
||||
"depth/stencil format.");
|
||||
}
|
||||
ASSERT(textureFormat == MTLPixelFormatDepth32Float_Stencil8);
|
||||
viewFormat = MTLPixelFormatX32_Stencil8;
|
||||
} else if (GetTexture()->GetFormat().HasDepth() && GetTexture()->GetFormat().HasStencil()) {
|
||||
// Depth-only views for depth/stencil textures in Metal simply use the original
|
||||
// texture's format.
|
||||
|
|
|
@ -80,15 +80,6 @@ MaybeError EnsureDestinationTextureInitialized(CommandRecordingContext* commandC
|
|||
const TextureCopy& dst,
|
||||
const Extent3D& size);
|
||||
|
||||
// Allow use MTLStoreActionStoreAndMultismapleResolve because the logic in the backend is
|
||||
// first to compute what the "best" Metal render pass descriptor is, then fix it up if we
|
||||
// are not on macOS 10.12 (i.e. the EmulateStoreAndMSAAResolve toggle is on).
|
||||
#pragma clang diagnostic push
|
||||
#pragma clang diagnostic ignored "-Wunguarded-availability"
|
||||
constexpr MTLStoreAction kMTLStoreActionStoreAndMultisampleResolve =
|
||||
MTLStoreActionStoreAndMultisampleResolve;
|
||||
#pragma clang diagnostic pop
|
||||
|
||||
// Helper functions to encode Metal render passes that take care of multiple workarounds that
|
||||
// happen at the render pass start and end. Because workarounds wrap the encoding of the render
|
||||
// pass, the encoding must be entirely done by the `encodeInside` callback.
|
||||
|
|
|
@ -452,7 +452,7 @@ MaybeError EncodeMetalRenderPass(Device* device,
|
|||
std::array<id<MTLTexture>, kMaxColorAttachments> resolveTextures = {};
|
||||
for (uint32_t i = 0; i < kMaxColorAttachments; ++i) {
|
||||
if (mtlRenderPass.colorAttachments[i].storeAction ==
|
||||
kMTLStoreActionStoreAndMultisampleResolve) {
|
||||
MTLStoreActionStoreAndMultisampleResolve) {
|
||||
hasStoreAndMSAAResolve = true;
|
||||
resolveTextures[i] = mtlRenderPass.colorAttachments[i].resolveTexture;
|
||||
|
||||
|
|
Loading…
Reference in New Issue