Graphics support

Graphics support

[Michael]

Hello,

is anyone still interested in graphics support on HP hardware? If so, I
made some progress on Visualize EG, HCRX and Visualize FX.

Full disclosure - I'm a NetBSD developer, I used some docs found on
parisc.docs.kernel.org, this is my attempt at giving back / comparing notes.

Recently I wrote native drivers for Visualize EG, HCRX and Visualize FX
4, they all support framebuffer access, basic acceleration, cursor
sprite, and on the HCRX, 24bit colour. I also wrote an Xorg driver that
supports whatever acceleration I could figure out, which is copy, fill
and hardware cursor, on all of the above, except ROPs on Visualize FX.

EG, HCRX etc. register functions are here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/stireg.h
PCI Visualize EG / Graffiti driver:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/gftfb.c
HCRX / hyperdrive:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/hyperfb.c

Visualize FX stuff, mostly found by disassembling the STI ROM on my FX4,
comparing notes with docs and hints found on parisc.docs.kernel.org,
and a lot of experimentation:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/summitreg.h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/summitfb.c

The Xorg driver lives here:
http://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/xf86-video-ngle/dist/src/

What I haven't been able to figure out so far:
- how to do ROPs on Visualize FX. I can do colour expansion, STI colour
  change and plain fills and copies
- access off-screen memory on HCRX. All we can mess with is 1280x1024
  in both 24bit and the 8bit overlay. I'm sure the thing has more
  memory than that, but blitter ops wrap at those boundaries and FB
  reads return garbage.
- off-screen memory on Visualize FX. STI reports 2048x2048 but what's
  actually accessible is screen width rounded up to the next multiple
  of 512 by screen height. There is a clipping register which STI sets
  to match the video mode but setting it to 2048x2048 does not allow
  access to anything else, blitter ops wrap like on HCRX. I *know* this
  thing has more memory than that. On the PCI EG we get full 2048x2048
  no matter what mode we're in.
- 24bit colour on the FX. I can switch the FB wndow to 32bit mode but
  that doesn't result in 24bit pixels being displayed.

hope this helps
Michael

Re: Graphics support (HP VisEG/VisFX/HCRX...)

[Helge Deller]

Hello Michael !

On 12/16/24 12:41, Michael wrote:
> is anyone still interested in graphics support on HP hardware?

Of course !!!

> If so, I made some progress on Visualize EG, HCRX and Visualize FX.

Great!

> Full disclosure - I'm a NetBSD developer, I used some docs found on
> parisc.docs.kernel.org, this is my attempt at giving back / comparing notes.
>
> Recently I wrote native drivers for Visualize EG, HCRX and Visualize FX
> 4, they all support framebuffer access, basic acceleration, cursor
> sprite, and on the HCRX, 24bit colour.

I assume you mean native drivers for NetBSD ?
On Linux VisEG and HCRX are supported in graphics mode, and VisFX in
text mode only.
We do have drivers for VisFX in graphics mode too, one for fbdev
and the other for drm. Both are not upstreamed yet and have various
reasons why I haven't upstreamed them yet.
See branches at
https://github.com/hdeller/linux/tree/hp-visualize-fx-fbdev-2

> I also wrote an Xorg driver that
> supports whatever acceleration I could figure out, which is copy, fill
> and hardware cursor, on all of the above, except ROPs on Visualize FX.

Maybe the VisFX driver sources from Sven Schnelle can give you some
idea. See github repo above.

> EG, HCRX etc. register functions are here:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/stireg.h
> PCI Visualize EG / Graffiti driver:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/gftfb.c

> HCRX / hyperdrive:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/hyperfb.c
>
> Visualize FX stuff, mostly found by disassembling the STI ROM on my FX4,
> comparing notes with docs and hints found on parisc.docs.kernel.org,
> and a lot of experimentation:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/summitreg.h
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/summitfb.c
>
> The Xorg driver lives here:
> http://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/xf86-video-ngle/dist/src/

Any chance this can get upstreamed?
I'm happy to test it on Linux.

> What I haven't been able to figure out so far:
> - how to do ROPs on Visualize FX. I can do colour expansion, STI colour
>    change and plain fills and copies

Here are the Linux VisFX drivers:
fbdev: https://github.com/hdeller/linux/commit/87e03df1af93e8236b3c1b44e60c0fa2d6c995d5
drm:   https://github.com/hdeller/linux/commit/3a5fc28d9e3d39e7e116b8acf0b028a3024d9c36

