Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Ravyne

Member Since 26 Feb 2007
Offline Last Active May 02 2015 11:27 AM

#5166323 hyphotetical raw gpu programming

Posted by Ravyne on 11 July 2014 - 05:50 PM

Here are some good resources to read:

 

Background: How GPUs work

 

Midgard Architecture Explored




#5166321 hyphotetical raw gpu programming

Posted by Ravyne on 11 July 2014 - 05:39 PM

You guys are wayyy over my head with this stuff.  I'm kinda with fir on this; I only have a vague notion of what a GPU does, but I figure it's like he says, a vast array of memory as data input, a similar vast array as output, and a set of processors that read and process instructions from yet another array of memory to transform the input to the output.  Is that not the case?

 

50,000 foot-view? Yes. Think of it like doing CPU assembly -- you write assembly as if you have this idealized x86 processor with a certain number of registers and a certain CISC-like instruction set. That's what you write, that's what gets stored on your hard disk. But when you sent that to the CPU it does all kinds of crazy transformations to it and executes an entirely different, though equivalent, program at the lower levels. If you were to write a GPU program in SPUR or PTX, which is as close to GPU assembly language as it practical, its the same situation except that a) you might be executing on wildely different underlying architectures, and that there are various perf consequences of such, and b) the logical leap between SPUR/PTX and GPU silicon is probably an order of magnitude more removed than between x86 assembly and your CPU silicon.

 

Furthermore, almost nothing on a GPU behaves as a CPU does -- not caching, not branching, not latency, not throughput -- good news though, the same old math works (except when it doesn't :) )

 

 

Do all the processing units always work in lock-step or can they be divided into subgroups each processing a different program on different input sets?

 

Is there a separate processor that divides up the data and feeds it or controls the main array of processors as appropriate?

 

In every programmable GPU I'm aware of, with the exception of ARM's new Midgard and Intel's MIC if we're including it, yes -- there's always lock-step execution. Sticking just to recent architectures, AMD's GCN compute block has 4 16-wide SIMD ALUs (in typical 4-vector code, each would correspond to x, y, z, and w), and there's only one program counter per block, IIRC. This is where my own knowlege starts to get a bit fuzzy unless I'm looking at docs, but the take-away is that you're certainly lock-step with 16 physically, and I think the full 64 ALUs as more of a practical matter.

 

At a higher level, you can put different workloads on different compute blocks, and your GPU has between 4 and ~48 of those. The workloads you send the GPU are meted out to the blocks by a higher-level unit. IIRC, in the past this unit could only handle two workloads at a time, but the most recent GCN cards can handle 8 -- You can think of them a bit like hyperthreads -- mostly the duplication is there so that free compute blocks don't go to waste -- and the workloads themselves are very short-lived, typically. The increase from 2-8 workloads is possibly even a bit premature from a client-code perspective. I think its just precipitating that soon GPUs will be able to issue very-small-grained sub-workloads to themselves -- the workloads that come across the PCIe bus are big enough to not really need more than the two.




#5166318 (Super) Smart Pointer

Posted by Ravyne on 11 July 2014 - 05:00 PM

@Ravyne

 

You mean the target-pointer shouldn't persist between frames, but the unit should decide every frame which one is the current target?

 

It depends -- if you engineer your system to support it, then you can keep it around between frames and possibly use it as an avenue to short-circuit the AI routine ("If my target hasn't been destroyed, just keep attacking it, don't consider other options"). But you're right that you can't keep it if there's no mechanism to identify when an object has been removed from play, and simply deleting that object from memory doesn't cut it. Using weak_ptr would work, but its not a good solution for reasons I'll get into below. Another solution would be for destroyed objects to post a message, and that game entities would subscribe to that message, whereupon they could clear the pointer. Another solution would be to have a system of entity 'slots' that persistently occupy the same memory location, combined with an enemy ID -- you could keep the pointer around between frames, along with its ID, and check whether the slot still corresponds to that ID. Yet another would be to temporarily exist in a destroyed state for some extra frames, so that everyone has a chance to notice its been destroyed (in practice, this can work well as there's often an animation cycle associated with the object or entity being destroyed/killed).

 

Also, although I'm using the word 'pointer' I don't strictly mean a memory address; It could be any kind of handle that resolves to a specific object reliably.

 

 

The trouble OP has is that things become tightly coupled when they interact. The result of this is that it creates this false appearance of ownership semantics -- to be clear, the need for shared ownership semantics in the system OP describes is real, but the ownership is necessitated by the implementation rather than the requirements. Ultimately this is a code-smell.

 

