Falcosoft wrote on 2026-05-28, 21:40:

Thanks, I found them. […]
Show full quote

Marco Pistella wrote on 2026-05-28, 19:24:

Falcosoft wrote on 2026-05-28, 19:16:

Github is still indexing the code base so searching does not function properly.
Can you tell what files contain the SSE and AVX benchmark routines?

VESA_Speed_Routines.ASM + VESA_COMMAND_02.ASM

Thanks, I found them.

There is 1 thing that I could not find in X-VESA (even in the detailed video mode information page): It's the bits in the ModeAttributes field inside the ModeInfoBlock struct.
Some of these bits, such as 'VGA compatible mode' could be useful for troubleshooting since it seems e.g. Build engine games use it to determine code paths.
Thanks in advance!

All ModeAttributes bits are decoded in VESA_Command_01. The decoding is version-dependent: bits 5-6-7 (VGA compatible + windowed + linear frame buffer) are shown only for VESA 2.0, additional fields for VESA 3.0. The Block_Yes_Or_No routine handles the actual bit testing, iterating through the mask defined by DH/DL.

Marco Pistella wrote on 2026-05-29, 06:44:

Falcosoft wrote on 2026-05-28, 21:40:

Thanks, I found them. […]
Show full quote

Marco Pistella wrote on 2026-05-28, 19:24:

VESA_Speed_Routines.ASM + VESA_COMMAND_02.ASM

Thanks, I found them.

There is 1 thing that I could not find in X-VESA (even in the detailed video mode information page): It's the bits in the ModeAttributes field inside the ModeInfoBlock struct.
Some of these bits, such as 'VGA compatible mode' could be useful for troubleshooting since it seems e.g. Build engine games use it to determine code paths.
Thanks in advance!

All ModeAttributes bits are decoded in VESA_Command_01. The decoding is version-dependent: bits 5-6-7 (VGA compatible + windowed + linear frame buffer) are shown only for VESA 2.0, additional fields for VESA 3.0. The Block_Yes_Or_No routine handles the actual bit testing, iterating through the mask defined by DH/DL.

Ahh, OK. Thanks!

Regarding the AVX benchmarks: Don't you think that after the AVX block of instructions VZEROALL or VZEROUPPER should be called to prevent false dependency on the upper 128-bits in ymm registers when SSE instructions are used later?
I refer to this problem (implicit widening):
https://stackoverflow.com/questions/66874161/ … 895855#66895855

@Edit:
Since it seems always only 1 SIMD register is used by all routines (xmm0, ymm0, zmm0 respectively) VXORPS on the 1st register should be enough.
Or you always only move (zeroed) data so the issue is not relevant in your case?

Falcosoft wrote on 2026-05-29, 07:18:

Ahh, OK. Thanks! […]
Show full quote

Marco Pistella wrote on 2026-05-29, 06:44:

Falcosoft wrote on 2026-05-28, 21:40:

Thanks, I found them. […]
Show full quote

Thanks, I found them.

There is 1 thing that I could not find in X-VESA (even in the detailed video mode information page): It's the bits in the ModeAttributes field inside the ModeInfoBlock struct.
Some of these bits, such as 'VGA compatible mode' could be useful for troubleshooting since it seems e.g. Build engine games use it to determine code paths.
Thanks in advance!

All ModeAttributes bits are decoded in VESA_Command_01. The decoding is version-dependent: bits 5-6-7 (VGA compatible + windowed + linear frame buffer) are shown only for VESA 2.0, additional fields for VESA 3.0. The Block_Yes_Or_No routine handles the actual bit testing, iterating through the mask defined by DH/DL.

Ahh, OK. Thanks!

Regarding the AVX benchmarks: Don't you think that after the AVX block of instructions VZEROALL or VZEROUPPER should be called to prevent false dependency on the upper 128-bits in ymm registers when SSE instructions are used later?
I refer to this problem (implicit widening):
https://stackoverflow.com/questions/66874161/ … 895855#66895855

@Edit:
Since it seems always only 1 SIMD register is used by all routines (xmm0, ymm0, zmm0 respectively) VXORPS on the 1st register should be enough.
Or you always only move (zeroed) data so the issue is not relevant in your case?

As you guessed in your edit, since the SSE/AVX routines only transfer data and never read the previous register state, and these instructions are not used elsewhere in the program, VZEROALL/VZEROUPPER are not needed. The upper bits state is irrelevant in this context.

Marco Pistella wrote on 2026-05-29, 08:16:

Falcosoft wrote on 2026-05-29, 07:18:

Ahh, OK. Thanks! […]
Show full quote

