Post not yet marked as solved
Is this a new development? I have a texture viewer that I develop, and Metal is failing to create a texture for ETC2_RGBA textures when the type is a 3D texture. 2d, cube, and 2d array seem to have support. Are other ETC2 textures preserved as compressed textures in the L1, or are these being decompressed?
Post not yet marked as solved
I'm trying to update all my projects to C++20. The C++ only projects work fine. All the Objective-C++ files, though, suddenly stop compiling. Is this supposed to work. I can't imagine [NSString stringWithUTF8String:foo] should be failing. Setting the project back to C++17 works.
I do have -fmodules and -fcxx-modules for clang modules in some projects. Do those all need to be removed for C++20 modules?
Post not yet marked as solved
I'm hoping the answer here is that the fp16 values get written out to the parameter buffer to save space on TBDR, but then the gpu promotes them back to fp32 for interpolation, and then back to fp16 for the receiving fragment shader. This would then work around banding if the output and interpolation was done in fp16 math like on Android. There is no documentation that I've found on this, or even on the PowerVR documentation about their gpu.
Post not yet marked as solved
For as long as I've used Xcode, the Issue navigator shows stale errors and warnings even after the build is completely building and executing. It would be nice to have a way to retain file warnings without having to set "warnings as errors", but here the problems have already been fixed.
Also need a "Reveal in Report Navigator" since half the time these errors/warnings lack 90% of the info needed to actually fix them. There's already a "Reveal in Project Navigator" that is almost never needed.
Post not yet marked as solved
All major platform pthread APIs except for Apple, provide a pthread_setname_np call that takes a pthread_t handle as the first argument. Even pthread_getname_np takes a pthread_t handle. But Apple, only allows setting the name from within the thread. This means std::thread abstractions in C++ can't or don't provide a reasonable call to set or change the thread name from another thread.
pthread_setname_np(pthread_t thread, const char* name); <- standard api
pthread_setname_np(const char* name); <- Apple's api
Could this be standardized? Given that [NSThread setName:] exists and can perform this function, there must be a way to perform this.
Post not yet marked as solved
I have an scrolling NSTableView that has an isFlipped MTKView as the parent. No matter how I set the growth constraints, frame.y (which seems to offset from bottom left still) or adjust the height, I can't get a gap from the top. I have a hud that this then clobbers over. I want to offset from the top-left so this doesn't happen. What is the magic to do this?
Post not yet marked as solved
This must be a bug in NSTableView, but when I hide the view, the NSScroller shows its scrollbar moving through an empty list and still responds to vertical gestures.
Since this is over a view that already handles panning, this causes a giant deadzone where the table was displayed and vertical panning stops on that section of the view because the table view is intercepting it.
All I do is supply an NSTableViewDelegate. The autohide property is set on the scrollers. This should not be responding to gestures either.
Bad Message 431
reason: Request Header Fields Too Large
That's the result I get trying click on any forum message from Google Chrome. Safari doesn't exhibit this issue, so please fix the html that drives for forums so that more browsers are supported.
Post not yet marked as solved
How do I suppress these strings? These are flooding my logs when I hit pause/resume. These seem to have been left in the debug/release builds. I'm on Xcode 13.1, and building for macOS 10.15. But I'm running on an M1 mac.
2022-02-26 12:56:43.169437-0800 app[96801:1760817] [] [0x1238a0000] CVDisplayLinkStart
2022-02-26 12:56:43.169584-0800 app[96801:1760817] [] [0x1238a0020] CVDisplayLink::start
2022-02-26 12:56:43.169772-0800 app[96801:1761488] [] [0x6000029f6bc0] CVXTime::reset
2022-02-26 12:56:43.926183-0800 app[96801:1760817] [] [0x1238a0000] CVDisplayLinkStop
Post not yet marked as solved
To minimize uptime, I am currently using two command buffers. One holds offscreen commands and is then committed. Then the second waits 20-30ms under heavy gpu use on nextDrawable, does a little work, and calls presentDrawable(which is drawable.present in addScheduledHandler).
This whole setup seems less than ideal. On Android, Vulkan stalls very little on vkImageAquire, and mostly on vkQueuePresent, but that is after the command buffer is ended and submitted. Doing that present call on a thread is often suggested, but the command buffer is already complete and submitted to the gpu before that call.
Metal stalls the commit of the command buffer from this fundamental architecture limitation. I would prefer to have a single command buffer here. The nextDrawable especially with frontBufferOnly set is really just a reference to a drawable, and shouldn't lead to such a long stall. This also makes using double buffering nearly impossible.
Post not yet marked as solved
I have an NSImageView-based preview appex plugin for macOS in Objective-C. It's based off the sample template that you can add to an app.
It completely makes it through preparePreviewOfFileAtURL, and I stuff pixel data into a CGImage, then that into an NSImage and that onto an NSImageView that is self.view from the storyboard. I can see all data via qlManager -p, since it will print error messages for caveman debugging. I have no idea and there are no docs on using the "Quick Look Simulator" which appears to do nothing.
I set background color of the NSImageView.layer to red, and it shows up red. So I know the NSImageView is visible, just not the image that it also points to.
About 30% of the time, only the red shows up, and the other 70% of the time nothing shows up in preview just smokey blurred version of the icons underneath in Finder.
My only recourse, is to disable the extension list for the preview appex, and let the thumbnailer appex provide the preview. There are no samples of this for macOS, and the default templates aren't a working version of this either.
Post not yet marked as solved
I'm getting "Bad Message 431" trying to access the forums from Chrome, so I'm using Safari instead. This is a thread with a ton of people hitting this problem.
https://developer.apple.com/forums/thread/123657
I tracked it down to a bug in the validation layer. This happens with Apple's own sample code. RG16Unorm and other formats shouldn't be flagged as unsupported on a RDNA1 chip in the 16" MBP.
Please also make are R16Unorm isn't flagged either. The Metal texture loader used in the sample seems to always pick the wrong format for loaded images (RG for a height map png?), with no way to control the format.
This is the feedback assistant post on it.
https://feedbackassistant.apple.com/feedback/9540775
Post not yet marked as solved
CMake calls through to xcodebuild clean, but this fails since custom build directories are set. The current workaround is to have to trash the entire CMake build folder. With many subprojects this then takes a long time to rebuild. Can Apple please fix this?
Here I have a project with multiple targets (a fake workspace). CMake can only generate xcprojects and not xcworkspace files. Visual Studio and Android Studio both integrate CMake into the IDE. But building iOS and macOS universal apps is still not simple with CMake. Can Xcode team support CMake better in general?
cmake --build . --target clean
xcodebuild -project foo.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment
Command line invocation:
xcodebuild -project foo.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment
User defaults from command line:
HideShellScriptEnvironment = YES
note: Using new build system
note: Building targets in parallel
error: Could not delete `build/lib` because it was not created by the build system.
error: Could not delete `build/app1` because it was not created by the build system.
error: Could not delete `build/app2` because it was not created by the build system.
warning: Refusing to delete `build` because it contains one of the projects in this workspace: `build/foo.xcodeproj`.
CLEAN FAILED
Post not yet marked as solved
The problem with ClampToEdge is that it stretches the outer strip of pixels even when uv goes outside [0,1]. So the typcial change is to use ClampToZero.
The problem with ClampToZero/Border of 0 is that it pulls in black transparent color into images. What would be better is for this to double up the edge pixels of the texture (ClampToEdge), and only once uv exceeds 0,1 then bilerp the transparent color. Currently ClampToZero pulls in black and drops alpha at the edges of small images leading to poor edges of small textures.
Post not yet marked as solved
When you use the simd classes like float3/matrix3x3 on Swift they are great. I can write and run code like this from existing math routines that are readily found on the web.
let value = m[0][0] * v[0]
When you try to do this in C++/ObjC, the code becomes this. This is not code readily found on the web, and is a big pain to convert.
float value = m.columns[0][0] * v[0];
Can the float3x3 and other wrappers to simd_float3x3 provide an operator[] to the column and other operations like splatting since v[0] above pulls the data out of simd registers.
We currently have to derive off the matrix classes, but it seems like functionality that should be provided in the C/C++ simd classes. A vector math library should promote better code readability than this. We seem to not be able to derive off the vector types which is an issue below.
I also have code based on classes that takes 3 elements that suddenly has to convert to this less readble form.
float3 v(x,y,z) - float3 v(simd_make_float3(x,y,z))
And then there's this code that should fill all values like init repeating in Swift. This is error prone in converting existing simd code to Accelerate simd. So then we try to wrap the float3, can't derive off them, and then lose all swizzling support, operators, etc. Then have to roll our own ops on that struct that holds a float3. What's the recommended way to make this more C++ like without more compiler support
float3 v = {3} - 3,0,0 wasn't expecting that
float3 v(3) doesn't compile
v = {3,0,0} is completely different syntax, and doesn't line up with MSL and most simd libraries
struct myfloat3 : float3 doesn't work
struct myfloat3
{
float3 v; - works, but loses swizzles, operators, etc
explicit myfloat3(float value)
myfloat3(float x, float y, float z)
...
}
Alecazam.