Author Topic: Building Qt5  (Read 34567 times)

Roderick Klein

  • Hero Member
  • *****
  • Posts: 655
  • Karma: +14/-0
    • View Profile
Re: Building Qt5
« Reply #45 on: November 23, 2022, 12:00:07 am »
Dear builders Qt5 please turn off the AVX (and AVX2) code. Due to its presence, the browser does not display the pages. And it is impossible to use libraries. I don’t understand why this code is included if it does not work on OS/2 correctly?

Please open a ticket for this at Github for this issue on the BWW page.

And on which websites does happen so it can be reproduced ?

Thanks,

Roderick Klein
OS/2 VOICE

Andi B.

  • Hero Member
  • *****
  • Posts: 811
  • Karma: +11/-2
    • View Profile
Re: Building Qt5
« Reply #46 on: November 23, 2022, 08:03:49 am »
Dave, if I understand it correct, the problem is our gcc. So it would be necessary to fix gcc not Qt. What you propose is a work around for a bug in our gcc which only exposes on OS/4 kernel. Correct?

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: Building Qt5
« Reply #47 on: November 23, 2022, 09:53:13 am »
It's a mix of problems.

1) The compiler needs to properly align data to be loaded into an XMM (SSE) or YMM (AVX) or ZMM (AVX512)  register (at least for performance reasons but some instructions will also lead to a trap if a memory operand does not align on a 16-byte boundary (for SSE), 32-byte boundary (AVX) or 64-byte boundary (AVX52)).

2) an OS needs to support SSE/AVX/AVX512 context save and restore when switching from one application to another.

Regarding 2) , OS/2, eCS and ArcaOS only support SSE context save (FXSAVE, FXRSTOR: 128 bit registers) but OS/4 also supports AVX/AVX512 context save (XSAVE,XRSTOR: 128 bit and 256 bit and 512 bit registers).

So, the safest thing is to never use AVX/AVX512. That will ensure that you can run your SW on OS/2, eCS, ArcaOS and also on OS/4.

If I am wrong, someone please correct me. Personally, I can say that SSE can safely be used (with memory operands 16-byte aligned where necessary) as I did so in the past and I am running eCS.
« Last Edit: November 23, 2022, 10:08:39 am by Lars »

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: Building Qt5
« Reply #48 on: November 23, 2022, 01:39:01 pm »
... OS/4 also supports AVX/AVX512...

OS/4 currently supports AVX only

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Building Qt5
« Reply #49 on: November 23, 2022, 05:51:55 pm »
Dave, if I understand it correct, the problem is our gcc. So it would be necessary to fix gcc not Qt. What you propose is a work around for a bug in our gcc which only exposes on OS/4 kernel. Correct?

Basically correct. Lars's description is pretty good but to expand on his point one.
Our GCC compiles code into the aout object format. Aout is primitive and doesn't understand the .align directive, so the resulting machine language is randomly aligned (it might support .align 4, I forget) when it comes to SSE+ instructions. The fix is to change the object type, likely to ELF, a fairly big job that might never happen though it has been planned.
There is also an issue open for supporting AVX+ in the OS/2 kernel, might happen and might not as it means patching the kernel to store the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash. Even if the kernel is updated along with GCC, we still have all the older code floating around that will crash. Disabling the use of AVX+ until GCC is fixed will prevent this in the future.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: Building Qt5
« Reply #50 on: November 23, 2022, 06:32:59 pm »
...store the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash.

Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: Building Qt5
« Reply #51 on: November 24, 2022, 03:02:55 am »
Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)

OK, the BOLD highlight is mine...and that's also the focus point: so enlighten us, what exactly does that mean? (is someone else working on getting the GCC thing fixed-up for us? I ask b/c AFAIK Paul is the only one who actively maintains and ports the latest releases...sooo....????)

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Building Qt5
« Reply #52 on: November 24, 2022, 03:38:41 am »
Well, Bitwise has expressed interest in adding Elf support and Paul did some work on it. Turns out that wlink can produce OS/2 executables from ELF objects but has problems with C++ code, or rather symbols, and it is possible that Steven might find time to fix that.

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: Building Qt5
« Reply #53 on: November 24, 2022, 05:33:08 am »
Well, Bitwise has expressed interest in adding Elf support and Paul did some work on it. Turns out that wlink can produce OS/2 executables from ELF objects but has problems with C++ code, or rather symbols, and it is possible that Steven might find time to fix that.

Slight correction to the above.... GCC itself doesn't produce a.out or ELF code - it produces assembly; then gas (GNU Assessember) converts that assembler code into object code. It's trivial to compile gas.exe for OS/2 to use ELF format code; but as Dave says, the linker is the problem. wlink works for some cases, but not all.

