GetCompatibleFormats() not implemented correctly. #1
Comments
|
@thorfdbg Sorry for the late reply and thanks for looking at this. This part of the code I have no clue about. I took the source over from Tobias with the intention to add the PPC cards as their BARs behave differently to normal PCI cards. Now, he had a HD crash so the sources were (much) older than the binary of library version 3.1 as his got lost, so I tried to reverse engineer it back into the source and called it 4.0. I haven't look at the .card side of things as I haven't seen color issues present itself (yet) So that being said, I love to fix it. But I don't own P96 myself and so I don't have the API (it is part of the download, right?). |
|
Even though this function is present in the Prometheus' card driver code, it is as far as I can see not actually being used. It seems, the card driver relies on the chip driver to implement it and link their own function into the boardinfo structure. At least that's how I did it for the Trio64 driver. The Trio64V+ and later models, however, have two apertures and expose the same memory through both windows at the same time. In this case CalculateMemory() can report either window to access the framebuffer depending on the requested format, while GetCompatibleFormats would claim that all formats can live on the board at the same time. |
|
To provide a bit more technical background to what Mathias said:
The "GetCompatibleFormats()" function provides a bitmask which RGB
formats can co-exist with the given format in the memory of the graphics
card without changing the (CPU-visible) data in the video RAM.
This sounds a bit abstract, so maybe some examples:
Consider a card where the data path from the 68K to the video RAM goes
through a (programmable) endian switch: BGRA is "little endian" and
requires one configuration of the endian switch, ARGB is "big endian"
and requires another configuration. Now, if the code switches from big
to little endian, the data in the video RAM "seems to change" as seen
from the CPU, and thus, the two modes are not compatible.
Consider now the same card, but the endian configuration is not due to a
flag, but rather due to the address at which the video RAM is accessed.
At low addresses, it is little endian, at high addresses it is big
endian. As the image data always stays the same when addressed through
its window, both modes are now compatible to each other.
To avoid unnecessary data migration, P96 furthermore assumes that modes
that are "endian-swaps" of each other (e.g. 16bitPC and 16Bit, or ARGB
and BGRA) are converted to each other when switching between such
incompatible modes. Thus, to render an ARGB bitmap on a BGRA screen, it
is sufficient to switch the RGB mode to ARGB, perform the rendering, and
it will end up in video RAM as BGRA.
As a rule of thumb:
*) Planar is never compatible to anything, and nothing is compatible to
planar. This is due to the way how planar works on VGA, namely accessing
video RAM through the (legacy) graphics controller, which performs
another conversion - or put it around, enabling "chunky" usually enables
the chain-4 mode, which re-interprets data according to the address, and
thus implements another form of aperture.
*) If different endiannesses are addressed through windows in the
address space of the card, the modes that are accessible simultaneously
through two different windows are compatible. If one mode requires to
switch one window to another mode, the original mode and the mode
switched to are not compatible.
*) If different endiannesses are realized through an aperture switch
(and not by an address selection) the two modes are not compatible to
each other.
The Trio64V+ and later models, however, have two apertures and expose
the same memory through both windows at the same time. In this case
CalculateMemory() can report either window to access the framebuffer
depending on the requested format, while GetCompatibleFormats would
claim that all formats can live on the board at the same time.
In that case, see above, the modes that coexist through the windows are
compatible, and the modes that require a switch of the mode of one of
the windows are not compatible.
Example: Consider the first window can be switched between little endian
and long-word endian change. Consider the second window is fixed to
big-endian word switch. Then:
16bit hicolor (in the second window) is compatible with all other modes
except planar as it always has its own window.
chunky, 16bit PC and BGRA are compatible as they are all accessed
through the first window. BGRA is not compatible to chunky, 16bit PC or
RGBA as it requires a reconfiguration of the first window, but it is
compatible to 16bit hicolor as the latter has its own window.
HTHH,
Thomas
|
|
The Voodoo works this way, I think. I noticed it on the Mediator, the memory list gets corrupted during an endian switch (to e.g. a PC mode) as the Mediator adds part of the VGA memory to the system as usable memory, but also places the memory header of this memory in the memory of the VGA card. |
|
Am 10.02.24 um 00:10 schrieb DvdBoon:
The Voodoo works this way, I think. I noticed it on the Mediator, the
memory list gets corrupted during an endian switch (to e.g. a PC mode)
as the Mediator adds part of the VGA memory to the system as usable
memory, but also places the memory header of this memory in the memory
of the VGA card.
Adding VGA memory to the system memory list is a fairly stupid idea -
for the reasons given. Also, a switch to planar will corrupt memory, and
in planar this will likely not work at all as data goes through the GCR.
|
Just browsing the code... the "GetCOmpatibleFormat()" function is not implemented in a correct way and may cause disruptions or color artefacts if the chip driver or card driver supports aperture switches.
First of all, the mask supplied here is (ULONG)~PLANAR, which is just binary %1111...1110, thus the remaining terms that are or'd are just superfluous. What that term means, however, is that if the chip or card supports both big and little endian access, then both can be accessed at the same time without an aperature switch for all modes (16 and 32 bit modes) in the same memory window. This is typically not true, and thus may result in false colors in some modes, in particular if a non-native endianness is used.
Some background information:
The video RAM typically sits behind a "bit-flip" driver that can, upon request, perform a big to little-endian switch. How that switch operates or is controlled depends on the chip and card design, of course, but there are two typical designs:
Design a) is that the switch is dynamically controlled through an I/O port. In that case, big and little endian modes cannot be on the card in the same time as their interpretation changes dynamically with how the switch is operated. In such case, the GetCompatibleFormats() call should only the bitmask of the modes that share the same aperture switch control as the mode passed in.
This design applies, for example, for the Cybervion3D in Zorro-II mode.
Design b) makes all modes (or a subset of the modes) available through multiple windows in the 68K address space, and depending into which window you write, an endian swap happens or not. In such a case, all modes are compatible, but thue card interface then also needs to supply a GetMemory() function that, upon the RGB format passed in, adjusts the memory pointer to point to the correct aperture window into which a write has to go.
This design applies for the CyberPPC and Cybervision3D in Zorro-III mode.
Which of the two designs applies to the graphics cards behind a Prometheus switch I can only guess, that is up to the card author (i.e. "you") to know. (-:
In either case, the interface is incomplete by missing a function or not providing a consistent mask of compatible modes. Please check (carefully!) the P96 API specification at icomp.
As always, I am happy to help through mail if you have further questions.
Greetings,
Thomas
The text was updated successfully, but these errors were encountered: