Qt6 Development

[Paul Smedley]

As I understand it, stating 'BITS 32' should be equivalent to USE32.

BITS 32 is set at https://github.com/psmedley/qt6-webengine-os2/blob/main/src/3rdparty/chromium/third_party/openh264/src/codec/common/x86/asm_inc.asm#L201 (I think)

[Dave Yeo]

Not sure if it will mean a 32 bit flat, aligned segment, rather then 32 bit code in a 16 bit segment. Guess could ask the nasm people, or experiment.

[Paul Smedley]

OK - I now see how USE32 was used in other areas...

Initial commit in https://github.com/psmedley/qt6-webengine-os2/commit/37131634cd23b9b73408d15b17e8d347b389134d gets it building.. will see what changes...

[Dave Yeo]

Not sure about your align statement, see https://www.nasm.us/xdoc/2.16.01/html/nasmdoc8.html#section-8.4.1, 32 align will end up as 256. I thought 16 is good enough for SSE*, though they are using 32. Maybe once again experimentation is in order. At least a misaligned SSE* instruction should cause an obvious trp.
There's also a section .rodata in mc_chroma.asm
Mostly looks good to me.

[Paul Smedley]

Few more changes in https://github.com/psmedley/qt6-webengine-os2/commit/4c70325abdb7e6c9abd9c96286d0dc08724236d0

https://smedley.id.au/tmp/qt6webee-20230222.zip has the above changes - but still locks up with youtube here Not sure what's changed to make this worse...

[Dave Yeo]

It's weird, just tried Youtube with the latest Qt5 Dooble, it didn't actually play anything for more then a few seconds with the CPU peaked, exited fine, others are reporting it works fine. My I5 is old, but still an I5
Feel stupid as Dmik ported Dav1d for Qt5 and I never noticed, you might want to review his changes, they look basically the same as yours quickly looking, there's other differences even though they're the same version. Perhaps just drop in the Qt5 version, or maybe just libdav1d, and update the BUILD.gn etc if needed.
 

[Dave Yeo]

After testing your latest and having to reboot I found the Qt5 Dooble played YouTube videos not too badly, especially the VP9 ones, AV1 played but a bit laggy.
It then occurred to me to try the Qt6 simplebrowser. Youtube almost loaded and then the tab froze, other tabs continued to work, system was responsive, top reported the qtwebprocess was using about 80% CPU, the Xcentre CPU meter agreed. There were a lot of complaints about sqlite. Simplebrowser also shut down cleanly.

[Paul Smedley]

Hey Dave,

Feel stupid as Dmik ported Dav1d for Qt5 and I never noticed, you might want to review his changes, they look basically the same as yours quickly looking, there's other differences even though they're the same version. Perhaps just drop in the Qt5 version, or maybe just libdav1d, and update the BUILD.gn etc if needed.

Thats interesting.... I'd forgotten this - but indeed I had the initial patches for dav1d in https://github.com/psmedley/qt6-webengine-os2/commit/a70bb96c96df634e5472441d695be5eedfc7bbc8 based on the qt5 work.

Looks like the main differences are the xhanges to xf86inc.asm in https://github.com/psmedley/qt6-webengine-os2/commit/805bf77f6685a414b4688534b440b001a7c6252c#diff-a620cf88d9f41455099357472777f199beaf4683454fd86b6312f7149b1da6c3 &  https://github.com/psmedley/qt6-webengine-os2/commit/167babc8243d00b067de3c35b4cfdb8829f6974a

I'll revert xf86inc.asm to the one from qt5... and see what happens...

[Paul Smedley]

Seems to have helped a bit.... https://www.abc.net.au/news/newschannel/ has been playing for a few minutes now without pausing...

https://smedley.id.au/tmp/qt6webee-20230222.zip has been refreshed - changes not checked in yet...

Youtube also played a few clips without locking up the system... not declaring victory yet, but seeming like progress...

[KO Myung-Hun]

Hi/2.

Hey Dave,

Feel stupid as Dmik ported Dav1d for Qt5 and I never noticed, you might want to review his changes, they look basically the same as yours quickly looking, there's other differences even though they're the same version. Perhaps just drop in the Qt5 version, or maybe just libdav1d, and update the BUILD.gn etc if needed.