> - access off-screen memory on HCRX. All we can mess with is 1280x1024
>    in both 24bit and the 8bit overlay. I'm sure the thing has more
>    memory than that, but blitter ops wrap at those boundaries and FB
>    reads return garbage.
> - off-screen memory on Visualize FX. STI reports 2048x2048 but what's
>    actually accessible is screen width rounded up to the next multiple
>    of 512 by screen height. There is a clipping register which STI sets
>    to match the video mode but setting it to 2048x2048 does not allow
>    access to anything else, blitter ops wrap like on HCRX. I *know* this
>    thing has more memory than that. On the PCI EG we get full 2048x2048
>    no matter what mode we're in.
> - 24bit colour on the FX. I can switch the FB wndow to 32bit mode but
>    that doesn't result in 24bit pixels being displayed.

I have not hacked on it since quite some time ... :-(

Helge

Re: Graphics support (HP VisEG/VisFX/HCRX...)

[Michael]

Hello,

On Tue, 17 Dec 2024 21:28:08 +0100
Helge Deller <deller@gmx.de> wrote:

> > Full disclosure - I'm a NetBSD developer, I used some docs found on
> > parisc.docs.kernel.org, this is my attempt at giving back / comparing notes.
> >
> > Recently I wrote native drivers for Visualize EG, HCRX and Visualize FX
> > 4, they all support framebuffer access, basic acceleration, cursor
> > sprite, and on the HCRX, 24bit colour.  
> 
> I assume you mean native drivers for NetBSD ?

Yes. The hardware is quite weird so just posting the sources seemed the
easiest way to document it. I'm well aware that our respective console
subsystems are too different to port anything directly.

> On Linux VisEG and HCRX are supported in graphics mode, and VisFX in
> text mode only.
> We do have drivers for VisFX in graphics mode too, one for fbdev
> and the other for drm. Both are not upstreamed yet and have various
> reasons why I haven't upstreamed them yet.
> See branches at
> https://github.com/hdeller/linux/tree/hp-visualize-fx-fbdev-2

We were the same way - there's a generic console driver that just uses
STI calls for everything, with a little extra to put known hardware
into fb mode, then run X on a dumb framebuffer.
 
> > I also wrote an Xorg driver that
> > supports whatever acceleration I could figure out, which is copy,
> > fill and hardware cursor, on all of the above, except ROPs on
> > Visualize FX.  
> 
> Maybe the VisFX driver sources from Sven Schnelle can give you some
> idea. See github repo above.

I looked at a proposed console driver, compared notes and made a bunch
of additions, tried to keep my own code more or less compatible. Looks
like an older version of the above.
Also found some differences between my FX4 and his FX5 along the way.

> > EG, HCRX etc. register functions are here:
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/stireg.h
> > PCI Visualize EG / Graffiti driver:
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/gftfb.c  
> 
> > HCRX / hyperdrive:
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/hyperfb.c
> >
> > Visualize FX stuff, mostly found by disassembling the STI ROM on my
> > FX4, comparing notes with docs and hints found on
> > parisc.docs.kernel.org, and a lot of experimentation:
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/summitreg.h
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hppa/dev/summitfb.c
> >
> > The Xorg driver lives here:
> > http://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/xf86-video-ngle/dist/src/
> >  
> 
> Any chance this can get upstreamed?
> I'm happy to test it on Linux.

For now the driver is quite NetBSD-specific in the way it maps graphics
devices. In order to support both PCI and GSC cards through the same
driver with minimal hassle it just goes through NetBSD's console
devices, maps fb and registers at fixed offsets and things like cursor
sprite and colour maps are handled using ioctl()s because of the weird
way the NGLE hardware wants them ( you basically write stuff into a
buffer, then use the blitter(!) to move data to the actual registers,
so we have to make sure nothing tries to use the blitter or access the
fb while we do colour map updates... )

> > What I haven't been able to figure out so far:
> > - how to do ROPs on Visualize FX. I can do colour expansion, STI
> > colour change and plain fills and copies  
> 
> Here are the Linux VisFX drivers:
> fbdev:
> https://github.com/hdeller/linux/commit/87e03df1af93e8236b3c1b44e60c0fa2d6c995d5
> drm:
> https://github.com/hdeller/linux/commit/3a5fc28d9e3d39e7e116b8acf0b028a3024d9c36

Nice, I wasn't aware of those!
So, still no fb access. Well, I can help with that:
#define VISFX_VRAM_READ_MODE	0xa0080c	// this is a guess
or, in HP speak, B2_SBA controls what you read in the fb aperture, in
much the same way as B2_DBA controls what you write. Just like on HCRX,
what we see and what the blitter sees is controlled by the same
registers.
B2_EN2D controls the fb aperture depth, 0xb0 gives you 8bit, 0xd0
32bit, at least on my FX4.

Also, that's a *lot* of register definitions. Did someone get a hold of
official headers?

> > - access off-screen memory on HCRX. All we can mess with is
> > 1280x1024 in both 24bit and the 8bit overlay. I'm sure the thing
> > has more memory than that, but blitter ops wrap at those boundaries
> > and FB reads return garbage.
> > - off-screen memory on Visualize FX. STI reports 2048x2048 but
> > what's actually accessible is screen width rounded up to the next
> > multiple of 512 by screen height. There is a clipping register
> > which STI sets to match the video mode but setting it to 2048x2048
> > does not allow access to anything else, blitter ops wrap like on
> > HCRX. I *know* this thing has more memory than that. On the PCI EG
> > we get full 2048x2048 no matter what mode we're in.
> > - 24bit colour on the FX. I can switch the FB wndow to 32bit mode
> > but that doesn't result in 24bit pixels being displayed.  
> 
> I have not hacked on it since quite some time ... :-(

I only got started on hppa a year ago or so when I was able to get a
C200 and then a C360 system board for relatively cheap - I've been
writing drivers for weird and unusual graphics hardware for a long
time, just not in hppa.

have fun
Michael

Re: Graphics support (HP VisEG/VisFX/HCRX...)

[Michael]

Hello,

On Tue, 17 Dec 2024 21:28:08 +0100
Helge Deller <deller@gmx.de> wrote:

> Here are the Linux VisFX drivers:
> fbdev: https://github.com/hdeller/linux/commit/87e03df1af93e8236b3c1b44e60c0fa2d6c995d5
> drm:   https://github.com/hdeller/linux/commit/3a5fc28d9e3d39e7e116b8acf0b028a3024d9c36

From the register list:
#define UB_CF					0x40000c
#define UB_CB					0x400010

I'm willing to bet that these are Cursor Foreground and Cursor Background.
Going to check that in a little bit, I've been looking for that, but in
the wrong direction.

have fun
Michael

Re: Graphics support (HP VisEG/VisFX/HCRX...)

[Michael]

Hello,

made some progress.
Mostly detail optimizations on HCRX and EG, and a bit more substance on
the FX4:
- ROPs, cursor sprite colours, 24bit etc. work now
- both the kernel driver and xorg now abuse the back buffer as
  off-screen storage, since unlike HCRX we can set source and
  destination buffers separately on FX
- kernel and Xorg both use the hardware to draw anti-aliased characters
  ( the FX4 supports *some* alpha blending, more on that further down )
- image up- and downloads now use hardware assistance - framebuffer
  reads are *much* faster when you tell the memory controller in which
  direction you're going to read
Still a work in progress, EXA makes a lot of assumptions that aren't
true on these cards.

Now for alpha blending. By the look of it HP implemented just what they
need to draw anti-aliased lines and edges. There is:
- no framebuffer storage - alpha in 32bit colour always reads zero
- only a few blend modes are implemented, all using only source alpha (
  destination would read zero anyway )
What we can do with that is:
- vram-to-vram blits with constant alpha
- rectangle fills with constant alpha ( not too useful... )
- host-to-vram blits with per pixel alpha
The latter lets us do PictOpOver and maybe a few others as long as the
source is in main memory and the destination in video memory. Certainly
enough to draw anti-aliased characters, which is what my drivers are
doing so far.
I strongly suspect that HCRX can do this too, unfortunately I don't even
have a hint of a clue on how to do that.

As for FX5 and 10 - attribute handling on those seems to be
substantially different from FX2/4/6 :/

This is still NetBSD only, but may be useful as hardware documentation
in case anyone wants to update the linux drivers, and I'd happily
assist with that.

have fun
Michael