darlinghq/darling-cocotron
1
0
Fork 0
mirror of https://github.com/darlinghq/darling-cocotron.git synced 2024-11-26 21:40:44 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
master
darling-cocotron/QuartzCore/CAMetalDrawableInternal.h

127 lines
4.4 KiB
C
Raw Permalink Normal View History

Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
/*
* This file is part of Darling.
*
* Copyright (C) 2022 Darling developers
*
* Darling is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* Darling is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with Darling. If not, see <http://www.gnu.org/licenses/>.
*/
#import <QuartzCore/CAMetalDrawable.h>
#import <Metal/MTLDrawableInternal.h>
#import <Metal/MTLTextureInternal.h>
#import <OpenGL/gl.h>
#import <OpenGL/OpenGL.h>
Make Metal an optional part of the build See the corresponding commit in the main repo
2022-12-31 18:16:50 +00:00
#if DARLING_METAL_ENABLED
Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
#include <indium/indium.private.hpp>
@class CAMetalLayerInternal;
class CAMetalDrawableTexture: public Indium::PrivateTexture {
CGSize _size;
VkImage _image = VK_NULL_HANDLE;
VkDeviceMemory _memory = VK_NULL_HANDLE;
VkImageView _imageView = VK_NULL_HANDLE;
GLuint _textureID = 0;
GLuint _memoryObject = 0;
Indium::PixelFormat _pixelFormat;
VkImage _internalImage = VK_NULL_HANDLE;
VkDeviceMemory _internalMemory = VK_NULL_HANDLE;
[mtl] Only require texture memory to be host-visible if it's not framebuffer-only
2023-04-11 12:16:16 +00:00
bool _framebufferOnly = false;
Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
public:
[mtl] Only require texture memory to be host-visible if it's not framebuffer-only
2023-04-11 12:16:16 +00:00
CAMetalDrawableTexture(CGSize size, Indium::PixelFormat pixelFormat, bool framebufferOnly, std::shared_ptr<Indium::PrivateDevice> privateDevice);
Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
virtual ~CAMetalDrawableTexture();
GLuint glTexture() const;
virtual VkImageView imageView() override;
virtual VkImage image() override;
virtual VkImageLayout imageLayout() override;
virtual Indium::TextureType textureType() const override;
virtual Indium::PixelFormat pixelFormat() const override;
virtual size_t width() const override;
virtual size_t height() const override;
virtual size_t depth() const override;
virtual size_t mipmapLevelCount() const override;
virtual size_t arrayLength() const override;
virtual size_t sampleCount() const override;
virtual bool framebufferOnly() const override;
virtual bool allowGPUOptimizedContents() const override;
virtual bool shareable() const override;
virtual Indium::TextureSwizzleChannels swizzle() const override;
virtual void replaceRegion(Indium::Region region, size_t mipmapLevel, const void* bytes, size_t bytesPerRow) override;
virtual void replaceRegion(Indium::Region region, size_t mipmapLevel, size_t slice, const void* bytes, size_t bytesPerRow, size_t bytesPerImage) override;
virtual void precommit(std::shared_ptr<Indium::PrivateCommandBuffer> cmdbuf) override;
virtual bool needsExportablePresentationSemaphore() const override;
};
class CAMetalDrawableActual: public Indium::Drawable {
private:
std::shared_ptr<CAMetalDrawableTexture> _texture = nullptr;
CAMetalLayerInternal* _layer = nil;
std::shared_ptr<Indium::BinarySemaphore> _semaphore = nullptr;
GLuint _glSemaphore = 0;
Ensure objc presented handlers are invoked Previously, they would only be invoked if the `present` method was invoked directly on the objc drawable object.
2022-12-28 02:02:08 +00:00
std::function<void()> _wantsToPresentCallback = nullptr;
std::function<void()> _didPresentCallback = nullptr;
Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
NSUInteger _drawableID = NSUIntegerMax;
CFTimeInterval _presentedTime = 0;
bool _queued = false;
CGLContextObj _glContext = nullptr;
public:
CAMetalDrawableActual(CAMetalLayerInternal* layer, CGSize size, NSUInteger drawableID, Indium::PixelFormat pixelFormat, std::shared_ptr<Indium::Device> device, CGLContextObj _glContext);
virtual ~CAMetalDrawableActual();
virtual void present() override;
std::shared_ptr<CAMetalDrawableTexture> texture();
NSUInteger drawableID() const;
CFTimeInterval presentedTime() const;
Ensure objc presented handlers are invoked Previously, they would only be invoked if the `present` method was invoked directly on the objc drawable object.
2022-12-28 02:02:08 +00:00
void setWantsToPresentCallback(std::function<void()> wantsToPresentCallback);
void setDidPresentCallback(std::function<void()> didPresentCallback);
Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
void disown();
void synchronizeRender();
void didPresent();
void didDrop();
// this has nothing to do with memory management; this indicates that the drawable is no longer in use and can be recycled
void release();
void reset();
};
Make Metal an optional part of the build See the corresponding commit in the main repo
2022-12-31 18:16:50 +00:00
#endif
@interface CAMetalDrawableInternal : NSObject <CAMetalDrawable, MTLDrawableInternal>
Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
Make Metal an optional part of the build See the corresponding commit in the main repo
2022-12-31 18:16:50 +00:00
#if DARLING_METAL_ENABLED
{
Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
NSUInteger _drawableID;
CFTimeInterval _presentedTime;
std::shared_ptr<CAMetalDrawableActual> _drawable;
MTLTextureInternal* _texture;
CAMetalLayer* _layer;
NSMutableArray<MTLDrawablePresentedHandler>* _presentedHandlers;
}
- (instancetype)initWithLayer: (CAMetalLayer*)layer
drawable: (std::shared_ptr<CAMetalDrawableActual>)drawable;
Make Metal an optional part of the build See the corresponding commit in the main repo
2022-12-31 18:16:50 +00:00
#endif
Initial support for Metal layers and drawables In its current state, I consider this code to be experimental and unstable. The biggest problem is that there's currently a HUGE memory leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing what I have now since I don't feel like debugging that right now and it *does* technically work as-is. The current approach is not great for performance: first, we render to a Metal/Vulkan texture in the desired format then blit that to an RGBA Metal/Vulkan texture shared with OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer to use as the content for the layer (we can't keep the drawable's OpenGL texture, since that has to be recycled). Finally, this is rendered to a subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy since we must render to the subwindow somehow and it's the easiest way to play nice with sublayers. I also don't think we can get rid of the first copy since OpenGL doesn't support some of Metal/Vulkan's texture formats; plus, we can't share optimally tiled images between Vulkan and OpenGL with some vendors' drivers (e.g. AMD). We *could* get rid of the second copy if we were able to accurately determine when the content is finally presented; then we could simply keep the drawable in-use, render it to the subwindow when asked to, and release it once we know the render is complete.
2022-12-26 05:03:28 +00:00
@end
Reference in New Issue Copy Permalink