Did You Know...?

[Vimacs]

Linux is actually a blessing for the gp2x, without it we wouldn't have nearly as much software as we have now, it also makes debugging/rapid testing a lot easier,
while only taking a small percentage of the available resources.

However the more advanced the software gets the more you want to exploit the hardware directly.

That is where robs trampoline/sdk2x (hh) will be of great use in the future.
Trampoline will allow us to run things on hardware from "within Linux" (well, not really as it gets quit before, but it looks alike) as long as we don't have a real alternative firmware,
and programs written for it will likely continue running on any direct hardware firmware/launcher attempt.

So in the first month's of gp2x's live everything/most will be/is within Linux with slowly need for more, so now first solutions will be kernel modules and in a few months more advanced stuff will likely move to sdk2x or a similar solution.
And within a year we will likely move completely move to some direct hardware approach.
The problem that will arise is that many older soft will stay at Linux which will than be pretty annoying as you always have to wait for Linux to boot to start, but chances are quite good that the startup time of Linux will improve in the future as well.

Now my crystal globe needs recharging.

 

[Gaijin]

linux is not pants. linux is underwear. in your case, probably road-tripp'ed underwear with skidmarks.

in my case, linux is a case of being girls panties, on the floor of my bedroom, a couple pairs scattered here and there, and i'm the one in bed with boxers on, nice and snug ..
*




Yeah but since you are comparing the girl to linux she must be 600 pounds wink.gif And those panties could be used as a pup tent, and she is yelling "is it in yet". Because linux is a slow, fat, bloated, PIG.

