If anyone is interested in raw meat, just lookup pcx/hwregs.c 😀 You will find HW registers as well as PCX buffer location (system memory, lookup also PVROS implementation and win32/* for this) as well how it's passed to the PCX2 - how cool is that! Tomorrow I'll revisit my PCem fork, maybe I'll be able to go further with my emulation project 😀

Yay, everything is better with sauce.

Happily, I just located one of my Apocalypse 3Dx cards.

There's no MiniGL source I can find in there though, but should be enough legally cleared meat to make a better Mesa-powered one. 😀

Isn't it enough to make an OpenGL wrapper? Besides whatever voodoo is needed for DOS games, wouldn't it be (relatively) simply to do this in Windows?

Yeah, but I was thinking the other way around, to use PCX2 hardware better 😀

Yes, I agree. Do we even need to recompile the display driver or just the SGL library to add improvements?

Nah skip all that, go straight for Vulkan support 🤣

Though actually, with presumably having the foundation there, can we slap any walls and floors on it provided by development on the androids/ARMs using PVR derivatives?

simulat3/texas.c's TexturePixel function looks very interesting... (simulat3's a folder full of PCX2 hardware simulation code)

According to Simon Fenney (https://news.ycombinator.com/item?id=30777440):

>I think the "simulator" code is also bundled in there.

Haha it'd be typical that when I finally got a Matrox M3D Tuxality finds what he needs to finish the emulation 😁

I'm the guy who did the arm mali gpu reverse engineering and who started the whole open source drivers for arm movement (and modesetting, and the free ati driver, and ...). From the start, i planned for IMG to be singled out, and provided the reasons for doing so. If you hear or heard anyone state, in the last decade, that powervr SGX code is horrible and the hw is not worth reverse engineering, they have been repeating my statements and insights into that topic.

According to my insider info, IMG actively thought about going open back in 2014 and 2015, but each time could not get itself to spend the resources. There were also quite some rumours flying around. Last summer, as a corona babysitting project, i plugged my M3D in a pci-e-to-pci adapter, hacked QEMU to handle the iommu properly, and have been running Win98SE over X to my laptop. Capture was incomplete though, and replay was not happening. I spent a lot of time (on and off) with ghidra and found what i had been missing back in january. Then real life interrupted again, and this lay dormant.

So then my original plan worked out. With a 5-8y delay, but it worked out. But it killed what would have been the perfect troll, the start of an actual open source driver for powervr, but not a "useful" powervr... And i spent a few weeks debating whether i should continue working on getting a first triangle out, and doing a but of further code and a release still... And then IMG went above and beyond. It costs them barely anything, and they are getting a lot of goodwill out of this.

I have the previously publicly available demos ported to build under mingw32. Once i revive my build machine, i will get that code out on github.

As for mesa... This is very early and weird fixed function hw, i do not think this has a place in modern mesa. Parts of mesa could be retooled to provide the gl translation layer though.

libv wrote on 2022-03-30, 10:21:

If you hear or heard anyone state, in the last decade, that powervr SGX code is horrible and the hw is not worth reverse engineering, they have been repeating my statements and insights into that topic.

You are not the only one 😉

In 2008ish , there was some effort at Nokia/TI/IMG to get some decent PowerVR MBX out for Linux (proprietary or not). Nokia had already shipped several "somewhat open source" Linux devices using the MBX (the 770/N8xx internet tablets), but actually shipped no drivers whatsoever for the MBX at all due to difficulties in getting them to work, and Nokia was not that interested in 3D anyway.
With some pressure, TI/IMG decided to split the driver into what is now more traditional for Linux (but then wasn't!): move most of the code out of the kernel and release whatever must remain in the kernel module under the GPL. Then they gave us both the kernel module source and binaries for the userspace part but otherwise left us on our own to try to get it working on our devices.

10 year younger me was so excited about the entire thing ...
I remember spending most of Christmas 2009 working on getting the driver to render a single triangle... =)
Eventually I got something moving inside a X window, with a lot of gotchas.

Now the N8xx graphics architecture was a bit bizarre: OMAP2 graphics hardware could not contain the full 800x480 framebuffer (this was when 320x480 iPhone was "revolutionary").
But the driver code ... that was filled with the stuff of nightmares.
Actually I don't specifically remember much of it, I guess my subconscious has blocked it or something.
The thing had clearly evolved from a DOS-era library, it was still full of references to FAR pointers ( obviously #define'd to '').
The 3D libraries were actually doing IPC with another daemon who would then call the kernel...
Loading a texture would take forever.... and it was FULL of memory leaks. EVERYWHERE.

So I quickly got tired of it, too. Didn't help that by then SGX had been released and I already had new hardware on my hands

I have to admit, that entire experience left me very bitter about GPUs overall.
10 year younger me would have assumed rendering lines on a GPU would have always been faster than on the CPU (e.g. OpenVG).
Present me still doesn't dare to do 2D on a GPU 😀.

javispedro1 wrote on 2022-03-30, 11:35:

Now the N8xx graphics architecture was a bit bizarre: OMAP2 graphics hardware could not contain the full 800x480 framebuffer (th […]
Show full quote

Now the N8xx graphics architecture was a bit bizarre: OMAP2 graphics hardware could not contain the full 800x480 framebuffer (this was when 320x480 iPhone was "revolutionary").
...
I have to admit, that entire experience left me very bitter about GPUs overall.
10 year younger me would have assumed rendering lines on a GPU would have always been faster than on the CPU (e.g. OpenVG).
Present me still doesn't dare to do 2D on a GPU 😀.

I was at nokia from June 2010, until the end of 2011. So after the n900 (omap3, sgx530) was released, but before the N9 (omap3, sgx530) was released, pretty much 9months either side of the elopcalypse. Seems like you were at nokia before the N900 was being worked on.

I was fixing up the debugging infrastructure of the SGX, with most of the work going into the kernel. This is how i had my fun experiences with the SGX and why i knew that it was a waste of time to RE it.

We visited IMG head office in november 2010 and got the rogue presented to us. My main take-away, the re-introduction of a blitter. "we can do it all on the GPU" is correct, but the keyword is "can", not should. Copying bits of fb around, and drawing some simple things are much much more efficient, in every sense, on dedicated engines. But blitters and 2d engines are just not as sexy as full blown 3d engines.

libv wrote on 2022-03-30, 15:10:

Seems like you were at nokia before the N900 was being worked on.

(For the record I was never at Nokia, just one of these annoying "community" guys. Good times.)

I've asked about the source of the PowerVR Extreme MiniGL and they couldn't find a lead 🙁

So, uh..... maybe there's better luck poking Techland about opening up theirs?

(sorry, I have no SGX slander to share)

Was there anything special about the driver code in the matrox version of the hexen 2 demo? Or was it just the same old SGL wrapper?

(Sorry for shitting up the PVR esoteria thread with such a mundane topic)

It's the same GLHexen II but...

- it's ONLY GLHexen II. No software Hexen II provided.
- it's named "pvrh2" instead
- still an OpenGL game

It doesn't do anything special or out of the ordinary that a stock Hexen II with the PowerVR GLQuake MiniGL can't do. It is 1.10 though, while retail was 1.03, and so has some fixes.

I did a video comparing the PCX1 and PCX2 which might interest you guys.

https://www.youtube.com/watch?v=FetxUywyGf8

mwdmeyer wrote on 2022-06-05, 05:17:

I did a video comparing the PCX1 and PCX2 which might interest you guys.

https://www.youtube.com/watch?v=FetxUywyGf8

I saw the YouTube notification I cant wait to get home from work a give it a watch.

Another great comparison is Tomb Raider in software mode vs PowerVR. Of course, it also supports the Voodoo and Voodoo 2, so this is not exclusive.

I always love seeing MechWarrior 2 running on a PCX2. It is glorious.