[Interest] the path forward (or is it "how the things, look"?)

[Roland Hughes]

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.
>
> bye,
> //mirabilos

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.

https://www.researchgate.net/publication/326371108_Vulkan_Abstraction_Layer_for_Large_Data_Remote_Rendering_System

I only read the snippet and maybe they are doing Web only.

Hmmmm

According to NVIDIA, x11 must still work.

https://developer.nvidia.com/embedded/vulkan

=====


      Vulkan Loader

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 
<https://github.com/KhronosGroup/Vulkan-Loader/blob/master/loader/LoaderAndLayerInterface.md>

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 
API version.

*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
    <https://github.com/KhronosGroup/Vulkan-Loader>
 3. cd Vulkan-Loader && mkdir build && cd build
 4. ../scripts/update_deps.py
 5. cmake -DCMAKE_BUILD_TYPE=Release
    -DVULKAN_HEADERS_INSTALL_DIR=$(pwd)/Vulkan-Headers/build/install ..
 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: 
https://www.khronos.org/vulkan/

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
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210412/08e9045c/attachment.html>