I compiled the old RISC OS Mesa port on my Iyonix this weekend and ran a demo app. Was disappointed to see that the framerate was still s***, but impressed that Aemulor Pro ran the old 26-bit demo apps not too much slower than my nice 32-bit versions.

I compiled the old RISC OS Mesa port on my Iyonix this weekend and ran a demo app.

Was disappointed to see that the framerate was still s***, but impressed that Aemulor Pro ran the old 26-bit demo apps not too much slower than my nice 32-bit versions.

So, after a bit of Googling, I found a BeOS open source OpenGL-ish driver using Mesa and an NVidia backend

I've been messing around with overlays on the Iyonix for a while with varying degrees of success and I would like to put my graphics knowledge to use in getting hardware 3D running on the Iyonix.

Can anyone here chip in any advice/help?

So, after a bit of Googling, I found a BeOS open source OpenGL-ish driver using Mesa and an NVidia backend...yes, it uses hardware acceleration.

Well, if you want something newer, the compiling the current Mesa/GL Stuff is pretty straightforward - it's part of Xfree of course.

I have working overlay code in Cino now, though I'm still not too happy about using it to be honest because the colours aren't right, and I don't think they ever will be whilst the R/B crossover is still present

Well, I can certainly contribute the low-level knowledge that's needed, ARM code, Iyonix hardware, DMA and nVIDIA access.

Is that *proper* open source or does it still rely on nVidia's precompiled binaries?

How does Viewfinder do it? I doubt it uses SW R/B swapping as the penalty would be large. Perhaps ATI cards support more types of byte ordering.

I just got 2D accelerated rectangles working...

Are rectangles drawn from BASIC accelerated in this way under the bonnet?

Is there a 2D acceleration module in development out there by anyone? Something that would provide accelerated sprite caching and plotting routines for games. If not, I might write one.

Yes, BASIC just calls the OS and it's the OS's VDU drivers that pass rectangle copy/fill operations to the graphics driver. The nVIDIA module only accelerates copies and solid rectangle fills though afaik; not inversions, for example.

You might remember the redraw cacheing prototype (accelerating the redraw of the ArtWorks Apple file, for example) that I posted in 'Programming' a while ago; well, that code found its way into Geminus too.

I have inversions working and tested. Perhaps I should speak to John Ballance about this.

So is Geminus useful for people who don't want to use dual displays? If so, I will look into it.

I'd love to see OpenGL/Mesa ported to the Iyonix but I think that's a separate project.

This thread is all very exciting

I just got 2D accelerated rectangles working...I know this isn't particularly impressive as it's been done before, but it's proof that I am talking to the NVidia card in the Iyonix (in particular talking to the FIFOs correctly), and a good stepping stone on the way to the 3D driver.

I was thinking of looking at this to speed up the redraw of a certain web browser (currently in development) when running on an Iyonix. I looked at the BeOS driver but don't currently have time to work out what its up to

Don't suppose you've spotted how to speed up the rendering of bitmaps? Especially bitmaps with an alpha channel?

I was thinking of looking at this to speed up the redraw of a certain web browser (currently in development) when running on an Iyonix. I looked at the BeOS driver but don't currently have time to work out what its up to

The main problem here is the speed at which data can be transferred to the screen once it is generated by the web browser. I believe Adrian wrote some routines to do fast memory transfers for image data.

The NVidia card could be used to speed up the rendering of solid blocks of colour, like rectangles or scanlines, but the OS already speeds up these types of shapes for us.

The other thing it could do is buffer commonly used sprites, like backgrounds or even entire windows for fast scrolling. I do believe it can support 8 bit alpha channels too, but I haven't yet found out how to use those in 2D.

Don't suppose you've spotted how to speed up the rendering of bitmaps? Especially bitmaps with an alpha channel?

Yep, bitmaps can be copied into graphics card memory and then redrawn as many times as you like, very quickly.