shared_ptr and weak_ptr are quite thin -- thin enough that you should instinctively reach for them when they fulfill your requirements -- but they are not so thin that one should consider using them to compensate for design flaws. Its implementation dependent, but if you ever look into the guts of how share_ptr and make_shared work, you can get yourself into situations in which just one extant weak_ptr (and no extant shared_ptr) disallows a significant block of memory from being freed because the control block is not deallocated until there is no extant weak_ptr (as when make_shared decides to embed the allocation block into the control block for objects up to an implementation-defined size) -- its always the case that the object is deconstructed and that the resources it holds are released when the shared count reaches 0, but its not always the case that the memory for the object itself is freed. I believe its common that this kind of combined control/allocation block can be as large as 32 or 64 bytes, which can add up quickly. Furthermore, use of make_shared (but not share_ptr) necessarily implies that the objects are non-contiguous and can't be used with pooled allocation (because you can't use a custom deleter) which could disallow significant optimizations in other parts of the code.




#5166280 (Super) Smart Pointer

Posted by Ravyne on 11 July 2014 - 01:27 PM

 

shared_ptr doesn't seem to work because that is reference counted.


Or of course simply a weak_ptr.

 

 

shared_ptr and weak_ptr are entirely the wrong mechanisms here -- both express a particular flavor of ownership (potential ownership, in the case of weak_ptr), but the marines discussed here don't 'own' their target. Any pointer they do hold to their current target should be raw (raw pointers are the preferred mechanism for non-owning semantics) and probably const-appropriate; above all, it should be viewed not even as an implementation detail of the AI, but an implementation detail of a particular optimization (e.g. "its likely that the thing I was interested in last frame still interests me.")

 

It sounds to me that the root of OPs problem here is that entities effectively become tightly-coupled when they interact. It sounds like there's direct-dealing between the sides, mediated by some AI/logic processes that are coupled to one or both of the participants. A solution is to move towards having more autonomous agents who make observations about their environment, and then perform some action as a result (possibly spawning a new autonomous agent) that achieves what they want ("fire my gun at my enemy"), but its hands off between the marine and his target.




#5166269 hyphotetical raw gpu programming

Posted by Ravyne on 11 July 2014 - 12:37 PM

It depends very much on the internal architecture -- because GPUs have sort of hidden behind the problem they focus on, the underlying silicon has been changed radically even in just the 10 or so years since they've become really programable -- off the top of my head, you had VLIW from AMD with an issue width of 5 and 4 going back to the HD5x00 and HD6x00 series, single-SIMD-per-core before that, and multiple-SIMD-per-core recently in GCN 1.0, and GCN 1.1/2.0 having the same basic architecture as that but with better integration into the system's memory hierarchy; From nVidia, you've had half-sized, double-pumped cores, single 'cores' with very many relatively-independent ALUs, and most recently (maxwell), which shrunk back the number of ALUs per core.

 

Both companies do expose a kind of assembly language for recent GPUs if you look around for it. It is entirely possible to write assembly programs for the GPU or build a compiler that can target them. But the mapping isn't quite as 1-1 as on, say x86 (even x86 you're only talking to a logical 'model' of an x86 CPU and the actual micro-code execution is more RISC-like).

 

If you branch out from PC and look at mobile GPUs that you find in phones and tablets, then you have tiled architectures too. ARM's latest Mali GPU architecture Midgard is something really unique -- where every small-vector ALU is completely execution-independant of any other -- as a consequence, every pixel could go down a different codepath for no penalty at all which is something no other GPU can do. In a normal GPU the penalty for divergent branches (an 'if' where the condition is true for some pixels and false for others) is proportional to the square of the number of divergent branches in the codepath, which can quickly become severe.

 

Then, you have something similar in intel's MIC platform, which was originally going to be a high-end GPU ~5 years ago. The upcoming incarnation of MIC is Knights Landing, which is up to 72 customized x86-64 processors based on the most recent Silvermont Atom core -- its been customized by having x87 floating point chopped off, each physical core runs 4 hyper-threads, and each physical core has 2 512-bit SIMDs, and its got up to 8 GB of on-package RAM using a 512-bit bus giving ~350GB/s bandwidth.

 

Anyhow, I get talking about cool hardware and I start to ramble :) -- Long story short, yes you can do what you want to do today, but the tricky part is that GPUs just aren't organized like a CPU or even a bunch of CPUs (Midgard is the exception, Knights Landing to a lesser extent) and so you can't just expect it to run CPU-style code well. A big part of making code go fast on a GPU is partitioning the problem into managable, cache-and-divergence-coherent chunks, which tends to either be super-straight forward (easy) or requires you to pull the solution entirely apart and put it back together in a different configuration (hard).




#5165935 Need advice with RPG making

Posted by Ravyne on 09 July 2014 - 08:15 PM

 