Marco Pistella wrote on 2026-05-29, 06:44:

All ModeAttributes bits are decoded in VESA_Command_01. The decoding is version-dependent: bits 5-6-7 (VGA compatible + windowed + linear frame buffer) are shown only for VESA 2.0, additional fields for VESA 3.0. The Block_Yes_Or_No routine handles the actual bit testing, iterating through the mask defined by DH/DL.

Ahh, OK. Thanks!

Regarding the AVX benchmarks: Don't you think that after the AVX block of instructions VZEROALL or VZEROUPPER should be called to prevent false dependency on the upper 128-bits in ymm registers when SSE instructions are used later?
I refer to this problem (implicit widening):
https://stackoverflow.com/questions/66874161/ … 895855#66895855

@Edit:
Since it seems always only 1 SIMD register is used by all routines (xmm0, ymm0, zmm0 respectively) VXORPS on the 1st register should be enough.
Or you always only move (zeroed) data so the issue is not relevant in your case?

As you guessed in your edit, since the SSE/AVX routines only transfer data and never read the previous register state, and these instructions are not used elsewhere in the program, VZEROALL/VZEROUPPER are not needed. The upper bits state is irrelevant in this context.

OK, I see.

Falcosoft wrote on 2026-05-29, 08:47:

Marco Pistella wrote on 2026-05-29, 08:16:

Falcosoft wrote on 2026-05-29, 07:18:

Ahh, OK. Thanks! […]
Show full quote

Ahh, OK. Thanks!

Regarding the AVX benchmarks: Don't you think that after the AVX block of instructions VZEROALL or VZEROUPPER should be called to prevent false dependency on the upper 128-bits in ymm registers when SSE instructions are used later?
I refer to this problem (implicit widening):
https://stackoverflow.com/questions/66874161/ … 895855#66895855

@Edit:
Since it seems always only 1 SIMD register is used by all routines (xmm0, ymm0, zmm0 respectively) VXORPS on the 1st register should be enough.
Or you always only move (zeroed) data so the issue is not relevant in your case?

As you guessed in your edit, since the SSE/AVX routines only transfer data and never read the previous register state, and these instructions are not used elsewhere in the program, VZEROALL/VZEROUPPER are not needed. The upper bits state is irrelevant in this context.

OK, I see.

If you're interested in the SSE/AVX handling, I'd also suggest looking at LIBS\Retrieve_CPU_Capabilities.ASM — it contains the full detection and enabling sequence (SSE/AVX/AVX512F)

EduBat wrote on 2026-05-26, 19:07:

Marco Pistella wrote on 2026-05-23, 10:05:

RC2
- Added Video BIOS dump to disk (S key in F10 screen)

It is may be interesting to note that the Video BIOS extracted by X-Vesa is the runtime one, after initialisation. In this case, some of the initialisation code is not present, but it may be interesting to get it to better understand the card. The specs go into a lot more detail about how it all works.

In my GTX650, the file extracted by X-Vesa has 58368 bytes, while the one I extracted "before initialisation" has 64512.

Just for completeness, let me add a bit more information regarding how I extracted the "before" BIOS I attached...
The answer is here:
https://envytools.readthedocs.io/en/latest/hw/io/prom.html

i.e. there is a copy of the Video BIOS in the MMIO configuration space.
To access it, you need to find out the address of this address space from the PCI configuration space and add the value of the PROM register depending on graphics card.

As an example, in my computer I have...
root [ ~ ]# lspci -vs1:0.0
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Device 3553
Flags: bus master, fast devsel, latency 0, IRQ 25
Memory at fd000000 (32-bit, non-prefetchable) [siz=16M]
Memory at d0000000 (64-bit, prefetchable) [siz=256M]
Memory at ce000000 (64-bit, prefetchable) [siz=32M]
I/O ports at dc00 [siz=128]
Expansion ROM at 000c0000 [siz=128K]

...so the MMIO address is fd000000h. I then add the location of the PROM address which is 300000h giving out fd300000h.
I then convert this value to decimal and divide it by 4.
Now I can do use dd with the /dev/mem device.
root [ ~ ]# dd if=/dev/mem skip=1061945344 bs=4 count=16384 of=VVBIOS.BIN
16384+0 records in
16384+0 records out
65536 bytes (66 kB, 64 KiB) copied, 0.133868 s, 490 kB/s

Through trial and error I realised I really had to use block size 4 (32bits) on the command above, or else I would get some wrong bytes in the output.
(in order for dd to work like this, the kernel needs to be compiled with CONFIG_STRICT_DEVMEM not set)

(Hope this helps someone someday..)