GPU in main, SCIENCE!

[Atari_Owl]

 

A good example to highlight the misleading nature of the MIPS claim might be to add one binary coded decimal number to a second. The 68k's ABCD instruction vs a GPU implementation. Have the GPU do that and compare how many instructions it takes vs the 68k. Now see why MIPS is often referred to as "Meaningless Indication of Processor Speed" and not something we can use to prove anything one way or the other.

 

So now you can see you also have to consider that the path from A to Z using the 68k might be a very different path using the GPU or DSP and doing so might mean you're working in a completely arbitrary and unproductive way due to the inherent nature of the processor and how it does its thing... comparing even direct like-for-like implementations of the same routines could be unfair as one might not be practical or lend itself to the task (it works both ways).

And after all that... here's what Owl also said:

 

 

It. Depends. Same old story as any other aspect of programming. You do what makes sense based on any number of factors. It's not a binary question, not a matter of right and wrong, clever and lame, productive and lazy...

 

 

I dont think its fair to suggest i was trying to be misleading. That most certainly was not my intention.

 

As we discussed on my blog, the MIPS comparison is not perfect,by their nature instructions on a CISC are intended to do more than a RISC. So yes your ABCD example falls on one side of the discussion. However on the other side, SOME RISC instructions are MASSIVELY more efficient than some CISC instructions, in division for example. In order for a perfect comparisoon you would have to compare so many real life examples it would take so long as to be pointless.

 

As i said it all depends. There CAN be a benefit to GPU in main, but also sometimes there is not.

 

I think it is just as wrong to dismiss the method as it would be to suggest it as a cure all.

 

 

It's just there, a curiosity that CAN be useful... sometimes.

[+Gemintronic]

Thanks for clearing things up Atari_Owl! For homebrewers having to re-discover what the machine can and cannot do your work is invaluable. It's hard to imagine a system with so many possible stategies to use (besides the Sega Saturn).

[Otto1980]

It's just there, a curiosity that CAN be useful... sometimes.

 

and is your project still there?

[Atari_Owl]

 

and is your project still there?

 

Haven't decided.

Not the most pressing thing on my mind.

[OldSchoolRetroGamer]

[+Stephen]

Hi Remo. You seem to really dislike the whole idea of the GPU in Main thing. You certainly are very vocal about it. However 'Panacea' is not really what anyone is talking about and yet you keep throwing that out there. What has been said is that for 3D it will HELP the Jaguar do better at that. Not make it a PSX, or an N64, but help it to do better than what we've seen.

 

 

Your last sentence, even from my limited technical knowledge just seems to be totally disregarding every proponents argument for it. Never really addressing anything just keep saying the same statement over and over. Can you break down anything that has been said previously by AtariOwl or Gorf and disprove it? Not for what Typo was doing but for actual 3D stuff?

I'm more inclined to believe someone's actual coded benchmarks (on real hardware) with source code provided, that rely on what other people said they did. When I am coding (which I do fill-time) I do not rely on what someone tells me they think will speed up my stuff. I try various ways and prove it.

[JagChris]

Sounds absolutely reasonable. Love or hate the GPU in Main or whatever, its out there I guess for everyone to try and find out what's going on one way or the other. Another option! Can't have too many opions.

 

I'm more inclined to believe someone's actual coded benchmarks (on real hardware) with source code provided, that rely on what other people said they did. When I am coding (which I do fill-time) I do not rely on what someone tells me they think will speed up my stuff. I try various ways and prove it.

[Stephen Moss]

It seems to me that every time this comes up there seems to be one group advocating running GPU in main and one against however I would think that use of one method or the other is not an absolute, reality is probably somewhere in the middle, i.e. there may be times when running GPU in main and turning the 68000 on/off are beneficial and times when it is not. I doubt Atari Owl or Gorf would be using that method if it was not advantageous for them to do so for their specific projects, at least they have put information on how to do out there if you choose to do it.

 

As far as Jag programming goes reading controllers is about as far as I have got so I have no idea of how useful a test Linkovitch's test is, however it is not unknown for test A to prove in favour of one thing and test B to show the opposite results and so while the results are interesting could they be considered conclusive?

[LinkoVitch]

I am by no means saying it has no use, just that the use of it is limited. I would say it is possible to run 100% of your GPU code in main for all projects, however this may require a substantial amount of work to achieve, it is therefore likely that whilst the majority of code can be happily ran in Local, there will be times when it's simply more beneficial (from a development/timescale perspective) to simply shut down the 68K and have the GPU run some code out in main.

 

What my experiment shows is the performance impact of running the GPU in main RAM vs running it in Local RAM, nothing more. AtariOwl has done his own tests I believe proving that GPU in main is faster than running the 68K. So if you have code that would cause significant effort to fit into Local RAM on the GPU, performing that task with GPU in main would be faster than performing that task with the 68K.

 