I've certainly seen that mentioned for Cino, to speed up DVD playback. Such funtionality would be useful to have, but it would need to be able to handle the source and destination being of different colour depths (i.e. rendering an 8bit image to a 32bit display).

What I would like to be able to do is request a rectangle to be drawn, and then have the main CPU carry on working out where to draw the next rectangle whilst the graphcis card is busy performing the work. This way the CPU can get on with something useful.

What I would like to be able to do is to render all output into an offscreen buffer (Held in the Graphics card memory) and the copy that to the display.

This would certainly be a useful feature to have, but I think the biggest performance gains would be to have HW support of the alpha channel, because at present when rendering image data with alpha (PNGs, text) we have to read the current contents of the display to work out what the final pixel colour will be. And reading from the graphic's card memory is supposed to be very slow.

I've certainly seen that mentioned for Cino, to speed up DVD playback. Such funtionality would be useful to have, but it would need to be able to handle the source and destination being of different colour depths (i.e. rendering an 8bit image to a 32bit display).

I wouldn't be surprised if the NVidia card could do some depth conversions in hardware. I just don't know how yet.

What I would like to be able to do is request a rectangle to be drawn, and then have the main CPU carry on working out where to draw the next rectangle whilst the graphcis card is busy performing the work. This way the CPU can get on with something useful.

This is how my 2D stuff works - the CPU does not wait for the GPU to finish after pushing it the graphics operation, leaving the CPU to queue up more graphics operations or do other work.

What I would like to be able to do is to render all output into an offscreen buffer (Held in the Graphics card memory) and the copy that to the display.

I think you can just set up two screen banks in the usual way and then draw with my accelerated routines to the back buffer, before swtiching. Or, you could allocate the back buffer yourself in graphics card memory (placing it away from anything else).

This would certainly be a useful feature to have, but I think the biggest performance gains would be to have HW support of the alpha channel, because at present when rendering image data with alpha (PNGs, text) we have to read the current contents of the display to work out what the final pixel colour will be. And reading from the graphic's card memory is supposed to be very slow.

The GPU supports various raster operations (ROPs), which allow you to do stuff like this (making changes to the frame buffer based on the old contents).

Does your 2D code allow the CPU to put together a list of graphics operations and then send them to the GPU in one go? Or is there no real performance difference between sending multiple requests over the PCI bus, compared to sending occasional blocks of requests?

When I manage to find some free time I will have to work out how to do that. I've not yet looked at how to play with PCI devices on an Iyonix yet.

Does your 2D code allow the CPU to put together a list of graphics operations and then send them to the GPU in one go? Or is there no real performance difference between sending multiple requests over the PCI bus, compared to sending occasional blocks of requests?

My code isn't that generic yet, but yes, you can potentially queue up a list of operations and send them to the GPU in one go. At the moment, the CPU sends the commands in chunks, one chunk for each operation.

I've done some performance measurements of such a system on other hardware, but not the Iyonix yet. It is certainly better if you can keep the GPU busy with rendering operations while doing other stuff on the CPU.

When I manage to find some free time I will have to work out how to do that. I've not yet looked at how to play with PCI devices on an Iyonix yet.

You can set up two screen banks in the usual way and switch with OS_Byte 112 and 113 (ask if you need more info).

Well, I've got Mesa 3.2.1 building and the NVidia 2D and 3D drivers too...just got to put everything together now. At this point I still haven't run a 3D test, so who knows what'll happen.

Well, I've got Mesa 3.2.1 building and the NVidia 2D and 3D drivers too...just got to put everything together now. At this point I still haven't run a 3D test, so who knows what'll happen.

When it freezes your Iyonix and you need some help debugging it, let me know!

When it freezes your Iyonix and you need some help debugging it, let me know!

Thanks! I will most certainly take you up on that offer, sir!

Aw c'mon. You're supposed to be reporting on rotating teapots by now

Couldn't get DMA working last night. I actually suspect it might be working, but I lose all display output at that point.

Could you dump a screenshot to disc to test this?