[Interest] the path forward (or is it "how the things, look"?)
roland at logikalsolutions.com
Mon Apr 12 18:31:24 CEST 2021
On 4/12/21 10:47 AM, Thorsten Glaser wrote:
> On Mon, 12 Apr 2021, Roland Hughes wrote:
>> Again, ripping XCB out won't be a free effort even if the new library is
>> free as in beer, but the current situation with XCB is kind of at the
>> heart of everything when one steps back for a few days.
> And this very well MUST be. I’m using Qt applications (both with and
> without KDE) over remote connections (all three of X11, X11VNC and
> xrdp), so requiring local GPU rendering isn’t going to fly at all.
> So, the X11 protocol, either with libX11 or XCB, must keep working.
I didn't mean to imply requiring remote GPU rendering. I was talking
about applications having access to the GPU for compute intensive things.
Vulkan was just the latest one I heard about. Someone else has done work
on remote Vulkan.
I only read the snippet and maybe they are doing Web only.
According to NVIDIA, x11 must still work.
Vulkan applications interact with Vulkan drivers through the loader. The
loader is responsible for supporting multiple GPUs and their drivers.
For supporting the latest Vulkan API version, the loader also needs to
be the matching version.
More information about the loader is available here: Vulkan Loader
Canonical provides a specific version of the loader with each LTS
release and it is not upgraded frequently. This limits the Vulkan
driver’s ability to support the latest API version. To address this,
NVIDIA now provides a compatible loader version along with the BSP
release. This ensures applications can use the latest supported Vulkan
*The latest BSP release includes Vulkan loader version 1.2.132.*
The Vulkan Loader can also be built on the device using the following steps:
1. sudo apt-get update && sudo apt-get install git build-essential
libx11-xcb-dev libxkbcommon-dev libwayland-dev libxrandr-dev cmake
2. git clone https://github.com/KhronosGroup/Vulkan-Loader.git
3. cd Vulkan-Loader && mkdir build && cd build
5. cmake -DCMAKE_BUILD_TYPE=Release
6. make -j8
What I was saying was that it is time for "the project" to cut bait with
what we have for graphics rendering. There are cross platform, industry
standard, OpenSource GUI only libraries that work well on the remaining
Qt targets, Windows, Linux, Android. This one, and I'm certain others,
claim to have 3D and 4K/8K out of the box.
Cutting bait on the low-level GUI code and focusing on the high level
things that make Qt good and useful would make "project sense." Android
could stop feeling totally neglected. If 3D doesn't work it wouldn't be
"the project's" fault.
Probably most importantly, this entire conversation would get rather
moot. True, our good friend Scott and his company might still be
screwed, but there would now be a real abstraction layer between Qt and
the video hardware. I haven't delved into the actual API, but judging
from that NVIDIA site snippet, the loader should have a non-depreciable
API call for obtaining the supported API version. That would mean code
could gracefully straddle many years of API.
I mean the list of companies providing Vulkan drivers on this site:
Intel, AMD, NVIDIA, Qualcomm, BROADCOM, etc. means this is a significant
standard and needs to be looked into. There may well be other low level
GUI only OpenSource standards supported by these same companies. Thiago
would be able to find the public information from Intel easier than the
rest of us. (Not asking for insider information. If Intel released an
XXXXXXX-API driver for some cards, I imagine it got published somewhere.
Can our good friend Scott build a version of Vulkan loader on RHEL 6
with the xcb he has on there? I don't know.
How is Vulkan using X11-xcb? I don't know. Maybe it is only for the
remote communication stuff that you need? Maybe our good friend Scott is
still screwed after this move? I hope not, but still possible.
Quite a few Engines currently support Vulkan according to that link.
Among them Unity, UNREAL, and UX3D. I'm not a game developer, but I've
heard of those.
In general, there obviously isn't enough resources in "the project" to
continue doing the low level GUI stuff __AND__ everything else. It's
causing breakage in the customer base. At least one, possibly more)
layers of abstraction need to be inserted between the Qt API and the
graphics hardware. Maybe "the project" has to adopt an engine as well?
Maybe "the project" creates its own engine on top of Vulkan now that
some resources are freed from maintaining the low level stuff?
It would be nice if Qt could have out-of-the-box 8K support while still
supporting 640x480 VGA.
It would be nice if the 3D stuff could be its own code base with its own
engine that you need not pull in by default.
It would be possible, especially given the current reputation of Qt3D
(however accurate) to just kill that off and make the 3dEngine+API
commercial only. There might be some OpenSource developers honked by
that, I don't know.
Just saying it is time for the larger conversation and time to cut bait
on what we have for the low level stuff.
Roland Hughes, President
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest