xrender in cg14 & SBusFPGA (was:Re: CG14 with xrender)

Le mer. 12 janv. 2022 à 19:25, Romain Dolbeau <[email protected]> a écrit :
> But then on my 'todo' list, I also need to do a 8/24 FB with some
> acceleration (...)
> So in the meantime I've found another way to waste time and money -
> I'm considering re-using the same FPGA daughterboard for a NuBus
> carrier for old Macs, where I could prototype the VGA and/or HDMI
> output (...)

Well, some months later, the NuBusFPGA
(<https://github.com/rdolbeau/NuBusFPGA>) is working in 1/2/4/8/16/32
bits in my Quadra 650 - in MacOS. I still need to try it with NetBSD.
Discussion is in
<https://68kmla.org/bb/index.php?threads/nubusfpga-hdmi-on-nubus-macs.40760/>.

The original 8/24 bit FB had been prototyped in SBusFPGA, but a lot of
work went into making the NuBusFPGA "reasonably fast", so I backported
that variant to the SBusFPGA to get an accelerated 8/24 (8 bits in
console, 24 bits in X11) framebuffer.
And I've started adding 'render' support - or rather, EXA Composite.
Which is not the best documented piece of software :-(

Having used the cg14 code as 'inspiration', some thoughts and questions.

Le mer. 11 mai 2022 à 23:09, Michael <[email protected]> a écrit :
> (...) I'll have to read up on what exactly things
> like PictOpSrc with no source operand but a mask are supposed to do.

From my reading of render, the ((src IN msk) OP dst) uses Alpha of 1.0
and colors of 0.0 by default, so I read this specific combination as
setting the dst to the msk alpha and 0 color.
(src OpIn msk) will apply the msk's alpha to src, so that produces (mskA,0,0,0)
Then the OpSrc operator will just copy that to dst.
I can't try that on my system as I don"t see that operator applied
after adding OpOver and OpAdd.
Also, 'rendercheck' fails a lot ... even without any acceleration :-(
Endianess issue ?

Also a question on the SX instructions; the name of the multiplication
instruction sort of implies it does "(a*b)>>8" (a*b)/256), but render
says [0,255] is [0,1], so the computation needed is (a*b)/255 if I
read the spec correctly ? (I've added a custom 4x8 SIMD FMA to my
RISC-V core to do ((a*b)/255 +| c), where +| is the saturated addition
; as I understand it the SW does saturation by clamping during the
'store' ?). Without the 'appropriate' division, 'rendercheck -t
gtk_argb_xbgr' complains that the result is 1 too low in every
channel; e.g. (0x44*0xff)>>8 is 0x43, but should be pass-through so
0x44.

And I don't see the cg14 code checking for 'filter' or 'transform',
are they never set ? I think if they are non-NULL the code should
currently decline to accelerate. But I've yet to see either non-NULL
on my system, I'm not sure if that's actually used...

Cordially,

-- 
Romain Dolbeau