Thats interesting.... I'd forgotten this - but indeed I had the initial patches for dav1d in https://github.com/psmedley/qt6-webengine-os2/commit/a70bb96c96df634e5472441d695be5eedfc7bbc8 based on the qt5 work.

Looks like the main differences are the xhanges to xf86inc.asm in https://github.com/psmedley/qt6-webengine-os2/commit/805bf77f6685a414b4688534b440b001a7c6252c#diff-a620cf88d9f41455099357472777f199beaf4683454fd86b6312f7149b1da6c3 &  https://github.com/psmedley/qt6-webengine-os2/commit/167babc8243d00b067de3c35b4cfdb8829f6974a

I'll revert xf86inc.asm to the one from qt5... and see what happens...

I can see the following codes in your commits:

; Needed on OS/2 where it is 16-bit by default.
%macro SECTION_TEXT 0
    %ifidn __OUTPUT_FORMAT__,obj
        SEGMENT TEXT32 CLASS=CODE USE32
    %else
        SECTION .text
    %endif
%endmacro

BTW, why 16-bit not 16-byte? And the default alignment of SEGMENT/SECTION of NASM for obj is 1-byte unlike any other file format which is 16-byte in general. See https://www.nasm.us/xdoc/2.16rc12/html/nasmdoc8.html#section-8.4.1.

So if you want to declare segment with 16-bit alignment, you should add align=2. if 16-byte alignment, add align=16.

KO Myung-Hun

[Rich Walsh]

; Needed on OS/2 where it is 16-bit by default.
%macro SECTION_TEXT 0
    %ifidn __OUTPUT_FORMAT__,obj
        SEGMENT TEXT32 CLASS=CODE USE32
    %else
        SECTION .text
    %endif
%endmacro

BTW, why 16-bit not 16-byte? And the default alignment of SEGMENT/SECTION of NASM for obj is 1-byte unlike any other file format which is 16-byte in general. See https://www.nasm.us/xdoc/2.16rc12/html/nasmdoc8.html#section-8.4.1.
So if you want to declare segment with 16-bit alignment, you should add align=2. if 16-byte alignment, add align=16.

This was added to fix code generation -not alignment- after Paul encountered these errors:

src/x86/downsample_bilinear.asm:754: error: short jump is out of range
src/x86/downsample_bilinear.asm:754: warning: byte data exceeds bounds [-w+number-overflow]

At line 754 is a LOOP instruction whose target was more than 128 bytes away (bigger than a short jump allows). With the assembler assuming 16-bit code, it was adding a 32-bit-operand prefix before all 32-bit code, causing it to swell in size. Adding USE32 eliminated the prefixes and shrunk the loop to <= 128 bytes.

BTW... using this to also set alignment sounds like a good idea - the more stuff you have nailed down in one place, the better.

[Paul Smedley]

Thanks guys - ASM voodoo puts me way out of my comfort zone.

I made the changes to dav1d based on what was used in qt5:
https://github.com/bitwiseworks/qtwebengine-chromium-os2/blob/master/chromium/third_party/dav1d/libdav1d/src/ext/x86/x86inc.asm#L88

The current code (which I've replicated in other instances of x86inc.asm is at:
https://github.com/psmedley/qt6-webengine-os2/blob/main/src/3rdparty/chromium/third_party/dav1d/libdav1d/src/ext/x86/x86inc.asm#L88

@KO - appears you may have looked just before I checked in the latest code as there is now an ALIGN statement

[KO Myung-Hun]

Hi/2.

@Paul What I meant is https://github.com/psmedley/qt6-webengine-os2/blob/main/src/3rdparty/chromium/third_party/dav1d/libdav1d/src/ext/x86/x86inc.asm#L97.

[Paul Smedley]

Sorry - senior moment - wasn't reading properly - happy to do whatever you suggest here....

[Paul Smedley]

FYI - I just raised https://github.com/bitwiseworks/python-os2/issues/9 around an issue with python 3.x and building QtWebEngine 6.3.x (the build system in 6.2.x used python2, they now use python3). Fix is in the Issue..