I am sure with your electronics background you can theorize the same as my results by considering the difference of the GPU running from 100-120ns speed DRAM vs it running over a local bus from SRAM (I'd guess around 5-10ns in speed? not sure). My tests simply prove a reduction in command execution for the GPU when it runs from main RAM.

 

HTH

[JagChris]

That is what they have been saying all along.

 

It seems to me that every time this comes up there seems to be one group advocating running GPU in main and one against however I would think that use of one method or the other is not an absolute, reality is probably somewhere in the middle, i.e. there may be times when running GPU in main and turning the 68000 on/off are beneficial and times when it is not. I doubt Atari Owl or Gorf would be using that method if it was not advantageous for them to do so for their specific projects, at least they have put information on how to do out there if you choose to do it.

[GT Turbo]

SCPCD know the answer, he know everything about hardware and timing on the Jag.

 

 

That's the F.ACT.s (

)

[+CyranoJ]

Try BCD math

 

performing that task with GPU in main would be faster than performing that task with the 68K.

 

 

[JagChris]

I think I may be seeing where some of the confusion may be coming from. Its the actual phrase 'GPU in Main' in reference to the bug workaround for this problem. The term GPU in Main was not meant to imply to run EVERYTHING out in the slower main memory. Only that which is appropriate such as the non-time critical stuff. Nor is anyone saying that its a cure all. Only another option programmers have to try to get the most out of the machine.

 

I think I read someone implying I said this workaround doubled performance, or framerates or some such. I never said that either. A couple of the programmers here who work with large programs and usually in 3D seem to indicate they feel they got a significant performance boost by using this technique as compared to the old way. How significant? I don't know. Significant enough that they seemed to feel it was worth the extra work to implement it.

 

I am by no means saying it has no use, just that the use of it is limited. I would say it is possible to run 100% of your GPU code in main for all projects, however this may require a substantial amount of work to achieve, it is therefore likely that whilst the majority of code can be happily ran in Local, there will be times when it's simply more beneficial (from a development/timescale perspective) to simply shut down the 68K and have the GPU run some code out in main.

 

What my experiment shows is the performance impact of running the GPU in main RAM vs running it in Local RAM, nothing more. AtariOwl has done his own tests I believe proving that GPU in main is faster than running the 68K. So if you have code that would cause significant effort to fit into Local RAM on the GPU, performing that task with GPU in main would be faster than performing that task with the 68K.

 