Need advice with RPG making


Don't.

You don't have the bandwidth, skill level, team size, money, or time to make an RPG. Those generally take teams of a hundred-plus professional game developers multiple years of full-time-plus work to make.

There's a reason you see so few indie RPGs and the few you do find are almost solely made by established RPG developmers.

 

 

 

Uh...  Markets are overflowing with indie RPGs...

 

I think you have to qualify both of these statements.  The first is very true if you try to compete with the AAA RPGs on content, although this is equally true in most game genres. The second of these statements is true if we're realistic about the scope of indie RPGs.

 

I would say, in general, that rather few 'indie' games provide more than about 10 hours of content unless they're either relying on procedural content, or are particularly well-funded and well-staffed for an "indie" studio. There are a few exceptions, but I'm hard-pressed to think of any who exceed the ~10 hour mark by double or more.

 

OP isn't going to compete with Bard's Tale on content or quality anytime soon -- not alone, or even in a small group; but a similarly styled game with with a more focused scope and reasonable expectations for content polish is doable alone or in a small group, if you have dedication and sufficient time.




#5165918 MIT License in PlayStation Vita Game

Posted by Ravyne on 09 July 2014 - 06:34 PM

And FYI, I'm reasonably certain your worries are unfounded. My own reading of the complete license, in my mind, leaves no question that 'the Software' refers to the source code covered by the license, and not your body of code that integrates it. MIT is widely regarded as one of the more permissive licenses, and also is not a viral license like GNU GPL (that is, *your* software is not required to adopt the same license), But again, IANAL and that does not constitute legal advice.

 

These links appear to back up my understanding of things.

 

Can I use MIT license plugins in my commercial website?

Meaning of MIT license -- StackOverflow

MIT License (Expat)




#5165915 MIT License in PlayStation Vita Game

Posted by Ravyne on 09 July 2014 - 06:23 PM

IANAL, but I too would have thought that the notice clause pertains only to the source code. In this case the truth of the matter appears to hinge on how the license defines "the Software" -- if 'the Software" is the MIT-licensed code, then it just means you can't remove the copyright notice and distribute the source; otherwise, if "the Software" means the completed software you produced that incorporates said MIT-licensed code, then things are as you believe. 

 

If this actually is cause for concern, then both options are good. Is it really the case that your game doesn't have a credits screen or "about" menu item somewhere that you couldn't put the notice without upsetting the client? Would it mean an extra round of certification? If the license demands public notice in the client software I don't think you're going to avoid it -- you either have to obtain a different license, add the notice, or remove the code, and only the first option will save you any churn.




#5165423 Need advice with RPG making

Posted by Ravyne on 07 July 2014 - 07:14 PM

For someone without programming skills, RPG Maker is probably up your alley. Its mostly point and click, and you only have to think of as much programming as you absolutely need to -- even then, it provides most of the programming plumbing that would be easy for a beginner to get wrong or that would just take too much time to do yourself.

 

I'd seriously look into that, and don't let anyone tell you its not real programming. Maybe it is, maybe it isn't -- but its beside the point. Your stated goal is to make the game, not to become a programmer, so it doesn't matter whether anyone thinks you're a real programmer or not. RPG maker is very capable of what you describe, and is the path of least resistance.




#5165345 How do you get ideas for new games?

Posted by Ravyne on 07 July 2014 - 02:12 PM

Its kind of ironic that limitations can be so freeing, but its really obvious once you see it. Having limitations lets you know where the practical boundaries are in clear terms, and keeps the set of things you need to reason about small and nearby so that it can be considered quickly, allowing you to move forward. When the boundaries are vague or too distant, your considerations are too numerous and far-flung to be made quickly or decisively. You end up becoming paralyzed by the unbounded possibilities, and even when you are able to make a decision, you will often be haunted by questioning whether you made the right call, which will sometimes sing you the Siren's Song of re-doing things, negating the forward progress you might have made.




#5165336 So I got another random idea

Posted by Ravyne on 07 July 2014 - 01:41 PM

To be clear, the project seems like a worthwhile pursuit to the ends of growing as a programmer (hey, go implement that recursive solver I mentioned, too!), I just don't think its particularly attractive as gameplay. There'd need to be more to it than just exploring, and I'd also get away from the idea that exploring the maze completely is "winning", you need dead-ends/false-paths/red-herrings to contrast the happy-path, otherwise there's no purpose to what the player is doing.

 

Adding gameplay elements, though, is fairly simple. Some traps, some loot, some dead-ends, some keys/doors, a little back-story, maybe some NPCs and dialog, and suddently you have something that looks a lot more like a game.




#5164482 How do you get ideas for new games?

Posted by Ravyne on 02 July 2014 - 10:11 PM

