My first thesis was on GPGPU - "General Purpose computation on Graphical Processing Units" - i.e. the answer to the question:
<< How could I trick a Graphical Processor and make it think it is computing Doom 3's reflection while actually it is accelerating serious computations (not necessarly related to graphics...) ????>>
Three years ago using GPU to speed up arbitrary (parallelizable) computations in SIMD fashion was little more than a nerd's game...today it is lagely used (and is leading to the use physical processors). I tryed to search for "gpgpu psp" and found nothing. So my question is "Is PSP's GPU suitable for GPGPU??" This translates into:
1) Does PSP's GPU own something like a _programmable_ pixel/vertex shader?
2) Can we instruct PSP's GPU to render into an hidden buffer?
Luckyly, the second question is quickly answered by the pspsdk itself 'cause renderTarget demo is doing exactly this.
Ideas for the first question??
jean
GPGPU on PSP
http://forums.ps2dev.org/viewtopic.php?t=8796 - a good example of the psp gu power.
00000110 00000110 00000110
GPUs are highly optimized to do SIMD (Single Instruction on Multiple Data) stuff. If you can achieve a good parallelism between CPU and GPU (i.e. if you can feed GPU with non-blocking calls) then the trick helps even if GPU is slower than CPU since CPU has ALWAYS better things to do... If we cannot program the GPU's pipeline, things are harder but something can be done anyway. To be more explicit, in homebrew (that currently are not using GPU extensively), even without pipeline programmability one could still use blending features to sum/subtract/multiply/divide huge matrices (as big as a texture can be) and hence improve response time of -for instance- correlation and transformation algorithms (i.e.:faster OCR, realtime voice recognition, etc...) without stressing CPU that's still free for other tasks (as interpretation of so retrieved data)...as usual, maybe this would be clearer with a demo. I will try to do something demonstrative as soon as i get some free time :)I'm not even sure that's fast enough to justify doing it there
jean
No
The PS2 had the closest thing to GPGPU of it time, and it wasn't really the GPU but rather the outboard VPU's (vector processors) that fed the GPU. But it worked on the same principle as todays programmable pixel engines and shaders - SIMD.
Regardless, the computing power is not there in either system (PS2 or PSP) to remotely do anything comparable to today's high end GPU's.
Now the GPU in the PS3, THAT would be a GPGPU monster, especially in conjunction with the SPU's, if only we could get at it. With the work being pioneered by those in the PS3 forums, that may happen eventually.
www.gpgpu.org is a good resource for gpgpu kinda things.
Also, the Nvidia book GPU GEMS 2 contains extremely good introductions.
Regardless, the computing power is not there in either system (PS2 or PSP) to remotely do anything comparable to today's high end GPU's.
Now the GPU in the PS3, THAT would be a GPGPU monster, especially in conjunction with the SPU's, if only we could get at it. With the work being pioneered by those in the PS3 forums, that may happen eventually.
www.gpgpu.org is a good resource for gpgpu kinda things.
Also, the Nvidia book GPU GEMS 2 contains extremely good introductions.
I'm not disagreeing on GPGPU - believe me, I've done work with it myself. I'm strictly talking in the context of the PSPs graphics engine - you'd be much better off writing something for the ME (2nd processor).jean wrote:GPUs are highly optimized to do SIMD (Single Instruction on Multiple Data) stuff. yadda yadda
@adrahil
@gauri
Be sure, i know what i'm saying...if this whole thing cannot be done (or simply cannot give benefits...), it will surely be for some hardware specific issue. I haven't just implemented something on PSP 'cause i barely got the time to write something on this forum every now and then by now, but i liked to explain the idea to the community, seen all the robotic-related works appearing. If you don't like it, then i'm sorry...
I thought I wasn't clear as i would in my previous posts, but please read what someone writes before reply (sorry, i don't mean to be unpleansant, but i'm sick of it)
Render-to-texture is a way to "draw" without display anything. I've not tryed this way mayself, but i think that a glance at the pspsdk example is enough to tell this can be done!Oh and all that of course without any display - since GE kind of is one of the only ways to access the display :)
No, my friend, i'm not looking for WEP cracking, since this would be better done by batch processing...in this case i bet the real challenge is to get the raw data...anyway, i'm looking for EXACTLY what i said.TBH, I don't think you're talking about OCR or TTS... You're probably aiming at WEP&co :) Just forget it.
@gauri
Again, i must repeat myself:jean, I do not see any way to perform general purpose calculations on the fixed-function pipeline.
It's not really general purpose, but it can often help.even without pipeline programmability one could still use blending features to sum/subtract/multiply/divide huge matrices (as big as a texture can be)
Be sure, i know what i'm saying...if this whole thing cannot be done (or simply cannot give benefits...), it will surely be for some hardware specific issue. I haven't just implemented something on PSP 'cause i barely got the time to write something on this forum every now and then by now, but i liked to explain the idea to the community, seen all the robotic-related works appearing. If you don't like it, then i'm sorry...
I thought I wasn't clear as i would in my previous posts, but please read what someone writes before reply (sorry, i don't mean to be unpleansant, but i'm sick of it)
So you already know the answer then!jean wrote:Again, i must repeat myself:It's not really general purpose, but it can often help.even without pipeline programmability one could still use blending features to sum/subtract/multiply/divide huge matrices (as big as a texture can be)
If all you need is the simple multiply-add operations performed by the blending unit, and 8 bits of precision are enough for you, then by all means go wild with all the "GP"GPU number crunching you can squeeze out of the PSP.
:)ufoz wrote:So you already know the answer then!jean wrote:Again, i must repeat myself:It's not really general purpose, but it can often help.even without pipeline programmability one could still use blending features to sum/subtract/multiply/divide huge matrices (as big as a texture can be)
If all you need is the simple multiply-add operations performed by the blending unit, and 8 bits of precision are enough for you, then by all means go wild with all the "GP"GPU number crunching you can squeeze out of the PSP.
I was about to say the same thing myself. Can anyone think of something this would be good for ON THE PSP? GPGPU for a general purpose computer is AWESOME! GPGPU on a limited handheld? Sorry, people don't need weather forecasting software or software to model nuclear warheads on the PSP.
Part of being a developer is having realistic goals and expectations about the platform you're working on. Wanting GPGPU apps on the PSP is akin to wanting an XBox 360 emulator - it ain't gonna happen.
What's the problem mr smart man? Do YOU are a REAL developer? Do YOU have a realistic goal? Then go for it! (and don't annoy me: all of your replies to me are simply pointless)
GPGPU _IS NOT_ something you CAN do ONLY if you have beefy hardware, BUT a trick to speed up things when you DON'T HAVE IT.
I would have never told that giving an advice to people who are in the position to turn it in practice could take to a rain of sarchastic posts like "it's not gonna happen" from people who demonstrated that they definitely DON'T KNOW what they are speaking of.
IF someone of you where minimally aware of what i'm saying, then he would have told me something technical about the GU_TCC_RGB constant as a parameter to sceGuTexFunc, the ONLY wrong thing i see to implement something good and that forces me to 8bit only. I expected people talking about GU_PSM_T16 and GU_PSM_T32 formats, or sceGuDrawBuffer... and not merely showing their posts-count. So, if someone is really interested in an open dialog, then PM me, as i see good ideas are not wellcome here.
GPGPU _IS NOT_ something you CAN do ONLY if you have beefy hardware, BUT a trick to speed up things when you DON'T HAVE IT.
I would have never told that giving an advice to people who are in the position to turn it in practice could take to a rain of sarchastic posts like "it's not gonna happen" from people who demonstrated that they definitely DON'T KNOW what they are speaking of.
IF someone of you where minimally aware of what i'm saying, then he would have told me something technical about the GU_TCC_RGB constant as a parameter to sceGuTexFunc, the ONLY wrong thing i see to implement something good and that forces me to 8bit only. I expected people talking about GU_PSM_T16 and GU_PSM_T32 formats, or sceGuDrawBuffer... and not merely showing their posts-count. So, if someone is really interested in an open dialog, then PM me, as i see good ideas are not wellcome here.
Im not trying to be smart or anything but why not demonstrate what you are trying to achieve in an application of your own to prove your theory, meaning try to get something going like checking if the psp has a programmable pixel / vertex shader or trying to instruct PSP's GU to render into the hidden buffer.jean wrote:What's the problem mr smart man? Do YOU are a REAL developer? Do YOU have a realistic goal? Then go for it! (and don't annoy me: all of your replies to me are simply pointless)
GPGPU _IS NOT_ something you CAN do ONLY if you have beefy hardware, BUT a trick to speed up things when you DON'T HAVE IT.
I would have never told that giving an advice to people who are in the position to turn it in practice could take to a rain of sarchastic posts like "it's not gonna happen" from people who demonstrated that they definitely DON'T KNOW what they are speaking of.
IF someone of you where minimally aware of what i'm saying, then he would have told me something technical about the GU_TCC_RGB constant as a parameter to sceGuTexFunc, the ONLY wrong thing i see to implement something good and that forces me to 8bit only. I expected people talking about GU_PSM_T16 and GU_PSM_T32 formats, or sceGuDrawBuffer... and not merely showing their posts-count. So, if someone is really interested in an open dialog, then PM me, as i see good ideas are not wellcome here.
It'd help some people out a lot here.. Not everyone is right and not everyone has time for things like this.
@wally
Finally a person I can talk with! Thanks for your care.
I wished to write a demo, but my time was sooo small...so i gave my idea to the community...who didn't appreciate it. After all, the criticisms had the effect to push me into the challenge and try to code something.
Let's do this way: i'll bet a beer.
If someone can help me figure out how i can draw 16bit textures on 16bit textures (obviously in hw accel.) avoiding the sum-and-saturate effect on the components (does something like GU_TCC_SINGLECOMPONENT exists?), THEN i will prove usefulness of the system OR i will pay a beer to all the criticists (of course they have to come visiting me in my country to have their beers).
take it easy....
jean
Finally a person I can talk with! Thanks for your care.
I wished to write a demo, but my time was sooo small...so i gave my idea to the community...who didn't appreciate it. After all, the criticisms had the effect to push me into the challenge and try to code something.
Let's do this way: i'll bet a beer.
If someone can help me figure out how i can draw 16bit textures on 16bit textures (obviously in hw accel.) avoiding the sum-and-saturate effect on the components (does something like GU_TCC_SINGLECOMPONENT exists?), THEN i will prove usefulness of the system OR i will pay a beer to all the criticists (of course they have to come visiting me in my country to have their beers).
take it easy....
jean
He was talking to me, Wally, and generally demonstrating what an ass he is. If he doesn't even know what I've done, he certainly hasn't bothered searching/reading enough threads here to be yammering about anything.
@jean: Put your money where your mouth is - write something USEFUL for the PSP using GPGPU and I'll apologize. As it is, my opinion is based on the fact that using GPGPU on anything less than a nvidia 8000 series card on a beefy PC is worthless. Look at the GPGPU examples currently out - the recommended MINIMUM system is a beefy PC with TONS of memory and at least a 7000 series nvidia. The PSP doesn't even come close to those specs.
@jean: Put your money where your mouth is - write something USEFUL for the PSP using GPGPU and I'll apologize. As it is, my opinion is based on the fact that using GPGPU on anything less than a nvidia 8000 series card on a beefy PC is worthless. Look at the GPGPU examples currently out - the recommended MINIMUM system is a beefy PC with TONS of memory and at least a 7000 series nvidia. The PSP doesn't even come close to those specs.
Look poeple!! Mr macho-man is back!! If it can make you feel better i can post 1193 bullshits on this forum...after that will you treat me with a little respect?? This is surely maturity!!...demonstrating what an ass he is...
I could tell you you're a complete idiot, and that some of the GPGPU demos you have tried (if you really had) could be MINE, but i will not...please don't ever contact me again.Look at the GPGPU examples currently out
A serious user of this forum has told me -by PM- what i needed: so
I think this thread can be locked to avoid personal flames.
Drama, if it continues the thread will be locked, and maybe hall of shamed depending how hilarious it is.
'GPGPU' sounds fun on PSP, I did some on PS2 for interpolation of some 8bit values and it was incredibly fast, but I never found a way to work it into my pipeline nicely.
I think to most people actually doing 'GPGPU' stuff the 'General Purpose' bit just means non-graphics, or at least non-raster-output stuff, and not that you can use it for anything under the sun...
Clearly any GPU that can render to non-onscreen RAM can be used to do things other than rasterising triangles, blitting sprites, etc and may be lots faster than a CPU at doing certain (very specific things).
Feel free to continue this thread in a constructive manner...
'GPGPU' sounds fun on PSP, I did some on PS2 for interpolation of some 8bit values and it was incredibly fast, but I never found a way to work it into my pipeline nicely.
I think to most people actually doing 'GPGPU' stuff the 'General Purpose' bit just means non-graphics, or at least non-raster-output stuff, and not that you can use it for anything under the sun...
Clearly any GPU that can render to non-onscreen RAM can be used to do things other than rasterising triangles, blitting sprites, etc and may be lots faster than a CPU at doing certain (very specific things).
Feel free to continue this thread in a constructive manner...
-
tacoSunday
- Posts: 34
- Joined: Fri Aug 31, 2007 10:05 pm
How can you claim that J.F.'s 1193 posts are bullshit? Have you read any of them? I can tell you that I have. J.F. is about as far from bullshit as you can get. His posts have helped me and many others on this forum countless times. If you don't like the atmosphere then please go elsewhere. This is surely maturity.Look poeple!! Mr macho-man is back!! If it can make you feel better i can post 1193 bullshits on this forum...after that will you treat me with a little respect?? This is surely maturity!!
-
tacoSunday
- Posts: 34
- Joined: Fri Aug 31, 2007 10:05 pm
----------------
if you're not interested in anything else than PSP-programming-related arguments, please skip until the more constructive argument.
----------------
Ok, now that i'm more relaxed i can say that probably I don't know who JF is or all the wonderful things he's doing, but he doesn't know me as well, and since his first reply to me, he's doing everything to annoy me, saying nothing technical and boasting of his superiority (and I suspect that's because i'm a newbie on this forum). But, i am everything but a newbie in computer science, and expected more maturity from such an old member, if not availability like that showed by Art, Raphael, Tyranid and all the other nice people i'm talking with.
Ok, ok, I will stop it now. I'll try not to indulge in personal attacks never again, and i think i would look like a nicer person if I apologized to everyone is here to discuss PSP related arguments, included JF to whom i say "please let's cease ostilities"...if you have something interesting to say i'm open, and if you're not sure about my ability as a developer, then feel free to contact me, but please don't continue filling my topics with "If you searched../if you were a real developer.../if you were as good as me/ etc...", mainly if you're not sure of your skills in the task (being obviously assured those you showed in other fields).
I unluckyly found (from Raphael) that GPGPU on PSP is bound to 8 bit (like JF said) because of the PSM_ formats being RGB, RGBA or indexed only. As far as i know, there is lack of a two 16bit components or single 32bit component texture format. Hence i tried to work around indexed formats, but it seems that none of them can be used as a rendering target (my screen turned black), and in addition blending operation in such a situation would be very unpredictable to me... If when we set blending mode for the texturing unit we had something else than GU_TCC_RGB and GU_TCC_RGBA then we could instruct to sum-and-saturate -for instance- two 16 bit values instead of 4 8bit ones. So the result is that unless it turns out that other color-blending modes are available (GU sources leave very little hope for this, since there is no space between currently well known commands to even send the configuration values as commands to GE) we have to do fast computations on more-than-8-bit-values in other ways. At least now i know WHY. I was suggested by ufoz to try ME. Currently i'm investigating, searching the forum, but if someone has some advices on ME usage, they're wellcome.
if you're not interested in anything else than PSP-programming-related arguments, please skip until the more constructive argument.
----------------
Thank you jBit, that was EXACTLY what i wanted to make everyone understand.'GPGPU' sounds fun on PSP, I did some on PS2 for interpolation of some 8bit values and it was incredibly fast, but I never found a way to work it into my pipeline nicely.
I think to most people actually doing 'GPGPU' stuff the 'General Purpose' bit just means non-graphics, or at least non-raster-output stuff, and not that you can use it for anything under the sun...
Clearly any GPU that can render to non-onscreen RAM can be used to do things other than rasterising triangles, blitting sprites, etc and may be lots faster than a CPU at doing certain (very specific) things.
Yes, I did...maybe some of them are fine... unluckyly none of them are replies to me.How can you claim that J.F.'s 1193 posts are bullshit? Have you read any of them?
Ok, now that i'm more relaxed i can say that probably I don't know who JF is or all the wonderful things he's doing, but he doesn't know me as well, and since his first reply to me, he's doing everything to annoy me, saying nothing technical and boasting of his superiority (and I suspect that's because i'm a newbie on this forum). But, i am everything but a newbie in computer science, and expected more maturity from such an old member, if not availability like that showed by Art, Raphael, Tyranid and all the other nice people i'm talking with.
Ok, ok, I will stop it now. I'll try not to indulge in personal attacks never again, and i think i would look like a nicer person if I apologized to everyone is here to discuss PSP related arguments, included JF to whom i say "please let's cease ostilities"...if you have something interesting to say i'm open, and if you're not sure about my ability as a developer, then feel free to contact me, but please don't continue filling my topics with "If you searched../if you were a real developer.../if you were as good as me/ etc...", mainly if you're not sure of your skills in the task (being obviously assured those you showed in other fields).
NOW let's swap to a more constructive argument:Feel free to continue this thread in a constructive manner...
I unluckyly found (from Raphael) that GPGPU on PSP is bound to 8 bit (like JF said) because of the PSM_ formats being RGB, RGBA or indexed only. As far as i know, there is lack of a two 16bit components or single 32bit component texture format. Hence i tried to work around indexed formats, but it seems that none of them can be used as a rendering target (my screen turned black), and in addition blending operation in such a situation would be very unpredictable to me... If when we set blending mode for the texturing unit we had something else than GU_TCC_RGB and GU_TCC_RGBA then we could instruct to sum-and-saturate -for instance- two 16 bit values instead of 4 8bit ones. So the result is that unless it turns out that other color-blending modes are available (GU sources leave very little hope for this, since there is no space between currently well known commands to even send the configuration values as commands to GE) we have to do fast computations on more-than-8-bit-values in other ways. At least now i know WHY. I was suggested by ufoz to try ME. Currently i'm investigating, searching the forum, but if someone has some advices on ME usage, they're wellcome.