Hey No fair, any OS/Kernel is only as good as it's has been coded to be, i'd far rather have thousands of people improving things part-time than a few hundred full-time (And not releasing patches until it's too late, you know who I mean Gates).

For example I run a Vector Linux distro on a P3M 1.3ghz laptop that runs like a cheetah coated in teflon and fitted with an adrenaline suppositry (Nice mental image huh!), this makes my desktop P4 3Ghz with Winblows XP look like a particularly sluggish sloth.

Anyway given time I'm sure that Emus and apps can be written that directly access the hardware without using the linux kernal = full on!

N.B don't forget that the 2.4x kernal in the 2x is hardly the latest

Just my 2 pence


Now play nice

 

[Squidge]

There's nothing physically stopping you, but the cache needs to be in sync with memory.

I concur, to a certain extent.

What if if the 920 writes "1" at 0x100 but caches it.
The 940 then writes "2" at 0x100, also caching, but the cache line gets written out.
The 920 now decides to flush, 0x100 now contains "1", but the 940 still thinks it's "2".

The idea is that you never write single bytes. You don't use the memory for IPC of the like of "here's a command, go and do it". You only use the memory for buffers - as in, here's a block of data. In which case, you know when you have finished, so can request an explicit cache drain (not flush) at the end of your copy loop, or just blit the bugger into memory and avoid the cpu's cache completely (kinda difficult as we don't have access to memory < 32mb)

IPC Requests for the 940 should be sent along the proper channels, and not through main memory.

Shared memory space should not be cached, if it's not shared, why allow the 920 to potentially cache the 940's memory?

The 940 doesn't have any memory, it shares the 920's. Also, we don't have any access to turn a virtual address to a physical address, so if we need to use the hardware (eg. the blitter), we MUST use memory above 32mb. It would be silly therefore to disallow the 920 to not be able to cache this memory whilst it is working on it. Why slow down an application unnecessarily by 65% if we don't need to?

Plus, why slow down the applications which don't make use of the multiprocessor support? This is why I said the module should be configurable via a /dev or /proc entry, so an application could state how it liked the memory setup.

​

Any program that does use the 940 but relys on the memory model as it stands could really mess things up.

​

Very true, but I'm talking about a module that makes things optional - so current programs run with the cache turned off, and it's on turned on from a program request (even though as of yet the only program to use the 940 is the Movieplayer). Programs designed to run in an environment where both processors can cache the entire 64MB will have no problems if written correctly. There are instructions to ensure the write cache is properly written to memory, and can be called after any datablocks are written that might be required by the other processor. It should be understood that neither processor will attempt to access the others data randomly without some kind of IPC through the proper channels to ensure that the data is there.

 

[Ravnos]

linux is not pants. linux is underwear. in your case, probably road-tripp'ed underwear with skidmarks.

in my case, linux is a case of being girls panties, on the floor of my bedroom, a couple pairs scattered here and there, and i'm the one in bed with boxers on, nice and snug ..

​

Yeah but since you are comparing the girl to linux she must be 600 pounds And those panties could be used as a pup tent, and she is yelling "is it in yet". Because linux is a slow, fat, bloated, PIG.

​

Spoken like someone who has no idea what he's talking about, which is pretty much how it comes across every time you talk about Linux.

 

[deadlychicken22]

Davec:
linux is a BLESSING for the gp2x. We wouldn't have nearly so many games available already if linux wasn't on the gp2x, and we would have a much smaller community as many of the people who jumped on the gp2x heard about it from linux websites because it runs linux. I agree that HH will be great for things that want to get the most out of the hardware, but linux is great for developers who don't want to mess with that stuff. In a couple hours I got dev-c++ hooked up to compile things for my gp2x and had my own SDL tests running great on my gp2x in no time. Programming for the gp2x without linux would probably scare me away as I don't know much lower level stuff.

 

[paeryn]

The idea is that you never write single bytes. You don't use the memory for IPC of the like of "here's a command, go and do it". You only use the memory for buffers - as in, here's a block of data. In which case, you know when you have finished, so can request an explicit cache drain (not flush) at the end of your copy loop, or just blit the bugger into memory and avoid the cpu's cache completely (kinda difficult as we don't have access to memory < 32mb)

IPC Requests for the 940 should be sent along the proper channels, and not through main memory.

That was as an example, I wasn't suggesting using shared memory to send single bytes, just that if each processor has seperate cached values of the same memory then things are out of sync.

The 940 doesn't have any memory, it shares the 920's. Also, we don't have any access to turn a virtual address to a physical address, so if we need to use the hardware (eg. the blitter), we MUST use memory above 32mb. It would be silly therefore to disallow the 920 to not be able to cache this memory whilst it is working on it. Why slow down an application unnecessarily by 65% if we don't need to?

That's why Linux is set up to ignore the upper 32M, it's there for the 940 and hardware. Ideally you'd use the upper 32M to hold graphics & sound, and "normal" memory for everyday work. The blitter can work with the graphics fine and apart from initializing you shouldn't need to access that memory - at least not often enough to make uncached memory be a problem.

Any program that does use the 940 but relys on the memory model as it stands could really mess things up.

​

Very true, but I'm talking about a module that makes things optional - so current programs run with the cache turned off, and it's on turned on from a program request (even though as of yet the only program to use the 940 is the Movieplayer). Programs designed to run in an environment where both processors can cache the entire 64MB will have no problems if written correctly. There are instructions to ensure the write cache is properly written to memory, and can be called after any datablocks are written that might be required by the other processor. It should be understood that neither processor will attempt to access the others data randomly without some kind of IPC through the proper channels to ensure that the data is there.

​

What if a program is already running in the background that expects the cache to be off, it's okay for a new program that knows about it, but it can break old code that doesn't. Flushing caches isn't something that user-space programs should worry about. It's okay on HW like the GP32 or GBA where your code is the only program running and you have full access to the system.
Then again, I suppose not many people are going to be running anything other than one program at a time. I'm not saying don't do it, just be careful and be aware that it could cause problems.
goes away to add locking code to SDL - this thread just reminded me that two programs trying to access the screen will mess things up...

 

[Squidge]

Ok,

The problem I have at the moment is that I need to clear a rather large array at the end of every frame. The array is used constantly throughout the frame.

So, I can either do a memset or similar on this array, or I can put the array >32mb and use the blitter. Using the blitter gives me an increase of about 4fps, so I would obviously like to use this advantage. Since the array is accessed constantly, it should give me a nice performance increase if the memory was cached also.

I guess I should just ignore Linux and rewrite it as a HH-mode app - that way if anything is running in the background which may object to what I'm doing, it won't have time to start bitching

 

[paeryn]

Hmm, that's quite an increase. Would be interesting to see how much better caching gets it. If only GPH had designed the GP2X more as a games machine - as far as I can tell a lot of that upper 32M is wasted.
Do you know if Linux is set to reload all the program/data that it uses for the 940? I'm worried that if I trash some of the memory it uses for video decoding mplayer might not work afterwards without rebooting... Might test it by trashing the whole 32M and see what happens

 

[Squidge]

The upper 32mb is completely initialised whenever the kernel runs, so you can kill as much data there as you like, the only problem you'll get is mplayer not working until the next reboot.

 

[God Ginrai]

I don't care as long as it works the next reboot. ;P