Yes I want to try making something new to improve my dev skill. Making clone game within the day might be fun but I don't think I want to spent some weeks or months making a clone game


But do you se how that desire can be a little schizophrenic?

What more do you expect to learn from thrashing in the dark at an original idea than you would from, say, making a really polished platformer or puzzle game?

Within genre limits there's still an incredible degree of latitude to reconstruct and innovate their tropes, and to express your design voice. But the benefit of working from that existing framework is that people understand the design language at play, and there are models that you can compare yourself to and look to for inspiration -- you can ask "How does my platformer compare to Super Mario World? How am I different? Better? Worse?" -- something your original idea, cut from whole cloth, does not. Its not that new ideas are impossible to analyze, but amateur designers usually lack the experience and perspective to do so.


#5164478 How do you get ideas for new games?

Posted by Ravyne on 02 July 2014 - 09:52 PM

Instead on relying on your ability to design, it let's your mind wander around about the possibilities of systems that you've already created


Said another way: Embrace limitations as a creative opportunity.

Many amateur designers think that a design that has more stuff or a design that eliminates limitations is necessarily better than those that don't. Limitations, practical or otherwise, are the enemy. But a design that attempts to sidestep all limitations is one which loses all focus. I daresay that if the goal was ever achieved, you couldn't even say it was 'designed' at all, impressive as the result may be.

Besides that, complete freedom to do anything is paralyzing. There's so much that you could do that its hard to be clear about what you should do. Having limits, technical or self-imposed, keeps things near, where they are easier to reason about together, and sometimes by that virtue allows for creative solutions to present themselves, without being passed over for fear of unforeseen circumstances.

Design abhors unnecessary complexity. Limitations naturally curtail it.


#5164427 How do you get ideas for new games?

Posted by Ravyne on 02 July 2014 - 05:05 PM

Lots to consider here.

 

I think the first thing to realize is that design of any kind is not a fire-and-forget process. It doesn't matter what you're designing, a straight line between inspiration and tangible, universally-loved product simply does not exist. The path is twisty, branching, has many dead ends, and often loops back on itself. Those who believe or seek to prove true that there is a straight line are fools. Not only are these 'time wasters' unavoidable, they are a necessary part of the process. Design is not simply having an idea and making it real, design is taking the seed of an idea, and then exhaustively exploring all the space around it to find what works and what doesn't. You develop ways and ideas that compliment each other, and prune away those that don't, even when they might stand perfectly well on their own. Design is the process of finding form, not dictating it.

 

The skill to design, then, is not in simply having good ideas, but in being able to recognize ideas that enhance and compliment each other by combining to be something that is greater than the sum of its parts. Megaman isn't fun because he's a robot who moves left to right shooting things and gathering new weapons from bosses -- Megaman is fun because of how he moves through a world filled with a variety of enemies that represent different challenges, and which through their behavior, placement, timing, and environment create a novel, compound challenge on nearly every screen, and how by defeating bosses in a different order allows you, the player, to change those challenge equations.

 

Finally, its perfectly OK to be derivative of or to refine other games or combinations of other game mechanics, as long as you aren't duplicating them or using IP that's not yours. Romeo and Juliette is a story based on a previous tale, and which has been retold a thousand times since. Its a pattern or Genre of story that speaks well to us, just as there are genres and patterns in movies and games. But these things have to be moving, interesting, or fun to be true to what they are -- take it away and they are no longer the thing they claim to be -- a soulless story is not one worth hearing, a dull movie is not one worth viewing, a boring game is not one worth playing. In the entire space of what could be done, there are infinitely more failures to be found than successes, so if you make those core tenants subservient to your design -- rather than the other way around -- its no wonder that you will find yourself in the weeds with your boring game.

 

This last notion is not unlike the set of all numbers that exist -- in that set of numbers there exists an infinite amount of irrational numbers, unexpressible and forever repeating, and yet we thing of them as uncommon and not normal. In truth, its the rational numbers, those that have an end and therefore we can express, that we cling to in all we do, despite their cosmically singular rarity. Finding a new design that works is tantamount to discovering a new rational number, and its only natural that it might bare some resemblance to others we already know, or from which we might have learned from to find it.




#5164125 Designing a [Minecraft] RPG system

Posted by Ravyne on 01 July 2014 - 03:15 PM


I highly suggest you take a look at the following free PDF:
 
http://www.autzones.com/din6000/textes/semaine13/Kirk%282005%29.pdf
 
It is called RPG Design Patterns and it does a fantastic job at spelling out various RPG systems and how to effectively use them.  I can't emphasize enough what a treasure-trove of information this PDF has been to my designs!

 

This looks like an excellent document. Props for sharing!






PARTNERS