Qt and Metal
-
As you might know, OpenGL and OpenGL ES are deprecated in Apple platforms, and as far as I know, Qt uses them for rendering. I also use GLSL shaders in my Apps. What will happen to Qt, If Apple discontinues supporting OpenGL and OpenGL ES?
I also heard that Qt is adding support of Metal:
https://forum.qt.io/topic/91357/apple-deprecating-opengl-what-does-this-mean-for-qtWhat will happen to shaders? Do we need to write them from scratch in our apps (only for Apple apps?)
In which stage the development of Qt for Metal is? (I mean, could we rely on it for developing apps?)
-
@Pswin like @jsulm said, a good question for the mailing list https://lists.qt-project.org
But I doubt that the people at Qt would let it happen, that suddenly Qt apps are no longer compatible with MacOS and iOS.
Too many paying customers and loss of reputation on the line for that ;-)
-
But it appears Qt did break things. I am having problems around OpenGL now and it's ONLY if the app is built with Xcode 11/SDK 10.15 and run in Catalina. Qt does not appear to be compatible at all with SDK 10.15/opengl, so what do we do? Can we re-write our video surface in Metal? How?
At the moment we have an app used by thousands and the only way to build future versions is to use a backup with Xcode 10, that won't last long with Apple I'm sure. -
@wesblake said in Qt and Metal:
But it appears Qt did break things.
Apple broke things.
Software Release date Qt 5.13 2019-06 Xcode 11 2019-09 macOS 10.15 2019-10 Qt can't support something that didn't yet exist.
I am having problems around OpenGL now and it's ONLY if the app is built with Xcode 11/SDK 10.15 and run in Catalina. Qt does not appear to be compatible at all with SDK 10.15/opengl
Current releases of Qt have been tested up to Xcode 10 and SDK 10.14: https://doc.qt.io/qt-5/macos.html
Support for Xcode 11 and SDK 10.15 will come in a future release of Qt. For now, stick to the older versions.
the only way to build future versions is to use a backup with Xcode 10
Yes, do that. It is a perfectly sensible short-term solution.
For an app that is used by thousands, it risky to upgrade their dependencies to the latest and greatest as soon as they are released. Keep compatibility with your existing version and test your upgrade paths in a controlled manner.
that won't last long with Apple I'm sure.
Keep an eye out for the Qt release that adds Metal support: https://www.qt.io/blog/qt-quick-on-vulkan-metal-and-direct3d-part-2
-
While I understand what you are saying, it's not really my choice to upgrade dependencies, etc. Apple forces the Xcode/SDK upgrades upon us now. The only reason I can still use Xcode 10 (thankfully) is because I kept a bootable backup of my machine. And I do see this as both Apple and Qt's fault. Any developer is supposed to be aware of and prepared for new OS releases. We ourselves were building and testing from early beta's of Mac OS 10.15 so our app would be ready, why didn't Qt do the same?
-
@wesblake said in Qt and Metal:
it's not really my choice to upgrade dependencies, etc. Apple forces the Xcode/SDK upgrades upon us now. The only reason I can still use Xcode 10 (thankfully) is because I kept a bootable backup of my machine.
Older versions of Xcode and the SDK are available from https://developer.apple.com/download/ . The list goes all the way back to Xcode 1.0 and SDK 10.4.
You can also disable automatic updates on your development machine.
Any developer is supposed to be aware of and prepared for new OS releases. We ourselves were building and testing from early beta's of Mac OS 10.15 so our app would be ready
Good to hear.
That means you would have noticed the breakage during your beta tests, which would have informed you to continue using Xcode 10 + SDK 10.14 for deploying your app to Catalina for now.
why didn't Qt do the same?
Xcode 10 + SDK 10.14 are perfectly capable of deploying apps to Catalina, and Qt does not need the new features provided by Xcode 11 + SDK 10.15 yet. Therefore, macOS developers and end-users have nothing to gain but a lot to lose if Qt starts supporting Xcode 11 + SDK 10.15 so early in the release, before the teething problems have been fixed.
Remember, Qt continuously tests code patches against 56 different platform and toolchain combinations (see https://wiki.qt.io/Qt_5.14_Tools_and_Versions ). If a breakage occurs on even one combination, the patch is blocked from being integrated in Qt completely. Xcode 11 + SDK 10.15 are still immature so they have a high risk of breaking things for everyone and slowing down Qt development.
Once the latest tools are more mature, Qt will probably add Xcode 11 + SDK 10.15 while dropping Xcode 9 + SDK 10.12. This involves switching off support for Qt's legacy users and this is not a decision that the Qt Project makes lightly.
-
Apple does force now, what you can download means nothing. And each Xcode version now forces a particular SDK.
"The Apple App Store has announced that all new apps and app updates submitted to the App Store will need to be built with Xcode 10 or above starting from March 2019."
So fine, I can use 10, but Apple developers are typically in the habit of staying up to date though because that's what Apple expects. I don't like it either, I blame Apple too for this, fine. But I hope Qt stays up to date:
"Starting April, 2020, all apps submitted to the App Store will need to be built with Xcode 11. Xcode 11 requires macOS Mojave 10.14.3 or later."
Not sure why the pushback from you all. The concept of sticking to an older Xcode does not fit Apple's current paradigm. Fact is, it needs to be addressed before it's too late and it's my understanding this round requires a lot of work in Qt. I'm sure the Qt team is on it but, as unfortunate as it is (I develop for multiple platforms too and like Apple the least because of this), Apple does push.
How about we get back on topic for the thread. The metal support I've read about the last few days that is coming in 5.14 is for Qt Quick. What about all the apps based on Qt Widgets? What will happen to all the apps that are not Quick?
-
@wesblake said in Qt and Metal:
How about we get back on topic for the thread. The metal support I've read about the last few days that is coming in 5.14 is for Qt Quick. What about all the apps based on Qt Widgets? What will happen to all the apps that are not Quick?
they should be fine, I think.
unless you're using something like QOpenGLWidgets, then Widgets should not use OpenGl at all.
-
@wesblake said in Qt and Metal:
Apple does force now, what you can download means nothing. And each Xcode version now forces a particular SDK.
I was responding to your comment that "The only reason I can still use Xcode 10 (thankfully) is because I kept a bootable backup of my machine". You implied that developers who did not have a backup will be stuck; I clarified that anybody who starts writing Qt apps today has access to everything they need to deploy to Catalina without issues, and I provided links to point developers in the right direction.
So fine, I can use 10, but Apple developers are typically in the habit of staying up to date though because that's what Apple expects. I don't like it either, I blame Apple too for this, fine.
...
The concept of sticking to an older Xcode does not fit Apple's current paradigm.Acknowledged.
I am aware of Apple's current paradigm. I'm saying that nothing in the Qt Project's current paradigm endangers Apple developers or end-users.
Not sure why the pushback from you all.
I'm not speaking for others; these comments are mine alone. Personally, I found your statements unreasonable (e.g. "Qt did break things", "I do see this as both Apple and Qt's fault.") and sensationalistic (e.g."The only reason I can still use Xcode 10 (thankfully) is because I kept a bootable backup of my machine"). These are what I pushed back on.
Also, you asked why didn't Qt prepare for Xcode 11 and Catalina as soon as they were announced; I simply gave you an explanation why. If any part of that explanation doesn't make sense, please say so.
Fact is, it needs to be addressed before it's too late and it's my understanding this round requires a lot of work in Qt. I'm sure the Qt team is on it but, as unfortunate as it is (I develop for multiple platforms too and like Apple the least because of this), Apple does push.
I'm sure the Qt engineers are on it too, and I trust that they will address it before it's too late.
If you want to help speed things up, open a ticket at https://bugreports.qt.io/, post your investigations and findings, and post a link here for others who want to follow the developments. That will be helpful. Pushing is not helpful.
How about we get back on topic for the thread. The metal support I've read about the last few days that is coming in 5.14 is for Qt Quick. What about all the apps based on Qt Widgets? What will happen to all the apps that are not Quick?
Sure.
The parts of Qt that use OpenGL are Qt Quick, Qt 3D, and Qt 3D Studio. All of these technologies will benefit from the Qt Rendering Hardware Interface (RHI).
Qt Widgets use CPU rendering (unless you've explicitly written OpenGL code) so they are unaffected by the removal of OpenGL on macOS.
However, if you have explicitly written OpenGL function calls inside your widget (e.g.
QOpenGLWidget), then I don't know if the RHI helps you or not because those calls go straight to your OpenGL drivers, bypassing the RHI layer. You might need to insert something like MoltenGL into your app or replace your OpenGL code instead. I suggest you try to reach one of the Qt engineers who are working on this (or their colleauges) by subscribing to the Interest mailing list and asking there -- they might provide insiders' info on how to proceed.P.S. In case you're using
QGLWidget, be aware that it was deprecated 5 years ago and replaced withQOpenGLWidget. If the root cause of your issues lie solely on the Apple side, then the next release of Xcode + macOS SDK might makeQGLWidgetwork again. However, if Qt needs to make any patches, then the necessary patches might not make it intoQGLWidget. -
@JKSH Thanks. I appreciate the feedback, I've received a lot of pushback with this myself and it's been stressful! So yes, we are using QGLWidget right now, and currently on for Apple, I will see if changing that works.
OUr app is video relay software. Another team in house created an SDK to do the sip and encode/decode stuff. I am responsible for the UI including rendering the video. So I register with the SDK and receive images for local and remote video frames. When I get them, I simply render them. Originally we had this QGLWidget for Windows and Mac, because I was able to thread the job using a "shared widget". Due to another bug in Qt+Intel Graphics (known/un-resolved ticket on Qt side) where styles are lost while using opengl on certain Intel graphics, I detect Windows now and have a separate D2D based class for video. However, that one I could never figure out how to thread so it doesn't perform nearly as well.
But maybe there is a better solution? Would you all wait for 5.14 and re-write a single surface to use the new system (assuming I can) or is there a better way for us to render images at up to 60fps threaded within the UI? Writing this I wonder if we over-complicated it from the beginning, perhaps I didn't need OpenGL or D2D at all for this. -
@wesblake You're welcome. I do understand the frustration of having a good feature pulled from under your feet, or from longstanding bugs that don't get any attention.
What image/video format(s) does your SDK transmit? The format influences the optimal solution, I believe. If you give us more details about what formats are available, perhaps we can find something that works well for you.
Would you all wait for 5.14 and re-write a single surface to use the new system (assuming I can)
You can try a beta version of Qt 5.14 now if you like (either from the Online installer or from http://download.qt.io/development_releases/qt/5.14/ )
-
Sure. My "buffer" class subclass's an SDK class so that I implement the SDK's lock and unlock functions. Lock means it has a "frame" and unlock means it's supplied it to us or expects it has (because we supplied a buffer in lock for the frame and it's filled the buffer) and we can draw it. It supplies raw image data to said buffer. So, in my current working implementation of the lock function, the relevant part is:
int bufferSize = pixWidth*pixHeight*4; uchar *pBuffer = (uchar*)ALLOC_ALIGN16(bufferSize); memset(pBuffer, 0x0, bufferSize); m_Data[currentTail] = new QImage(pBuffer, pixWidth, pixHeight, (pixWidth*4), QImage::Format_ARGB32_Premultiplied, &myImageCleanupHandler, pBuffer);Then, currently, if Mac OS I draw that image to a QGLWidget (threaded via use of a share widget) which works great but won't anymore, if Windows I draw it to a QWidget with D2D which works ok, there's a delay between the camera and video view because it's not threaded.
I can provide more but I think that answers your question?
My first thought right now would be to try moving my threaded QGLWidget to QOpenGLWidget and see if that solves all but it will take time just to possibly find out it no longer works in Mac either! I did download a threaded QOpenGLWidget example and it compiled and ran on Catalina+Xcode 11 so that's hopeful. -
just coded a qt metal wrapper, full working example included:
https://github.com/rforcen/qt-metal -
I didn't think any workaround was needed since Qt 5.14:
From Qt 5.14 onwards, the default adaptation gains the option of rendering via a graphics abstraction layer, the Qt Rendering Hardware Interface (RHI), provided by the QtGui module. When enabled, no direct OpenGL calls are made. Rather, the scene graph renders by using the APIs provided by the abstraction layer, which is then translated into OpenGL, Vulkan, Metal, or Direct 3D calls. Shader handling is also unified by writing shader code once, compiling to SPIR-V, and then translating to the language appropriate for the various graphics APIs.
However, I never owned a Mac so this is not first hand experience