I am sure with your electronics background you can theorize the same as my results by considering the difference of the GPU running from 100-120ns speed DRAM vs it running over a local bus from SRAM (I'd guess around 5-10ns in speed? not sure). My tests simply prove a reduction in command execution for the GPU when it runs from main RAM.

 

HTH

[sh3-rg]

Don't make me fetch a gif...

[LinkoVitch]

I think I may be seeing where some of the confusion may be coming from. Its the actual phrase 'GPU in Main' in reference to the bug workaround for this problem. The term GPU in Main was not meant to imply to run EVERYTHING out in the slower main memory. Only that which is appropriate such as the non-time critical stuff. Nor is anyone saying that its a cure all. Only another option programmers have to try to get the most out of the machine.

 

I think I read someone implying I said this workaround doubled performance, or framerates or some such. I never said that either. A couple of the programmers here who work with large programs and usually in 3D seem to indicate they feel they got a significant performance boost by using this technique as compared to the old way. How significant? I don't know. Significant enough that they seemed to feel it was worth the extra work to implement it.

 

 

The 1st thing you say pretty much contradicts or undermines the 2nd thing you say JC.

 

What is this 'old way' you allude to? As has been stated here, this isn't a speed increase for 3D, it's a potential speed improvement IF it is used to remove 68K from the system performing some tasks, in specific circumstances. You seem to be confusing yourself and what is being discussed, it's merits and drawbacks. Simply saying 'improvements for large 3D code' isn't valid. It may have been used in these situations, but it is by no means related to them being 3D.

 

My experiment wasn't even related to what they have used it for, more to ideally help people see the impact to GPU performance by running it in main vs Local ram. There is an impact, this is irrefutable, this is what the experiment was intended to show. This does not mean that it should never be done, just avoided IF POSSIBLE.

[JagChris]

 

The 1st thing you say pretty much contradicts or undermines the 2nd thing you say JC.

 

What is this 'old way' you allude to? As has been stated here, this isn't a speed increase for 3D, it's a potential speed improvement IF it is used to remove 68K from the system performing some tasks, in specific circumstances. You seem to be confusing yourself and what is being discussed, it's merits and drawbacks. Simply saying 'improvements for large 3D code' isn't valid. It may have been used in these situations, but it is by no means related to them being 3D.

 

You seem to be confused about what I said. I said the programmers who feel they got a big enough benefit from using this technique seem to be working in 3D with large programs. That is what they seem to be using it for. I can't really help that. Talk to them about it.

[sh3-rg]

That is what they seem to be using it for. I can't really help that. Talk to them about it.

 

You seem to be confused. Full. Stop.

 

Who is interested in what you think Gorf and Owl did and why they did it when you don't even understand what they did or why they did it? What's the point keep hammering on? Do you think you are doing them or anyone else any favours flailing around in the dark?

 

Whoever shoved those energizers up your arse when it comes to GPU in main, well, they've got a lot to answer for...

 

http://www.youtube.com/watch?v=w-Ib4FICSSY

 

Maybe we should ask some stuffed toy rabbit for their opinion on GPU in main, I feel we've not quite reached the pinnacle of farcical ludicrousness.

 

tl;dr:

 

stahp.gif

[+Gemintronic]

 

Maybe we should ask some stuffed toy rabbit for their opinion on GPU in main, I feel we've not quite reached the pinnacle of farcical ludicrousness.

 

tl;dr:

 

stahp.gif

 

Indeed! JERRY IN MAIN!!!11!1!

 

8k Internal cache. I'm quite sure the DACs could be subverted to accelerate 3D calculations. Think about it hard: I didn't.

[Otto1980]

Linko i found it very interesting, would love see more such "bench" stuff

 

greetings

[+remowilliams]

 

You seem to be confused about what I said. I said the programmers who feel they got a big enough benefit from using this technique seem to be working in 3D with large programs. That is what they seem to be using it for. I can't really help that. Talk to them about it.

 

 

I kindly suggest you either start to develop an in depth understanding of the Jaguar's hardware, or let the folks who know what they are doing and why they do it continue the conversation if they wish.

 

You aren't doing yourself any favors by repeatedly bringing this up without having any of the required knowledge, and then proceeding to stumble around and resorting to saying 'ask them why'

[JagChris]

The reasons for what they did and why they claim they did it they keep saying over and over. And you guys ignore it.

 

The reason I like debating it is because the basic concepts ARE easy to understand. You guys keep jumping on anyone who comes in here new who asks about the performance potential of the Jaguar. The discussion that started this I wasn't even involved in then someone from your camp started screaming about GPU in Main! NOOOOOOOOO!!! when no one even mentioned it.Because how dare someone want to do something different on the Jaguar or dream bigger than what you guys are doing. And since Gorf is no longer here to defend himself, and AO is hardly ever here I figured what the hell, I'll bite. Sounds like fun. And all this goes for you too Remo.

 

And no am not confused SH3. Confusing the readers of this thread is your job. You'll make a good politician someday if you're not one already.

[LinkoVitch]

The reasons for what they did and why they claim they did it they keep saying over and over. And you guys ignore it.

 

The reason I like debating it is because the basic concepts ARE easy to understand. You guys keep jumping on anyone who comes in here new who asks about the performance potential of the Jaguar. The discussion that started this I wasn't even involved in then someone from your camp started screaming about GPU in Main! NOOOOOOOOO!!! when no one even mentioned it.Because how dare someone want to do something different on the Jaguar or dream bigger than what you guys are doing. And since Gorf is no longer here to defend himself, and AO is hardly ever here I figured what the hell, I'll bite. Sounds like fun. And all this goes for you too Remo.

 

And no am not confused SH3. Confusing the readers of this thread is your job. You'll make a good politician someday if you're not one already.

 

 

NO! No one is ignoring what has been said, you also HAVE NOT said what they have done, only "They have used GPU in main in their 3D projects for a reason" you DON'T KNOW what they have done from the sound of it, nor does it sound like you understand what the hell you are going on about. You keep claiming that you are debating or discussing but all you are doing is re-itterating your own lack of understanding of what others have said they have done (with no detail). No one is doubting that AO or even that Gorf has used GPU in main to their benefit for their particular situation.

 

Why does Gorf need to be here to defend himself? where is he being attacked? GPU in main is NOT Gorf nor is it AO! It's a a bloody quirk of the Jaguar that should of worked, but didn't quite and can be persuaded into working if you are careful. Please stop jumping to the defense of people that are not being attacked and muddying the waters. If you don't fully grasp what is being discussed, why not ASK! I started this thread with the hopes of spreading some knowledge, well done in seemingly trying to drag it down into pointless nay saying of facts and obfuscation!

 

There are more than just 2 people who know how to write code, I'd count myself as one of them, I'd say I have more than a basic understanding of computers to the lowest level (and a BSc in Computer Science with Honours to back that up) please stop assuming I don't have a clue and am fumbling around rocking my world with amazing personal breakthroughs when in fact I am actually trying to help people's understanding of topics (dunno why, but I do actually prefer to help out rather than not!).

 

So can we stick to constructive useful discussions please.. thanks.

[GroovyBee]

The reason I like debating it is because the basic concepts ARE easy to understand.

They sure are. When you have a pipelined architecture (like the GPU) consisting of Fetch, Decode, Execute and Write back phases and the Fetch phase (e.g. the act of getting instructions from main RAM) runs at approximately 1/10 of the speed of local RAM then it doesn't matter that the rest of the phases in the pipeline run at one 26MHz tick because the Fetch phase eats nearly all the time for the operation of the instruction you want to execute.

[+CyranoJ]

A bit like an F1 car in a plowed field.

 

Get 'orf my land!

[JagChris]

 

 

NO! No one is ignoring what has been said, you also HAVE NOT said what they have done, only "They have used GPU in main in their 3D projects for a reason" you DON'T KNOW what they have done from the sound of it, nor does it sound like you understand what the hell you are going on about. You keep claiming that you are debating or discussing but all you are doing is re-itterating your own lack of understanding of what others have said they have done (with no detail). No one is doubting that AO or even that Gorf has used GPU in main to their benefit for their particular situation.

 

Why does Gorf need to be here to defend himself? where is he being attacked? GPU in main is NOT Gorf nor is it AO! It's a a bloody quirk of the Jaguar that should of worked, but didn't quite and can be persuaded into working if you are careful. Please stop jumping to the defense of people that are not being attacked and muddying the waters. If you don't fully grasp what is being discussed, why not ASK! I started this thread with the hopes of spreading some knowledge, well done in seemingly trying to drag it down into pointless nay saying of facts and obfuscation!

 

There are more than just 2 people who know how to write code, I'd count myself as one of them, I'd say I have more than a basic understanding of computers to the lowest level (and a BSc in Computer Science with Honours to back that up) please stop assuming I don't have a clue and am fumbling around rocking my world with amazing personal breakthroughs when in fact I am actually trying to help people's understanding of topics (dunno why, but I do actually prefer to help out rather than not!).

 

So can we stick to constructive useful discussions please.. thanks.

 

Here is an example:

 

 

The problem with the Atari renderer that is in source

form is that it is loaded with a lot of 68k code. Not only that, the renderer itself is poorly written in the fact that it not

only uses 16 bit values to work with, but it also uses the matrix instuctions and that it was written to draw one model

at a time as opposed to building a list of polygons to rip through, as it should. So for every model you want to draw per

frame, it processes each one through all the set up....very inefficient. A good renderer would consider ALL models per

frame, build a list of polies and then render them using 32 bit values and instead of the matrix multiply instructions which

take WAY too much setup, he should use the MAC instructions which would better handle 32 bit values. Something the

MMULT instruction can't do.

 

Wht Scott (JagMod) did to speed up the renderer is get rid of the 68k code all together, eliminate all the blits of the code

to GPU local and put them in to one big chunk. The other issue with the Atari renderer is it has the GPU stop completely

while the blitter keeps loading in vertices to the RAM. What should be happening is that the verts should be out in main

and keep the GPU running at all times. OR use a small portion of the local to have the blitter move the verts to WHILE

the GPU is constanly processing them or at least doing something else while waiting for the blitter to load the next set.

 

A big problem besides the 68k running way too much is the fact that the GPU is constantly waiting in a tight loop for the

blitter to finish moving the data.....a ton of wasted cycles right there. JagMod had a small sample code where the GPU

never stops working and got well over 80,000 blits PER FRAME using this method. This was a first attempt too.

 

I maintain that we have not seen anywhere near the true ability of the Jaguar's 3D capabilities just based on these serious

flaws of coding inefficiencies. Just about every game uses this piss poor method of GPU waiting and over use of the 68k.

 

Those concepts are NOT HARD to understand. Not one bit. Don't need any kind of bachelor of science degree to understand that. Thats the thing about Steve is he was a genius who was a good teacher though at times was batshit crazy.

 

They sure are. When you have a pipelined architecture (like the GPU) consisting of Fetch, Decode, Execute and Write back phases and the Fetch phase (e.g. the act of getting instructions from main RAM) runs at approximately 1/10 of the speed of local RAM then it doesn't matter that the rest of the phases in the pipeline run at one 26MHz tick because the Fetch phase eats nearly all the time for the operation of the instruction you want to execute.

 

So if you have a large program that you have to put everything into the GPU local, and keep swapping stuff out? How much time does that eat up? Is that not the heart of the matter? Those who are proponents of it claim that in some instances the swapping eats up that speed difference real quick.

Edited March 4, 2014 by JagChris