forums.ps2dev.org

I think making an SPU-accelerated Xv driver with XvMC could be a good place to do it. I think too it is the best option: - SDL has support for xv - mplayer lib vo can use xv. However I don't know how easy (or difficult) it is to add xv into the X server (can it be done without touching the server o...

yes it matters since the last ~4 revisions or the kernel will stop being able to mount the internal disk (1.50) but maybe they don't affect the wlan support If I understood correctly on IRC yesterday, you are using Geoff's PS3 kernel tree. Nothing proves TerraSoft's kernel is just a version of that...

Ps3Rips wrote:Get everyone off buggy firmware so that exploit routes are closed and the platform remains more secure.

Oh, some exploits were found? Got some link for uneducated people? :)

StrontiumDog wrote:Yep, unfortunately its just WiFi. And in a weird twist its either WiFi or Wired, but not both at the same time (both are eth0)....

Too bad :)

Now it remains to be seen what other changes made their way into this new kernel...

urchin wrote:OpenGL or Wifi? (both of which could require a hypervisor upgrade)

Hint towards WiFi: kernel

Well, it should be fairly easy to test by disabling the kernel blit on vsync and run manual blits as fast as possible (no need to draw anything). If the speed is over 4GB/s, then it's definitely the GPU doing the blitting. Though that'd be interesting to measure, I fail to see that it would prove w...

It's actually the GPU that does the blitting (upon receiving a command from the SPU running the hypervisor). Where did you get that information from? All we know is that the kernel makes an hypervisor call to transfer its FB (in XDR) to GPU VRAM. I bet it's done using the MFC DMA from the Cell. @ps...

However, we do know that it's one of the SPUs that's blitting from XDR memory to VRAM. We are not sure it's an SPU that does the job... Anyway I am ready to bet the hypervisor makes the transfer using DMA, and that's why the question StrontiumDog asks should get answered :) Given that it must be ca...

The main problem is that the memory is allocated is kernel space, so we'd need an extension so that it can be accessed in userland. Of course, this may be exactly what the hypervisor module is for, but I haven't yet looked at it, as I still haven't got my standard kernel quite as I want it. What we...

Message: 1 Date: Thu, 26 Apr 2007 13:04:06 -0700 From: Owen Stampflee <ostampflee@terrasoftsolutions.com> Subject: [ydl-gen] YDL.net Enhanced PS3 Users, I have a surprise for you all. To: yellowdog-general <yellowdog-general@lists.terrasoftsolutions.com> Update your GameOS so you'll be ready ;) Tha...

So there might be some permanent, massive data transferts from the cpu-side ram to gpu-side ram (probably a bitblt gpu operation, triggered at each vertical blank event, which is just a standard dma access controlled by GPU). Right, the blitting is done by a kernel thread, so your explaination look...

jimparis wrote:I'm seeing it reset to some other value after 15ms or so. Definitely weird.

15 ms looks suspiciously close to the framerate.

BTW doesn't the 256 MB area also contains GPU IO address space?

Anyway, if my memory is correct, the PPU <-> GPU Ram access is very slow compare to PPU <-> Main Ram (And now with a hypervisor process between). I would be surprised if Hypervisor by itself would slow down memory access. I guess it would only if it played with the MMU to force software R/W to some...

Someone did something similar here CellPerformance.

Might be nice to merge both to get the best of them and also have only one such useful library :)

I just wan't to be able to access to the gpu to start to realize a true opengl driver. You mean you intend on: 1. filling the holes in missing reverse engineered information obtained by the (re)nouveau project 2. bypassing the hypervisor protection (provided the RSX mmio is indeed protected which h...

Title says it all: http://sourceforge.net/projects/libspe

The announcement was made on cbe-oss-dev mailing-list: http://ozlabs.org/pipermail/cbe-oss-dev ... 01542.html

Here you go:

http://ozlabs.org/~jk/projects/petitboot

BTW ozlabs is the host of the cbe-oss-dev list which is interesting to follow :)

Hey what about stopping giving numbers and try to code, that would be more fruitful. We could for instance try to beat IBM numbers :)

However, abck to cryptanalysis, you almost certainly won't need floats and doubtful that you'll need to be multiplying more than 16 bit integers anyway (probably the hardest is a multiplcation over GF(255) ) Number theoritic based cryptographic algorithms, such as RSA, need fast integer multiplicat...

Indeed the SPU is quite limited wrt integer math: you only get 16x16 -> 32 bit multiply, which is certainly killer for many cryptographic algorithms...

You should read available documentation about SPU instruction set before considering the PS3 :)

I think many people here are religious about giving away the source code. I don't seem to understand why. most game and software companies don't go around giving away their source, and if they do it is only years and years after they are not the current technology. But since I did get some help, I'...

Fact: Linux can only see 0xE0000000 = 234881024 bytes = 224MB. So the top 16MB seems to be reserved by the Hypervisor. Reasonable enough. That should read 32 MB I guess. Fact: Linux only reports it has Total memory = 200888kB ??? Where does all the other ram go? Not making much sense to me at the m...

You miss some blocks in your block loops : You should either change < with <= or remove the -1.

Not sure it has anything to do with your problem.

Your code looks OK...
Try to allocate "block" with malloc and see if that changes the behavior (if so, this *may* be a compiler bug).

Also play with the compiler flags (e.g. no optimization enabled).

I guess this will be used for pcsx2.

Yes perhaps something newer than SDL is needed, but right now the number of packages just requiring SDL to run is rather big (so, many examples to start from) and documentation is plenty enough.

And now for the shared library stuff. Makefile CC = /usr/local/ps2/bin/mipsEEel-linux-gcc DEBUG = -g CFLAGS = $&#40;DEBUG&#41; LDFLAGS = $&#40;DEBUG&#41; # Binutils execs OLDAS = /usr/local/ps2/mipsEEel-linux/bin/as NEWAS = /home/ldesnogu/Binutils/Dev/strippeddown-2.14/mybinutils-2.1...

I finally dug out my PS2 to test what I told. The poor beast had been off since last June... My silly stupid program is: #include <stdio.h> int main&#40;int argc, const char *argv&#91;&#93;&#41; &#123; fprintf&#40;stderr, "Was here\n"&#41;; return 1; &#125; ...

Saotome wrote:but maybe anyone knows if i can download the instruction set reference somewhere?

I know you won't like my answer, but the only easy legal way to get it is to buy the Linux kit.

Yes, but -mabi won't fix the problem with missing instructions, only -mips3 and -mcpu will. IIRC you already documented that in your PS2 binutlis release. -mabi only deals with calling conventions. -mabi does not only change the calling convention, it seems to also change gp_rel stuff, wich makes m...