Moving along


The OMAP does throttle, but not very useful (once it reaches a certain temperature it goes down to the lowest speed until it has cooled down again.

This doesn't make much sense. It should dynamically throttle to keep the heat below that temperature, but running as fast as possible.

The memory is what causes the freeze right now, as it has no throttling and produces errors.
That will be fixed with the heatsink and also, it's a nonrealistic scenario, as you never stress the memory that much.

Sent from my Moto Z using Tapatalk

How about a keyboard shortcut to control control under/over clock? (Overridden by Temps of course)
Ctrl+brightness up = raise clock
Ctrl+brightness down = lower clock

I would like to underclock as much as I can get away with if I have an easy way to adjust up at a whim.
 
The CRT filters in Retroarch are not that CPU intesive if I remember correctly.
The Pyra should be beefy enough.
:(I've never used retroarch before, just standalone emulators like SNES9X & ZSNES, is there a way to force it to just use a normal, simple, nested file(s) in folder tree structure (organized alphabetically by file name) within a window, like in a standard Linux or windows program, or are you just stuck with the ps3-style XrossMediaBar interface? Also, do you have to let it scan your files/games and decide on your behalf how to organize them in order to use it?
 
Retroarch is pretty easy and has a filemanager-like interface where you can choose your roms.
I recommend watching a how-to on Youtube.
 
I would like to underclock as much as I can get away with if I have an easy way to adjust up at a whim.

On my Pandora, after I broke the LCD connector, I configured keyboard shortcuts in the XFCE keyboard settings panel to run scripts that turns off tv-out and put the max clock down to 125MHz, and another to turn it on and put the max clock up to 1.1GHz. At 125MHz I could still play mp3s which was my main use of the unit when headless (via keyboard controls to deadbeef).

There's a small benefit of doing that over allowing the on-demand scheduler to spot when it can scale back the CPU clock over the course of a couple of days. If you have an operational LCD and like the check the unit frequently, it might be inefficient to keep modifying the max CPU clock like that I dunno.

I think the benefit came because the on-demand scheduler needs to raise the CPU clock frequently to work out how much the CPU is being used. If you stop it raising it beyond 125MHz, then it's much slower in calculating the CPU usage, but given it's throttled anyway that doesn't matter.
 
How about a keyboard shortcut to control control under/over clock? (Overridden by Temps of course)
Ctrl+brightness up = raise clock
Ctrl+brightness down = lower clock

I would like to underclock as much as I can get away with if I have an easy way to adjust up at a whim.

Usually you don't want to do that as "race to sleep" is a more power efficient strategy.
As the system already downclocks to the minimum possible when there is no load, you want to finish the tasks as soon as possible (highest clock) to then spend most of the time in the lowest clock.

Disabling the top end clock speeds could still be an option if the power curve doesn't scale that well towards the end, but that would still be a on/off option.
 
Regarding GPU. How does this thing about a 3d chip and a 2d chip works?

Does the vivante have better support? It's enough to run desktop software, render webpages, videos, abd the like.

Or it's just integrated on the gpu and transparent to the os?
 
The CRT filters in Retroarch are not that CPU intesive if I remember correctly.
The Pyra should be beefy enough.

There are some that will give a HD4000 gpu a run for the money. It is extremely easy to find retroarch shaders that will overload a mid-aged, midrange office laptop.
 
Regarding GPU. How does this thing about a 3d chip and a 2d chip works?

Does the vivante have better support? It's enough to run desktop software, render webpages, videos, abd the like.

Or it's just integrated on the gpu and transparent to the os?

I don't really understand why you're referring to Vivante. The OMAP5 has a PowerVR SGX GPU from Imagination Tech.

IIRC there's also a 2D blob of transistors based on ARM IP, but I don't really know anything about that.

AIUI the 3D chip works by taking a scene description (textures, vertices, etc.) from RAM and feeding back a framebuffer scene back into the RAM, which is then taken and rendered as per any 2D framebuffer would be. It's not really used by desktop software, or web browsing, but I'd have thought videos and 3d games would be heavily impacted by this.

From what I've heard, the missing thing is the shared lib that sits between the kernel and the GPU blob from TI. It could be worked on now, but only really by the people with a prototype unit, and right now it doesn't look like the units are going to be mass produced urgently, so the need for the 3D driver is also non-urgent. As is if they were to work on it now, the kernel would likely change underneath it before launch, and the work would be somewhat wasted.

Don't forget Notaz got the whole schebang together on an old kernel on the devboard well enough to run a Dreamcast emulator seemingly in a day or two while at a show. Perhaps when it's needed it'll just pop out again.
 
Ah okay. Wikipedia being a bit pants then, unsurprisingly.

https://github.com/etnaviv/etna_viv is a project to support the GC320 on various other chips and has been mainlined for recent kernels. That suggests it should just work (assuming TI haven't done something weird in their implementation), and interestingly, exposes OpenGLES2.0 and is apparently capable of running Quake on devices like the GCW Zero.
 
and interestingly, exposes OpenGLES2.0 and is apparently capable of running Quake on devices like the GCW Zero.
Not sure where you got that from, the GC320 is a so-called "Composition Processing Core", it only support 2D operations - you can apparently get DirectFB, but not OpenGL ES. It is often being coupled with actual GPU cores like the GC3000, which is not the case on the OMAP.
 
Another brainfart is seems. The linked wiki from the project I linked says you can run Quake on the GCW Zero using this, but I'd misread the GCW Zero as having a GC320, whereas the project readme suggests it has a GC860 instead.

I suspect it's rather academic anyway. I know the TI blurb says this will help with web browsing and video playback/transcoding, but only if you're using TIs half broken non-standards compliant and expensive software components. Maybe some open source web browsers can use it for blitting bits of the screen about as you scroll, but I'd have thought they'd just target something like OpenGLES to do that. Knowing the way the ffmpeg team tends to work though, they may well have speedups for that and mplayer using this, I guess.
 
Back
Top