Of course, it depends on how much they care in monetary terms. The N810 will (soon) be replaced, work is going on for the new platform, whether the N8x0 plays a part in this really depends on whether Fremantle on these devices is planned, and that we don't know.

There are other annoyances with the omap2xxx platform that are perhaps not so easily solved, like Ti's closed stance wrt documentation when compared to the omap3xxx platform, etc.

josiahg777,
thanks for that, I'll take a look tonight.

lardman,
That kinda fits with what we have already heard, but then Kate has said that the chance for a person with the right experience could try at least to see a path.
I would love to have the chance to try, however I think I lack a lot of experience in both the inner workings of the omap and with linux kernel mods and device drivers as a whole.

I'm gonna see what can be done with the software 3d stack though as a backup plan and way for me to pickup and learn the requirements and complexities

Not sure I have much experience in this either, but I'd be willing to give it a go.

\o/ Goooooooooooo lardman!
Save the powervr, save the world.

And who says you have no experience?
I can't think of anyone better suited right now, you know more than most about using the custom DSP onboard, you hack drivers for fun and have a very clear voice of reason to evaluate any potential future with it.

I, for one, think you are the right person to attempt such a challenge.
(assuming of course we can clear this from within Nokia etc)

This was my impression of the only way out of the situation. From what Quim's said on the discussion page, however, there may be problems signing NDAs between an individual and Nokia.

However, from direct experience, it is something they can do as a company.

Well, we might as well see how far we can go with software rendering...

While poking around the Mesa site, I found some performance tips, and I ended up here. Just another bit of info, not extremely useful or anything... Oh, and the DRI site points to KallistiOS, and the link is dead. But I found the current KOS site here. Downloads here.

Me again.

Still poking around the Mesa site and I found some information about mesa's glfbdev-driver, which seems to be a version of software GL targeted at embedded devices and which writes directly to the framebuffer. Is that something we're interested in?

I could've sworn that the Dreamcast didn't use tile-based rendering, instead something about infinite planes... Maybe just a mis-fire in the old brain. I pulled out my Dreamcast the other day and the newest save was from 2001, so it's been quite awhile since I was into the homebrew scene...

qole,
I think the DC used the older discrete video card chip that was in production before the powervr technology was burned onto the omap chip.
I like your thinking re optimizations and will come in handy, thanks for examining all this.

I have gotten most of the things together for an opengl software run (barring the configure step required for the gears example)
I've rebuilt a custom makefile and have half of it done, just failing on dependencies for one more file (its purely a config thing)

Joshua, thanks very much for the outline, you have simplified much of it, and as you say saved a bit of headscratching for certain elements.

I've had a few things on my mind recently which are emerging at the moment, but I should be following up with this as much as possible.

turbo-charged easy debian: $0
liqbase: $0
qole and lcuk collaborating: priceless

and maybe sprinkle in some lardman