Then the work would need to go into emxomfld and probably emxexp/emximp to handle things.....

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: Building Qt5
« Reply #54 on: November 24, 2022, 02:56:36 pm »
...store the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash.

Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)

You are raising an interesting question:

I recently released a new USBWAV.DLL containing 2 IOProcs where it made sense to implement certain things with SIMD instructions (SSE ...).
I hand coded the SIMD code in assembly, using the NASM assembler which also allowed me to force alignment where necessary. But my code only checks if SSE/SSE2/SSE3/SSSE3 is supported by the CPU but it does not check for CR4.OSFXSR flag that indicates that the OS supports SSE context save/restore as I know that OS/2 supports that (for SSE).
Does other SIMD code explicitely check not only for CPU support but also OS support ? And since reading CR4 into a register is only available in Ring 0, so how would application SW (executing in Ring 3) be able to check for that flag ?

Lars
« Last Edit: November 24, 2022, 05:49:55 pm by Lars »

Silvan Scherrer

  • Full Member
  • ***
  • Posts: 200
  • Karma: +1/-0
    • View Profile
Re: Building Qt5
« Reply #55 on: November 24, 2022, 08:12:16 pm »
Dear builders Qt5 please turn off the AVX (and AVX2) code. Due to its presence, the browser does not display the pages. And it is impossible to use libraries. I don’t understand why this code is included if it does not work on OS/2 correctly?

Please open a ticket for this at Github for this issue on the BWW page.

And on which websites does happen so it can be reproduced ?

Thanks,

Roderick Klein
OS/2 VOICE
no need to open a ticket, as we build with -mno-avx since about 15 month. so nothing which is newer should face the issue.
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Building Qt5
« Reply #56 on: November 25, 2022, 04:00:47 am »

I hand coded the SIMD code in assembly, using the NASM assembler which also allowed me to force alignment where necessary. But my code only checks if SSE/SSE2/SSE3/SSSE3 is supported by the CPU but it does not check for CR4.OSFXSR flag that indicates that the OS supports SSE context save/restore as I know that OS/2 supports that (for SSE).
Does other SIMD code explicitely check not only for CPU support but also OS support ? And since reading CR4 into a register is only available in Ring 0, so how would application SW (executing in Ring 3) be able to check for that flag ?

Lars

Used to see some software that checked for OS SSE support, looking I can't find much besides things like this from flac's changelog, (1.2.0)
Code: [Select]
* flac:
    * Added runtime detection of SSE OS support for most operating systems.
Googling, I found this, https://github.com/0xdaryl/omr/commit/83d57d1d09bf13cc71f3f085d56e05cb476bc31f.
Remember that most versions of OS/2 did not support SSE so if someone installs your USBWAVE.DLL on Warp v4 or older, I assume it will crash.

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: Building Qt5
« Reply #57 on: November 25, 2022, 03:07:32 pm »

Used to see some software that checked for OS SSE support, looking I can't find much besides things like this from flac's changelog, (1.2.0)
Code: [Select]
* flac:
    * Added runtime detection of SSE OS support for most operating systems.
Googling, I found this, https://github.com/0xdaryl/omr/commit/83d57d1d09bf13cc71f3f085d56e05cb476bc31f.
Remember that most versions of OS/2 did not support SSE so if someone installs your USBWAVE.DLL on Warp v4 or older, I assume it will crash.

Possible. My hope would be that the most recent W4 kernels (10.104a and the AN kernel versions) will also support save/restore SSE state. After all, we're in 2022. But now that you are mentioning it, I have a partition that I can start with the W4 kernel. Let's see what happens.

Thanks for the link. They are taking a trick to check for OS support (checking for and catching (if necessary) an exception). Very instructive.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Building Qt5
« Reply #58 on: November 25, 2022, 06:18:58 pm »
The recent W4 kernels support SSE, what doesn't is the stock kernel installed with Warp V4 I believe. No idea which fixpak would need to be installed for SSE support.
Win95 never supported SSE either which was why programs needed to test. At this point most everything supports it. At that various OS's and even FF 53+ require a Pentium M or newer due to SSE2 requirements.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: Building Qt5
« Reply #59 on: November 26, 2022, 07:29:41 am »

Does other SIMD code explicitely check not only for CPU support but also OS support ? And since reading CR4 into a register is only available in Ring 0, so how would application SW (executing in Ring 3) be able to check for that flag ?


As I understand it, the R3 application should not check the support of SIMD by processor, but should check the support of  SAVE/RESTORE by OS.
« Last Edit: November 26, 2022, 02:33:29 pm by OS4User »