Hi, I've got a Swift Framework with a bunch of Metal files. Currently users have to manually include a Metal Lib in their bundle provided separately, to use the Swift Package.
First question; Is there a way to make a Metal Lib target in a Swift Package, and just include the .metal files? (without a binary asset)
Second question; If not, Swift 5.3 has resource support, how would you recommend to bundle a Metal Lib in a Swift Package?
I am trying to build scover "Ray Tracing with Metal" on iMac Pro 2017, but got this error:
2020-06-25 14:29:35.233058+0200 MTLRaytracingSample-macOS[3602:145531] Failed to set (contentViewController) user defined inspected property on (NSWindow): Ray tracing isn't supported on this device
Xcode 12
Big Sur 11.0 Beta (20A4299v)
iMac Pro 2017
3,2 GHz 8-Core Intel Xeon W
32 GB 2666 MHz DDR4
Radeon Pro Vega 56 8 GB
What is the required hardware configuration?
Post not yet marked as solved
I have a complex CAS loop with branches that essentially implement a mutex and I'm porting it from CUDA to Metal. I'm looking for the equivalent of CUDA __treadfence();
=> docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#synchronization-functions
Unfortunately metal::threadgroup_barrier(metal::mem_flags::mem_device) also implies execution synchronization and needs to be "seen" by all threads or deadlock.
I need to have one store to buffer A happen before another store to buffer B.
Atomic memory oder options are only one: "relaxed".
How to accomplish this ordering guarantee?
Post not yet marked as solved
Hey everyone,
I have been working on a Metal Renderer and I would like to set this up as a Swift Package. However I am running into some issues with setting up the package and I have not been able to find a solution, so I thought I'd give it a shot here.
To keep it simple, in my project I have a .swift file doing the rendering, a .metal file that contains my shader code and a .h file (which is a bridging header in my project) which contains stuff like Types to be shared between the metal shaders and the swift code.
I am stuck of how I can include the .h and .metal files in the swift package. Right now the swift file doesn't pick up on the stuff inside the header file and the metal file is just loaded with errors as if it doesn't recognize the file type. Ideally I would also like to expose this header to the outside.
Has anyone ever done something like this, or know if this is even possible?
Thanks in advance, and kind regards
Post not yet marked as solved
I am currently developing applicsation using Metal for MacOS.
When the sample program "CreatingAndSamplingTextures" is run, the memory used will gradually increase.
Will this increasing memory be released someday? Or does the sample require the omitted release process? (It seems that the memory used increases like other samples)
If you create the product level code as it is, if the memory usage increases in the same way, it will not be able to withstand long-term use, so please answer.
Hi everyone,
Running Xcode 12, I'm developing a standalone WatchOS App using Spritekit.
I'm using a simple Palette-swap shader using a SKShader with several SKAttributes.
The shader seems to work fine, however I get the following message in the console: [Metal Compiler Warning] Warning: Compilation succeeded with:
program_source:3:19: warning: unused variable 's'
constexpr sampler s(coord::normalized,
I have no idea what this means, there is no variable 's' in my code so I guess this is an issue because GLGS shader code gets compiled to Metal in the background and it goes wrong there? How do I verify this? It seems there is a memory leak associated with this error so I'm prone to solve it. Any help would be appreciated, even if it's just pointing me in a direction. (Like, should I write a new palette shader in Metal?) Thanks in advance!
The function that adds the SKShader (an extension to SKSpriteNode):
func addMultiColorShader(strokeColor: UIColor, colors:[UIColor]) {
let useColors:[UIColor] = shaderColors(colors)
var attributes:[SKAttribute] = [SKAttribute(name: "a_size", type: .vectorFloat2),
SKAttribute(name: "a_scale", type: .vectorFloat2),
SKAttribute(name: "a_alpha", type: .float)]
let colorNames:[String] = ["a_color0","a_color1","a_color2","a_color3"]
for i in 0..<colorNames.count {
attributes += [SKAttribute(name: colorNames[i], type: .vectorFloat4)]
}
let shader = SKShader(fromFile: "SKHMultiColorize", attributes: attributes)
setShaderAttributes(size: self.size, scale: CGSize(width: self.xScale, height: self.yScale), alpha: self.alpha)
setShaderColors(strokeColor: strokeColor, color1: useColors[0], color2: useColors[1], color3: useColors[2])
self.shader = shader
}
The actual shader code (OpenGL GS):
vec2 nearestNeighbor(vec2 loc, vec2 size) {
vec2 onePixel = vec2(1.0, 1.0) / size;
vec2 coordinate = floor(loc * size) / size; // round
return coordinate + (onePixel * 0.5);
}
void main()
{
vec4 colors[4];
colors[0] = a_color0;
colors[1] = a_color1;
colors[2] = a_color2;
colors[3] = a_color3;
vec4 currentColor = texture2D(u_texture, nearestNeighbor(v_tex_coord, a_size));
int colorIndex = int((currentColor.r * 5.1));
vec4 refColor = colors[colorIndex];
gl_FragColor = refColor * currentColor.a;
}
Post not yet marked as solved
I notice that when I open the Photos app on my iPhone 12 Pro, viewing Photos or Videos shot in HDR makes them brighter than the overall display brightness level.
On macOS, there are APIs like EDRMetadata on CAMetalLayer and maximumExtendedDynamicRangeColorComponentValue on NSScreen.
I did see
CAMetalLayer.wantsExtendedDynamicRangeContent, but I'm not sure if this does what I'm looking for.
The "Using Color Spaces to Display HDR Content" - https://developer.apple.com/documentation/metal/drawable_objects/displaying_hdr_content_in_a_metal_layer/using_color_spaces_to_display_hdr_content?language=objc documentation page describes setting the .colorspace on the CAMetalLayer for BT2020_PQ content, but it's not clear if this is referring to macOS or iOS. Is that the right way to get colors to be "brighter" than 1.0 on "XDR" mobile displays?
Post not yet marked as solved
I have CVPixelBuffer's in kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange, which is 10 bit HDR. I need to convert these to RGB and display in MTKView. I need to know the correct pixel format to use, the BT2020 conversion matrix, and displaying the 10 bit RGB pixel buffer in MTKView.
Hello,
We recently noticed that copying pixel data from a meta texture to memory is a lot slower on the new iPhones equipped with the A14 Bionic.
We tracked down the guilty function on MTLTexture and found that getBytes(_:bytesPerRow:from:mipmapLevel: runs 8 to 20 times slower than 2 years old iPhones (iPhone XR). To measure how long it takes, we used signposts.
We've created a dummy demo project where we convert a MTLTexture to a CVPixelBuffer in this project: https://github.com/alikaragoz/UsingARenderPipelineToRenderPrimitives
The interesting part is located at this line: https://github.com/alikaragoz/UsingARenderPipelineToRenderPrimitives/blob/41f7f4385a490e889b94ee2c8913ce532a43aacb/Renderer/MetalUtils.swift#L40
Do you guys have an idea about what could be the issue?
Post not yet marked as solved
I see reasonable numbers from this on macOS, but on iPad I see really large numbers from this, and in the gpu capture that don't add up. This is Xcode 12.2 and and iPad 14.0.1.
Textures and Buffers add up to 261MB which is close to the macOS. The memory summary, and the "other" area in the buffers area report 573MB when I hover over that. Also device.currentAllocatedSize reports 868MB total. I assume the buffer size is skewing the memory totals, since Xcode reports 620MB for the entire app.
I would attach a screenshot of the gpu capture showing the memory capture, but seems that the new forums don't support this, and not being able to search categories anymore is rather limiting.
Non-voliatile 261
Volatile 0
Textures 195
Buffers 66 <- but hover over "other" reports 573
Private 184
Shared 77
Used 166
Unused 95
Post not yet marked as solved
I am a hobbyist programmer and I have been fooling around with Metal. In getting my feet wet in metal I have found that there is a pretty big gap between the HelloTriangle and DeferredLighting sample code from Apple and a more intermediate sample would be helpful. I have stumbled along through the brush and put together a little app that I thought that other novice metal programmers might find interesting.
Features: Vertex buffer creation in Object Space.
Composing objects into a scene in Model Space.
Transforming a scene in Model Space to Clip Space
Hit Testing / Mouse Picking
Two pass rendering to produce shadows.
I have put the project on GitHub for others to peruse:
github.com/MackenzieBD/Sample-Code/blob/main/MetalDemo.zip
I am using a MTLSharedEvent to occasionally relay new information from the CPU to the GPU by writing into a MTLBuffer with storage mode .storageModeManaged within a block registered by the shared event (using the notify(_:atValue:block:) method of MTLSharedEvent, with a MTLSharedEventListener configured to be notified on a background dispatch queue). The process looks something like this:
let device = MTLCreateSystemDefaultDevice()!
	let synchronizationQueue = DispatchQueue(label: "com.myproject.synchronization")
		
		let sharedEvent = device.makeSharedEvent()!
		let sharedEventListener = MTLSharedEventListener(dispatchQueue: synchronizationQueue)
		
		// Updated only occasionally on the CPU (on user interaction). Mostly written to
		// on the GPU
		let managedBuffer = device.makeBuffer(length: 10, options: .storageModeManaged)!
		
		var doExtra = true
func computeSomething(commandBuffer: MTLCommandBuffer) {
	
	 // Do work on the GPU every frame
	 // After writing to the buffer on the GPU, synchronize the buffer (required)
	 let blitToSynchronize = commandBuffer.makeBlitCommandEncoder()!
				blitToSynchronize.synchronize(resource: managedBuffer)
				blitToSynchronize.endEncoding()
				
	 // Occassionally, add extra information on the GPU
	 if doExtraWork {
					
			 // Register a block to write into the buffer
			sharedEvent.notify(sharedEventListener, atValue: 1) { event, value in
								
						 // Safely write into the buffer. Make sure we call `didModifyRange(_:)` after
								
						// Update the counter
						event.signaledValue = 2
			}
		 commandBuffer.encodeSignalEvent(sharedEvent, value: 1)
		 commandBuffer.encodeWaitForEvent(sharedEvent, value: 2)
	 }
				
				// Commit the work
			 commandBuffer.commit()
}
The expected behavior is as follows:
The GPU does some work with the managed buffer
Occasionally, the information needs to be updated with new information on the CPU. In this frame, we register a block of work to be executed. We do so in a dedicated block because we cannot guarantee that by the time execution on the main thread reaches this point the GPU is not simultaneously reading from or writing to the managed buffer. Hence, it is unsafe to simply write to it currently and must make sure the GPU is not doing anything with this data
When the GPU schedules this command buffer to be executed, commands executed before the encodeSignalEvent(_:value:) call are executed and then execution on the GPU stops until the block increments the signaledValue property of the event passed into the block
When execution reaches the block, we can safely write into the managed buffer because we know the CPU has exclusive access to the resource. Once we've done so, we resume execution of the GPU
The issue is that it seems Metal is not calling the block when the GPU is executing the command, but rather *before* the command buffer is even scheduled. Worse, the system seems to "work" with the initial command buffer (the very first command buffer, before any other are scheduled).
I first noticed this issue when I looked at a GPU frame capture after my scene would vanish after a CPU update, which is where I saw that the GPU had NaNs all over the place. I then ran into this strange situation when I purposely waited on the background dispatch queue with a sleep(:_) call. Quite correctly, my shared resource semaphore (not shown, signaled in a completion block of the command buffer and waited on in the main thread) reached a value of -1 after committing three command buffers to the command queue (three being the number of recycled shared MTLBuffers holding scene uniform data etc.). This suggests that the first command buffer has not finished executing by then time the CPU is more than three frames ahead, which is consistent with the sleep(_:) behavior. Again, what isn't consistent is the ordering: Metal seems to call the block before even scheduling the buffer. Further, in subsequent frames, it doesn't seem that Metal cares that the sharedEventListener block is taking so long and schedules the command buffer for execution even while the block is running, which finishes dozens of frames later.
This behavior is completely inconsistent with what I expect. What is going on here?
P.S.
There is probably a better way to periodically update a managed buffer whose contents are mostly
modified on the GPU, but I have not yet found a way to do so. Any advice on this subject is appreciated as well. Of course, a triple buffer system *could* work, but it would waste a lot of memory as the managed buffer is quite large (whereas the shared buffers managed by the semaphore are quite small)
Post not yet marked as solved
I hope someone here can give me some insight, because I am at my wits end.
I have been trying to learn Metal the past couple of months. In the process, I came across an examples and articles of Sorting Networks and decided to try and implement them in Metal.
Now the problem is, if I run the code on my Mac. Everything is fine. But if I run the the same code on my iDevice (iPadPro wLIDAR), I get all sort of errors I do not understand or sorted data is corrupted and all wrong.
Typical Error
2021-02-17 12:13:11.218394-0500 METAL_ISSUE[97650:6709092] [GPUDebug] Invalid device load executing kernel function "bitonicSort" encoder: "0", dispatch: 0, at offset 384
file:///Users/staque/Development/OTHER/METAL_ISSUE/METAL_ISSUE/Shaders.metal:77:40 - bitonicSort()
MTLBufferArgument: 0x28006d200
Name = floats
Type = MTLArgumentTypeBuffer
Access = MTLArgumentAccessReadWrite
LocationIndex = 0
IsActive = 1
ArrayLength = 1
TypeInfo =
DataType = MTLDataTypePointer
ElementType = MTLDataTypeFloat
Access = MTLArgumentAccessReadWrite
Alignment = 4
DataSize = 4
Alignment = 4
DataSize = 4
DataType = MTLDataTypeFloat
buffer: "unknown"
You can pretty much drop these in the default Xcode Metal Game default app.
Shader (slightly modified to track the indexes of the floats.)
/*
[Using Code based off of this](https://github.com/tgymnich/MetalSort)
Rewritten to make it more understandable.
*/
kernel void bitonicSort(device float *floats [[ buffer(0) ]],
device int *uInts [[ buffer(1) ]],
constant int &p [[ buffer(2) ]],
constant int &q [[ buffer(3) ]],
uint gid [[ thread_position_in_grid ]])
{
int pMinusQ = p-q;
int distance = 1 pMinusQ;
uint gidShiftedByP = gid p;
// True: Increasing / False: Descreasing
bool direction = (gidShiftedByP & 2) == 0;
uint gidDistance = (gid & distance);
bool isGidDistanceZero = (gidDistance == 0);
uint gidPlusDistance = (gid | distance);
bool isLowerIndexGreaterThanHigher = (floats[gid] floats[gidPlusDistance]);
if (isGidDistanceZero && isLowerIndexGreaterThanHigher == direction) {
float temp = floats[gid];
floats[gid] = floats[gidPlusDistance];
floats[gidPlusDistance] = temp;
int temp2 = uInts[gid];
uInts[gid] = uInts[gidPlusDistance]
uInts[gidPlusDistance] = temp2;
}
}
The call.
language
func runSort() {
let device = MTLCreateSystemDefaultDevice()!
let commandQueue = device.makeCommandQueue()!
let library = device.makeDefaultLibrary()!
let sortFunction = library.makeFunction(name: "bitonicSort")!
let pipeline = try! device.makeComputePipelineState(function: sortFunction)
let setRange = 0..1024
var floatData = [Float]()
var uintData = [UInt32]()
// Build the Float and index data backward to form worst case scenerio for sorting.
for value in stride(from: Float(setRange.upperBound-1), to: Float(setRange.lowerBound-1), by: -1.0) {
floatData.append(value)
}
for value in stride(from: setRange.upperBound-1, to: setRange.lowerBound-1, by: -1) {
uintData.append(UInt32(value))
}
print(floatData)
print("")
print(uintData)
guard let logn = Int(exactly: log2(Double(floatData.count))) else {
fatalError("data.count is not a power of 2")
}
for p in 0..logn {
for q in 0..p+1 {
let floatDataBuffer = device.makeBuffer(bytes: &floatData,
length: MemoryLayoutFloat.stride * floatData.count,
options: [.storageModeShared])!
floatDataBuffer.label = "floatDataBuffer"
let uintDataBuffer = device.makeBuffer(bytes: &uintData,
length: MemoryLayoutUInt32.stride * uintData.count,
options: [.storageModeShared])!
uintDataBuffer.label = "uintDataBuffer"
let threadgroupsPerGrid = MTLSize(width: floatData.count, height: 1, depth: 1)
let threadsPerThreadgroup = MTLSize(width: pipeline.threadExecutionWidth, height: 1, depth: 1)
var n1 = p
var n2 = q
let commandBuffer = commandQueue.makeCommandBuffer()!
let encoder = commandBuffer.makeComputeCommandEncoder()!
encoder.setComputePipelineState(pipeline)
encoder.setBuffer(floatDataBuffer, offset: 0, index: 0)
encoder.setBuffer(uintDataBuffer, offset: 0, index: 1)
encoder.setBytes(&n1, length: MemoryLayoutFloat.stride, index: 2)
encoder.setBytes(&n2, length: MemoryLayoutUInt32.stride, index: 3)
encoder.dispatchThreadgroups(threadgroupsPerGrid, threadsPerThreadgroup: threadsPerThreadgroup)
encoder.endEncoding()
commandBuffer.commit()
commandBuffer.waitUntilCompleted()
let dataPointer = floatDataBuffer.contents().assumingMemoryBound(to: Float.self)
let dataBufferPointer = UnsafeMutableBufferPointer(start: dataPointer, count: floatData.count)
floatData = Array.init(dataBufferPointer)
let dataPointer2 = uintDataBuffer.contents().assumingMemoryBound(to: UInt32.self)
let dataBufferPointer2 = UnsafeMutableBufferPointer(start: dataPointer2, count: uintData.count)
uintData = Array.init(dataBufferPointer2)
}
}
print(floatData)
print("")
print(uintData)
}
If anyone has a clue what I should be doing I am all ears, because I need help.
Thanks in advance.
Stan
Post not yet marked as solved
I am trying to use the new LiDAR scanner on the iPhone 12 Pro in order to gather points clouds which later on will be used as input data for neural networks.
Since I am relatively new to the field of computer vision and augmented reality, I started by looking at the official code examples (e.g., Visualizing a Point Cloud Using Scene Depth - https://developer.apple.com/documentation/arkit/environmental_analysis/visualizing_a_point_cloud_using_scene_depth) and the documentation of ARKit, SceneKit, Metal and so. However, I still do not understand how to get the LiDAR data.
I found another thread in this forum (Exporting Point Cloud as 3D PLY Model - https://developer.apple.com/forums/thread/658109) and the given solution works so far. However, I do not understand that code in detail, unfortunately. So I am not sure if this gives me really the raw LiDAR data or if some (internal) fusion with other (camera) data is happening, since I could not figure out where the data comes from exactly in the example.
Could you please give me some tips or code examples on how to work with/access the LiDAR data? It would be very much appreciated!
Post not yet marked as solved
On a dynamic switching capable Mac, calling MTLCreateSystemDefaultDevice() in a Metal app is supposed to return the discrete GPU and have the system switch the display to being driven by the discrete GPU. As explained in the comment in MTLDevice.h above that method:
"On Mac OS X systems that support automatic graphics switching, calling this API to get a Metal device will cause the system to switch to the high power GPU. On other systems that support more than one GPU it will return the GPU that is associated with the main display."
However on my application I am not seeing this occur anymore. I've tested the app on a Catalina partition on the exact same machine and verified it would work properly on 10.15.7 but on any build of Big Sur I have tried so far, it hasn't worked.
I even tested this functionality using one of Apple's demo apps (can find it by searching for "Using Metal to Draw a View's Contents"). It is a very simple app that just draws a blue screen but when ran on Catalina, I verified that dynamic switching was occurring properly (Activity Monitor's energy section will list the app with a Yes in the Graphics Card column specifying that it requires a High Performance GPU). For an app running via Xcode, it will change Xcode to have a Yes in the Graphics Card column. Running the exact same demo on Big Sur no longer triggers that change.
Note: You have to make sure you are using a machine with the Automatic Graphics Switching option enabled in the battery settings of System Preferences and you can't be connected to an external display (this will force the system to use the discrete gpu).
Has anyone else seen this issue? And if so, has anyone managed to fix it? I wasn't able to find any mention of a new api or an api change that is needed for this. I have also tried using NSSupportsAutomaticGraphicsSwitching in the Info.plist of the app set to both YES or NO, just in case maybe the api was updated to listen to that flag for Metal, but it had no effect.
I have submitted a ticket for this using the Feedback Assistant app, but I wanted to see if any other developers have been having this issue as well or have found a solution.
Hello,
So before on XCode 10.3 on MacOS Mojave my code worked without any problems.
However I have since upgraded to XCode 12.4 with MacOS Catalina (10.15.7)
Now when I attempt:
id MTLRenderPipelineState pcMTLRenderPipeLineState = [pcMTLDevice newRenderPipelineStateWithDescriptor: pcMTLRenderPipeLineDesc error: &pcError];
I get the following error:
Compiler failed to build request
CMetalPipeLineState::Create: Failed to generate a pipeline state object: Error Domain=AGXMetalA7 Code=1 "Could not resolve texture/samplers references" UserInfo={NSLocalizedDescription=Could not resolve texture/samplers references}
Does anyone have any idea what could be causing this?
The full debug output is shown below:
CMetalPipeLineState::Create: Descriptor: MTLRenderPipelineDescriptorInternal: 0x1701b5c40
{
"Alpha to Coverage" = 0;
"Alpha to One" = 0;
"Blend States" = (
{
"Alpha Blend Operation" = MTLBlendOperationAdd;
"Blending Enabled" = 0;
"Destination Alpha Blend Factor" = MTLBlendFactorZero;
"Destination RGB Blend Factor" = MTLBlendFactorZero;
"Pixel Format" = "MTLPixelFormatBGRA8Unorm_sRGB";
"RGB Blend Operation" = MTLBlendOperationAdd;
"Source Alpha Blend Factor" = MTLBlendFactorOne;
"Source RGB Blend Factor" = MTLBlendFactorOne;
"Write Mask" = RGBA;
},
{
"Alpha Blend Operation" = MTLBlendOperationAdd;
"Blending Enabled" = 0;
"Destination Alpha Blend Factor" = MTLBlendFactorZero;
"Destination RGB Blend Factor" = MTLBlendFactorZero;
"Pixel Format" = MTLPixelFormatInvalid;
"RGB Blend Operation" = MTLBlendOperationAdd;
"Source Alpha Blend Factor" = MTLBlendFactorOne;
"Source RGB Blend Factor" = MTLBlendFactorOne;
"Write Mask" = RGBA;
},
{
"Alpha Blend Operation" = MTLBlendOperationAdd;
"Blending Enabled" = 0;
"Destination Alpha Blend Factor" = MTLBlendFactorZero;
"Destination RGB Blend Factor" = MTLBlendFactorZero;
"Pixel Format" = MTLPixelFormatInvalid;
"RGB Blend Operation" = MTLBlendOperationAdd;
"Source Alpha Blend Factor" = MTLBlendFactorOne;
"Source RGB Blend Factor" = MTLBlendFactorOne;
"Write Mask" = RGBA;
},
{
"Alpha Blend Operation" = MTLBlendOperationAdd;
"Blending Enabled" = 0;
"Destination Alpha Blend Factor" = MTLBlendFactorZero;
"Destination RGB Blend Factor" = MTLBlendFactorZero;
"Pixel Format" = MTLPixelFormatInvalid;
"RGB Blend Operation" = MTLBlendOperationAdd;
"Source Alpha Blend Factor" = MTLBlendFactorOne;
"Source RGB Blend Factor" = MTLBlendFactorOne;
"Write Mask" = RGBA;
},
{
"Alpha Blend Operation" = MTLBlendOperationAdd;
"Blending Enabled" = 0;
"Destination Alpha Blend Factor" = MTLBlendFactorZero;
"Destination RGB Blend Factor" = MTLBlendFactorZero;
"Pixel Format" = MTLPixelFormatInvalid;
"RGB Blend Operation" = MTLBlendOperationAdd;
"Source Alpha Blend Factor" = MTLBlendFactorOne;
"Source RGB Blend Factor" = MTLBlendFactorOne;
"Write Mask" = RGBA;
},
{
"Alpha Blend Operation" = MTLBlendOperationAdd;
"Blending Enabled" = 0;
"Destination Alpha Blend Factor" = MTLBlendFactorZero;
"Destination RGB Blend Factor" = MTLBlendFactorZero;
"Pixel Format" = MTLPixelFormatInvalid;
"RGB Blend Operation" = MTLBlendOperationAdd;
"Source Alpha Blend Factor" = MTLBlendFactorOne;
"Source RGB Blend Factor" = MTLBlendFactorOne;
"Write Mask" = RGBA;
},
{
"Alpha Blend Operation" = MTLBlendOperationAdd;
"Blending Enabled" = 0;
"Destination Alpha Blend Factor" = MTLBlendFactorZero;
"Destination RGB Blend Factor" = MTLBlendFactorZero;
"Pixel Format" = MTLPixelFormatInvalid;
"RGB Blend Operation" = MTLBlendOperationAdd;
"Source Alpha Blend Factor" = MTLBlendFactorOne;
"Source RGB Blend Factor" = MTLBlendFactorOne;
"Write Mask" = RGBA;
},
{
"Alpha Blend Operation" = MTLBlendOperationAdd;
"Blending Enabled" = 0;
"Destination Alpha Blend Factor" = MTLBlendFactorZero;
"Destination RGB Blend Factor" = MTLBlendFactorZero;
"Pixel Format" = MTLPixelFormatInvalid;
"RGB Blend Operation" = MTLBlendOperationAdd;
"Source Alpha Blend Factor" = MTLBlendFactorOne;
"Source RGB Blend Factor" = MTLBlendFactorOne;
"Write Mask" = RGBA;
}
);
"Depth Attachment Format" = MTLPixelFormatDepth32Float;
"Fragment Depth Compare Clamp Mask" = 0x0;
"Fragment Function" = "MTLDebugFunction: 0x170272200 - _MTLFunctionInternal: 0x170196da0\n{\n attributes = \"null\";\n device = \"AGXA7Device: 0x101728000\\n{\\n name = \\\"Apple A7 GPU\\\";\\n}\";\n functionType = MTLFunctionTypeFragment;\n name = \"diffuse_main_ps\";\n}";
"Rasterization Enabled" = 1;
"Sample Count" = 1;
"Sample Coverage" = 1;
"Sample Mask" = 0xffffffffffffffff;
"Stencil Attachment Format" = MTLPixelFormatInvalid;
"Vertex Depth Compare Clamp Mask" = 0x0;
"Vertex Array" = "null";
"Vertex Enabled" = 1;
"Vertex Function" = "MTLDebugFunction: 0x170271f40 - _MTLFunctionInternal: 0x170196720\n{\n attributes = \"null\";\n device = \"AGXA7Device: 0x101728000\\n{\\n name = \\\"Apple A7 GPU\\\";\\n}\";\n functionType = MTLFunctionTypeVertex;\n name = \"diffuse_vp_main_vs\";\n}";
label = "null";
maxTessellationFactor = 16;
tessellationControlPointIndexType = MTLTessellationControlPointIndexTypeNone;
tessellationFactorFormat = MTLTessellationFactorFormatHalf;
tessellationFactorScaleEnabled = 0;
tessellationFactorStepFunction = MTLTessellationFactorStepFunctionConstant;
tessellationOutputWindingOrder = MTLWindingClockwise;
tessellationPartitionMode = MTLTessellationPartitionModePow2;
}
Post not yet marked as solved
Hi,
since installing Xcode 12 i get these messages in Xcode log console when running my macOS app.
the first message is the reguler Metal app validation but the other two are new.
what should i do?
do i just ignore them ?
2021-04-29 18:34:36.979153+0300 myMoney[1174:48679] Metal API Validation Enabled
2021-04-29 18:34:37.011809+0300 myMoney[1174:48679] MTLIOAccelDevice bad MetalPluginClassName property (null)
2021-04-29 18:34:37.012653+0300 myMoney[1174:48679] +[MTLIOAccelDevice registerDevices]: Zero Metal services found
thanks for your time,
Post not yet marked as solved
I am getting an error from the graphics driver while converting the EnvironmentTexture(from ARKIT.AREnvironmentProbeAnchor) to CVPixelBuffer. The EnvironmentTexture is an IMTLTexture. I am using Xamarin.iOS.
This is the code that I use to convert the IMTLTexture to CVPixelBuffer.
buffers[i] = new CVPixelBuffer((nint)epAnchor.EnvironmentTexture.Width, (nint)epAnchor.EnvironmentTexture.Height, CVPixelFormatType.CV32RGBA);
GetEnvironmentTextureSlice(buffers[i], epAnchor.EnvironmentTexture, i);
public void GetEnvironmentTextureSlice(CVPixelBuffer pixelBuffer, Metal.IMTLTexture texture, int id)
{
Metal.MTLRegion mtlRegion = Metal.MTLRegion.Create2D((nuint)0, 0, 256, 256);
nuint bytesPerPixel = 4;
nuint bytesPerRow = bytesPerPixel * (nuint)mtlRegion.Size.Width; // (nuint)pixelBuffer.BytesPerRow;
nuint bytesPerImage = bytesPerRow * (nuint)mtlRegion.Size.Height;
pixelBuffer.Lock(CVPixelBufferLock.None);
texture.GetBytes(pixelBuffer.BaseAddress, (nuint)pixelBuffer.BytesPerRow, mtlRegion, 0);
pixelBuffer.Unlock(CVPixelBufferLock.None);
}
The error I am getting from the driver is AGX: Texture read/write assertion failed: bytes_per_row = used_bytes_per_row
I tried with different values of pixelBuffer.BytesPerRow but still getting the error. Can someone help me?
Post not yet marked as solved
Hello,
It looks like my previous question was closed without being resolved.
https://developer.apple.com/forums/thread/668171
There are FPS values from our new benchmark.
Indirect command buffers are not working properly.
So there is no way to emulate multi-draw indirect count
functionality other than a loop of draw indirect commands. As you can see below, the same hardware is working three times slower under Metal because of it. And Apple M1 performance is worse than AMD integrated graphics performance.
We have a buffer with multiple draw commands. How should we render it efficiently under Metal?
AMD Vega 56 eGPU:
Direct3D12: 94.0
Direct3D11: 87.2
Vulkan: 91.1
Metal: 35.8
AMD Ryzen™ 7 4800H:
Direct3D12: 21.1
Direct3D11: 19.4
Vulkan: 20.5
Apple M1:
Metal: 16.9
Thank you
Post not yet marked as solved
This breaks shader hotloading and has been a persistent bug in Metal for the past many years. Metal holds onto some existing lib, returns it, without checking that the data content has changed. Similar bugs happen with Metal's shader cache not checking modification timestamps.
In my case, I'm just changing a color in the shader from float3(1,0,0) to float3(1,1,0) and then never seeing the result of the shader change. The new metallib is loaded from disk, and handed off to newLibraryWithData.
I can tell that it's returning a cached metallib, because we set a label on the MTLFunction that is returned. That's not nil on the first load of the shader, and after the hotload of the new metallib the label is non-nil. So we just see the old shader content.
This is a very important Radar to fix.
