There are no penalties, but the bandwith doing 8-bit MOVs instead of 16-bit is just half. You can check this behaviour with some benchmark (X-VESA, or my new benchmark https://github.com/viti95/V95bench)

Ok. Yes, I know it's half of the potential bandwidth, but sometimes I want to write a byte for alignment reasons (and when writing a font glyph to a bitplane, for example).
EDIT: The reason I can't benchmark this is because I don't have a 16-bit ISA video card, I only have 32-bit VLB. Just in case it's different on VLB makes me not want to trust the benchmarks when I target 16-bit ISA.

I wrote a similar throughput testing tool (with source-code): https://www.dropbox.com/s/71w2sqmmzztubf9/VRAMSPD.ZIP?dl=1
It's less flexible. It requires 386+, and if the time spent on writing a frame was more than 55ms, it will not report anything (PIT count overflow).

Well, you can use ctcm from heise.
With its /VID and /MOVSB or /MOVSW options you can perform 8 and 16 bit operations too on your video card. You also may specify the video mode.
You can download it from its German homepage. Its output support English language. https://www.heise.de/download/product/ctcm-1825

ViTi95 wrote on 2022-03-14, 08:05:

There are no penalties, but the bandwith doing 8-bit MOVs instead of 16-bit is just half.

It's not that easy. A 16 bit graphics card need not accept a 16-bit cycle under all circumstances. If the card feels like doing 8-bit access only in a certain video mode, it is free to do so. A lot of non-FIFO-based cards (think early Tridents) handle 16-bit cycles only in text mode, CGA-compatible graphics modes and 256-color modes, but not in EGA-like 16-color modes or Mode X. In the former set of modes, a single 16-bit bus cycle accesses two different bytes in the same 32-bit VGA memory word, but in the latter set of modes (when the addressing scheme is neither odd/even or chain-4), a 16-bit host bus access touches two VGA words, so the access needs to be performed in two parts on the VGA memory anyway. Early cheap cards do not split the access themselves, but have the main board chipset do it.

mkarcher wrote on 2022-03-14, 17:59:

ViTi95 wrote on 2022-03-14, 08:05:

There are no penalties, but the bandwith doing 8-bit MOVs instead of 16-bit is just half.

It's not that easy. A 16 bit graphics card need not accept a 16-bit cycle under all circumstances. If the card feels like doing 8-bit access only in a certain video mode, it is free to do so. A lot of non-FIFO-based cards (think early Tridents) handle 16-bit cycles only in text mode, CGA-compatible graphics modes and 256-color modes, but not in EGA-like 16-color modes or Mode X. In the former set of modes, a single 16-bit bus cycle accesses two different bytes in the same 32-bit VGA memory word, but in the latter set of modes (when the addressing scheme is neither odd/even or chain-4), a 16-bit host bus access touches two VGA words, so the access needs to be performed in two parts on the VGA memory anyway. Early cheap cards do not split the access themselves, but have the main board chipset do it.

That's why I say there are no penalties, base performance is the 8-bit one. Optimizations on the cards allow to transfer 16-bit or 32-bit data, even 8-bit transfers are optimized on some cards depending on the mode. That's why I created V95Bench, to test what cards have weird behaviour depending on the selected video mode.

For example on my testings detected that the ATI Small Wonder v2 (8-bit ISA) is faster depending on the selected video mode: