Jump to content
  • Advertisement

Radikalizm

Member
  • Content Count

    615
  • Joined

  • Last visited

Community Reputation

4809 Excellent

About Radikalizm

  • Rank
    Advanced Member

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Radikalizm

    [C++] ArrayView-class

    As mentioned above, this is pretty much exactly what gsl::span does. In addition to this gsl also provides string_span and multi_span. If you haven't played around yet with gsl, I definitely suggest you give it a try. It's been incredibly useful for us so far.   EDIT:   I also remember seeing a Microsoft implementation of array_view, and am quite sure that an implementation of array_view was suggested for an upcoming C++ standard. I also believe that boost provides a similar implementation.
  2. Radikalizm

    Renderer bells & whistles ~ pt. 2

    I'm always impressed when I read any of your journal entries. Awesome job!
  3. Note: This article was originally posted on my blog, go check it out! Also, the article editor might have eaten some of my formatting, my apologies for that. LOSING THE TRAINING WHEELS: SOME THOUGHTS ON MOVING FROM D3D11 TO D3D12 - PART 1 A new generation of graphics APIs has been released into the wild. With it come promises of improved performance through lean and mean drivers, an API that gives you - the developer - raw and virtually unhindered access to your graphics hardware, and fever dreams of pushing hundreds of thousands of draw calls per frame through your rendering pipeline without any of your systems showing any signs of breaking a sweat. Industry professionals and hobbyist developers around the world working on their very own next big thing rejoice, and all is good in the world of video game (graphics) development. Sound amazing, doesn't it? You bet it does! There's a catch though. Like with most of these big technological promises there's a price to pay, and in this particular case the price can be expensive. The philosophy behind DirectX 12 (and Vulkan and Mantle for that matter) is for the graphics driver to get out of the developer's way, and it does this by only doing the minimum amount of work necessary to translate the commands you provide into a predictable output on screen. This has some consequences, as by default there are no more training wheels to help you out like in DirectX 11 (and there were probably a lot more training wheels in place than you were aware of!). You are now in charge of managing the video memory backing your resources, you are in charge of making sure that your GPU resources are in valid states at all times, you are responsible for closely managing video memory budgets and consumption and telling the operating system about them, you are responsible for generating efficient resource binding layouts for your shaders, and you are responsible for so many more fun and exciting things which I couldn't list here because I'd just be going on forever. Failing to adhere to these responsibilities will relentlessly get you kicked into the wondrous world of undefined behavior, of which the side effects can range between nothing at all going wrong and your machine completely locking up or causing a kernel panic at seemingly random times. Fun times! This series of blog posts (which I've been wanting to write for a very long time, but I just never found the time to do so) goes over some problem points and general findings I've encountered during the time I've spent with DirectX 12, both professionally and in my spare time. I want to spend time especially on problem scenarios which might not be explained too well in other documentation. Additionally I'd like to talk at some point about design and architecture when building a DirectX 12 application from the ground up without a legacy D3D11 codebase to start from. Do note that this series of posts is not meant as an all-inclusive guide on how to move your existing applications to this new API or as a tutorial on how to build D3D12 applications. Some topics we'll go over first will be related to memory management, residency management, resource lifetime management, resource transition strategies and pipeline state object and root signature strategies. Today we'll start off with some memory and alignment related talk. Enjoy! THINGS YOU MIGHT WANT TO CONSIDER DOING UP FRONT: DEALING WITH RESOURCE ALIGNMENT DirectX 12 does away with specialized resource interfaces such as ID3D11Buffer, ID3D11Texture2D, etc. in favor of a generalized ID3D12Resource interface with a matching D3D12_RESOURCE_DESC structure used for resource creation. typedef struct D3D12_RESOURCE_DESC { D3D12_RESOURCE_DIMENSION Dimension; UINT64 Alignment; UINT64 Width; UINT Height; UINT16 DepthOrArraySize; UINT16 MipLevels; DXGI_FORMAT Format; DXGI_SAMPLE_DESC SampleDesc; D3D12_TEXTURE_LAYOUT Layout; D3D12_RESOURCE_FLAGS Flags;} D3D12_RESOURCE_DESC; If you're familiar with descriptor structures in DirectX 11, nothing in here should be a big surprise. One element in this structure, the Alignment entry, might carry more weight though than you'd at first assume. D3D12 wants video memory allocations to be straightforward and fast - remember: the driver has to get out of the developer's way -, so it makes a lot of sense to tie the size of its allocations to a value or set of values which it can deal with in a quick way, values closely tied to video memory page sizes for example. Because of this D3D12 only allows you to specify one of four (technically three) specific alignment values: 64Kb for general purpose allocations, 4Kb for small texture resources (note: I'm generalizing heavily here), 4Mb for multisampled textures and 0 to let the runtime decide for you. For textures these alignment values don't pose a lot of problems, and it can be safe in a lot of cases to let the driver choose an alignment for you as textures tend to be on the larger size when it comes to memory footprints. The amount of space wasted due to alignment overhead is generally tiny compared to the actual texture size. Buffers on the other hand pose a very big and inconvenient problem, making it almost impossible to directly (and naively) map ID3D11Buffer objects onto ID3D12Resource counterparts. As you might have noticed above, buffers have no other option than to specify a 64Kb alignment value - a value of 0 will always result in the runtime choosing 64Kb anyway -. Lots of titles tend to have a large amount of smaller ID3D11Buffer objects (think small vertex buffers, index buffers, constant buffers, etc.), which was absolutely fine in D3D11 as the driver would manage your memory for you under the hood. Taking the same approach in D3D12 will cause every single buffer, no matter how small, to take up a minimum of 64Kb of memory. Oops. Not dealing with this problem right away might cause your title to suddenly consume hundreds of Megabytes to Gigabytes more video memory than necessary, causing an immense amount of memory pressure on the operating system which at this point will frantically try to deal with the situation. If you have a system for dealing with residency (a topic which I'll elaborate on in my next post) your application will start working hard (and will fail) to stay within its provided memory budget, causing your title to stutter, slow down and maybe eventually crash when the situation becomes too dire. Solving this problem is going to require some work as you're going to want to implement a mechanism for doing sub-allocations on buffer resources. A lot of D3D11 titles already provide some form of buffer sub-allocation in the form of linear allocators or ring buffers which sit on top of an underlying ID3D11Buffer resource. These are very fast and very useful, especially for video memory allocations with a lifetime of a single frame or less, and are an essential tool in any graphics codebase, so porting them to D3D12 is a good first step if you have them. If you haven't implemented any of these yet, they're very similar to their system memory counterparts, only now you're dealing with pointers acquired through calls to ID3D12Resource::Map (or ID3D11DeviceContext::Map in D3D11), and for certain scenarios D3D12_GPU_VIRTUAL_ADDRESS values which act as pointers in virtual GPU memory. If you are looking for a reference implementation of these constructs, the MiniEngine project, which is part of the DirectX Graphics Samples on github provides a great implementation of a linear allocator which can be found at MiniEngine/Core/LinearAllocator.h and MiniEngine/Core/LinearAllocator.cpp. To solve our alignment problem completely however we'll need to go a step further by implementing a general purpose allocation system. The allocation strategies used here can be similar to the ones you'd implement for system memory allocations (look at it as implementing malloc for buffer resources). Feel free to get creative based on your specific allocation requirements; a construct such as a simple small block allocator can already solve a lot if not most of your alignment problems. One additional thing to keep in mind when implementing a general purpose allocator is that buffer resources which are used as a backing store for your allocations are created with specific usage flags (see D3D12_RESOURCE_FLAGS) and specific heap types (see D312_HEAP_TYPE), meaning that you'll want to specify separate allocators for separate use cases. Additionally this will have an effect on how you deal with resource state transitions (see D3D12_RESOURCE_STATES), as state transitions on a specific sub-allocated buffer can now affect other allocations on the same backing resources. Take the following pseudocode example: void Foo(ID3D12Resource* buffer){ // Sub-allocate two buffer resources BufferSubAlloc bufferA = MallocBuffer(buffer, 512); BufferSubAlloc bufferB = MallocBuffer(buffer, 256); // Transition buffer A into a vertex/constant buffer state ResourceStateTransition(bufferA, D3D12_RESOURCE_STATE_VERTEX_AND_CONSTANT_BUFFER); // Transition buffer B into an index buffer state ResourceStateTransition(bufferB, D3D12_RESOURCE_STATE_INDEX_BUFFER); DoSomeStuffWithBuffers(bufferA, bufferB); // What state is buffer A in at this point?} Two buffer sub-allocations, Buffer A and Buffer B, are allocated off of the same buffer. Buffer A gets transitioned into a vertex/constant buffer state, which results in the underlying ID3D12Resource to be transitioned into that same state. Next up, Buffer B gets transitioned into an index buffer state, causing that same ID3D12Resource from before to be transitioned in that state. Both Buffer A and Buffer B are now in the index buffer state because their backing resource is in that state, making Buffer A invalid for use as a vertex or constant buffer. Separating allocators based on intended use cases can save you the headache of having to deal with situations like these and will allow you to use buffer sub-allocations like you would use ID3D11Buffer objects. CLOSING THOUGHTS I hope this post didn't turn into too much of a rant, I sometimes have trouble with staying coherent in these kinds of posts or discussions (as many who know me can tell you). I'm looking forward to writing the rest of these, and I hope that someone somewhere finds these overviews useful. Next time I'll probably be talking about the MakeResident and Evict calls and how to use them to manage resource residency. I might throw in more stuff if I find the time, who knows. Thank you for reading, until next time!
  4. Radikalizm

    Cloud.gen

    Absolutely badass! Love to see stuff like this, keep it up!
  5. Radikalizm

    The Poor Man's Postmortem - Lemma

    Great postmortem! Very awesome job in seeing this project through until the end, there aren't a whole lot of people who can say they got to do a successful release of a personal project.
  6. Radikalizm

    It's done!

    Impressive work! Congratulations!
  7. Radikalizm

    Learn from Irrlicht the API mapping between OpenGL and Direct3D

    Irrlicht definitely isn't the right environment to do these kind of API comparisons in. It's not up to date with the most recent version of either API (as far as I know there's no support for any DX version after 9) and its general design is just not really that great.   If you really want to do a comparison of equivalent functionality in both OpenGL and DirectX just do a proper analysis of the APIs themselves instead of giving a shallow overview of an outdated - the last major release was over 2 years ago, and the last bugfix release over a year - and irrelevant engine.
  8. Radikalizm

    The CRI Project

    This journal entry was originally written for my homepage. Go check it out! THE CRI PROJECT CRI, short for Common Rendering Interface, a name which is no longer relevant as I hinted at in my last blog post, is a high performance 3D rendering toolkit which started development in late 2013. WHAT IS A RENDERING TOOLKIT EXACTLY? So glad you asked! The CRI project is a piece of software which allows a developer to prototype and build graphical systems and effects in an intuitive manner. It is an extensible research and experimentation tool targeted more towards building technical demos and proofs of concepts (read: really really cool shiny stuff) rather than actual games (although using CRI in a game project would definitely be feasible). It is a sandbox environment for rapid implementation and iteration of anything graphics and rendering related. At the core of the project lies a powerful lightweight multithreaded rendering engine built on top of Direct3D 11 and AMD's new Mantle API, with Mantle being the primary focus. Support for OpenGL 4 is currently also in the works but is treated as a "nice to have" feature for now since CRI relies heavily on multithreaded rendering job execution, something OpenGL does not like to play with nicely. Whether OpenGL will actually show up in later revisions of the project is absolutely not sure. On top of this rendering engine a set of tools will be provided which allow a developer to build custom lighting and shading pipelines, render queues, post-processing effects and much much more in a data-driven and native plugin-based fashion. A basic scriptable scene compositor and asset manager will also be provided to create scenes and easily set up graphics configurations. With this an extensive profiling suite will also be provided as a way to get exact performance details of your setup. Aside from all of this a C++ API will also be exposed for both the higher level tools and the low-level rendering engine. This allows for the development of plugins as well as integration into other C++ based projects such as games. WHY BUILD SOMETHING LIKE THIS? In the past I've written quite a few rendering engines both professionally and as personal side projects. The last one of my personal rendering projects was part of a larger project called RainEngine, which up until now has been my most ambitious and advanced personal project to date. As soon as I started my current job I pretty much stopped development on this project, this due to it being very massive in scope and me not being all too pleased with its overall design. I have been able to build some very cool stuff with it however and it served as the centerpiece of my portfolio before I started doing graphics programming professionally, and I am still very proud of what I achieved. During the development of the RainEngine project I learned that even though I had greater ideas in mind I always got most of my enjoyment out of building cool graphical systems and effects. Often this lead me to spending weeks or even months on tweaking, fine-tuning and experimenting with advanced lighting systems or post-processing effects even though I should have been focusing on how they would work best in the game I wanted to build. It is at this point that I realized that I didn't care so much about building games with the technology I had implemented, but rather about building breathtaking or lifelike and dynamic scenes which one could traverse in real-time. Combine this with the excitement of being able to read papers about the latest and greatest AAA techniques and implementing them within my own environment, and I was all set. This is why I am taking on the CRI project. Does a tool like this already exist? Probably. Do I care? No. This is all about me building something I want to build: A cool and exciting project which will allow me to easily do even more cool and exciting stuff. If people end up being interested in it, that's great! If people want to try using it, even better! (although I'll probably hold off on releasing anything until certain software components I'm using are widely accessible and no longer under any NDAs, *cough* Mantle *cough*. This is also a heads-up that I won't be discussing anything Mantle specific on this blog). I'm just saying that I'm not planning on creating the world's best AAA rendering engine or the most revolutionary application ever, I just want to build a tool I can enjoy working on and working with while pushing my own skills even farther. WHICH STATE IS THE PROJECT IN RIGHT NOW? I've been working on this project for several months now. Due to work and life in general I often have days or even weeks where I don't touch any CRI code at all, which means development isn't exactly going at breakneck speeds. What I have right now is a core library with platform abstractions and utility code, a math library (which has been with me for years and has improved with every graphics related project I've done), a task-based multithreading system, a fully functional D3D11 low level renderer and partially functional Mantle and OpenGL renderers. Since I did not anticipate on getting access to Mantle at the start of the project I had designed the rendering infrastructure around D3D11. The focus has however shifted towards a Mantle-based design, so I am currently working on revising the architecture of the renderer to be more future proof (as it seems like future generations of both OpenGL and D3D will follow a Mantle-like approach). As for design documents and architectural concepts for the rest of the project a lot more work has been done. I'd like to save the details for these for future blog posts though, as this one seems like a wall of text already. FINISHING UP If you've made it to this point: Congratulations! Apparently my post wasn't too boring! If I had cake I'd give you a slice! I'd like to write a lot more about this project as development continues. Even if nobody really reads any of this, it's nice to write about this stuff to clear out my mind a bit! Thanks for reading, and until next time! (Again, you can also read this entry at my homepage!)
  9. Radikalizm

    The death of a project

    I want to make it very clear though that I do not regret working on this engine, nor that I think it was a bad idea in the first place. If I wouldn't have built it I wouldn't have a job right now.     I also want to stress that I would have definitely been able to finish it if I wanted to, I'm dropping the project because it has no real purpose anymore, and making an engine without having a goal for it is just not a good idea. If my life hadn't changed this drastically I would've definitely finished it, along with the games we had planned for it.   I knew what I got into when I started this, I was not one of those people who had the idea of making the next AAA blockbuster engine.
  10. Radikalizm

    The death of a project

    2013 has been a completely insane year for me, it was the year in which I dropped out of university (with my degree not too far off!), got a job at a game development studio as a (rendering) engineer in Canada, and moved away from Europe to go do said job. This combination of events of course make a huge impact on your day-to-day life. You leave behind friends, family, your classmates, and in my case projects. For the past few years I have been working on a couple of things - either on my own or with friends - under the moniker Rainware. The biggest of these projects was the RainEngine project (Random note: holy shit, if you check out the forums seems like everyone and their mom wants to build the next greatest game engine out there these days). This project has been my baby for the last 4 or 5 years and has gone through many iterations. In its current state it is a very powerful and neat engine in which I can do my crazy crazy experiments, but it is far from finished, and actually finishing it according to the specification I wrote up for it would still take years in my current situation (having a full-time job which tends to stretch the daily 9-to-5 time frame quite often - not that I'm complaining of course, I love it! -). The idea of working on this project for another couple of years is not what's bothering me, it's the concept of how relevant this project is still going to be after spending way too much development time on it. Four years ago I also didn't have the same skills and experience I have now; this means that there are a couple of components of this engine which are not designed the way I'd like them to be (read: They're a pain in the ass!). Replacing these would be a huge task in itself as they are deeply embedded into the core of the engine. At this point I also feel like I have learned most of what there is to be learned from doing a project like this on your own. Although I gained a massive amount of knowledge (knowledge which got me where I am today), I feel as if it doesn't have anything to offer to me anymore, and the fact that the cool game projects we were working on are all dead now (seeing as there's this huge ocean in between me and the guys I was working with) doesn't get me excited about this project's future either. So, that being said, I now officially declare the RainEngine dead. So long! We had a great run! I had an awesome time working on you! But now it's time for something else... Since I started working at my current job I've grown a lot more confident about my programming skills, especially when it comes to writing clean and well thought-out code. When working on personal projects the last few years I only had myself and maybe a handful of classmates to review the code I wrote, not what you'd call a trustworthy group of reviewers. This kind of kept me from releasing code into the wild, because I would always be afraid of doing something really stupid somewhere in my code. These days I work with a team of people who have been working as software engineers for years; some of my coworkers even started out when I was still in elementary school. Getting confirmation from these people that what I write actually is quality code has boosted my confidence quite a bit, and this will be an important factor in how I tackle future projects. In these past few months I have also learned a lot about what it actually is to manage and develop these huge software systems without them becoming a huge chaotic mess of code, half implemented features and indecipherable road maps. In addition to this my skills in writing rendering code have improved as well. All of these things have motivated me to start on something new. Something more thought out and doable. All in all this new project will be: More manageable in scale: I wouldn't say it's a small project, but it is something that can be actually finished by a single developer in a reasonable amount of time. Closely related to my job: My job has actually motivated me to do more of the same in my personal projects! More open: Once this project gets off the ground I want to actually be more open about it. Maybe I'll throw the code out in the open under some permissive license to see what people can do with it. Or maybe I'll just do frequent binary releases, who knows. Properly structured: This applies to both the code itself and the way it's being developed. Awesome: Speaks for itself, right? Of course I don't want to get ahead of myself. I'm still finishing up writing the documentation what this project is going to be exactly and where its limits are going to be. In addition to that I'm also only writing boilerplate and support code right now, the actual meat of the project is something I'll be starting on in the next couple of weeks. As soon as this thing actually does something I'll be more than happy to write about it. I hope this journal post didn't come off as me rambling about a bunch of stuff, I'm just really excited to work on something new to go together with my new life! Until next time!
  11. Note: This is kind of a follow up on my last journal entry, read that one first if you want to be able to make sense of this one So I have been living and working in Vancouver for about three weeks right now as a software engineer at a local game studio, and it's been absolutely amazing. I was able to do a bunch of fixes for and witness the launch of one project on Steam during this time, and I've been able to dive head first into another project as well. This job is pretty much everything I had hoped it would be; I get to do what was basically my hobby for years as my job, and I get to do this in an awesome location with an awesome group of people with years of experience (seriously, some of my coworkers have been working in this industry since I was still a little kid!) One of the best things about this job is maybe that while I'm technically an intern, I'm not being treated like an intern. I have a solid position within my team with my own share of real responsibilities and real tasks just like anyone else, and being able to live up to those responsibilities only confirms even more that I made the right decision in taking this opportunity and that this is what I want to do with my life. Of course I can't go into specifics of what I'm working on, so let's just say that it's pretty damn cool and exciting Besides work I've been able to meet a bunch of really cool people here in Vancouver and surroundings, especially everyone in AIESEC SFU, which is the organisation which set me up with my internship in the first place (On that note I should definitely give a shout out to the person who made all of this possible, you know who you are! You're awesome!). The city and surroundings themselves are quite different from where I used to live in Belgium, but I'm absolutely loving it. I think that's about all I wanted to say for now. I'll probably do some more journal entries in the future if anyone is interested. Until next time!
  12. Radikalizm

    Did that just happen?

    Vancouver is really nice indeed, I really fell in love with the city while I was there
  13. Radikalizm

    Did that just happen?

    I've studied at KU Leuven for two years after which I went to UHasselt :)
  14. Radikalizm

    Did that just happen?

    About a month ago I was a computer science student in Belgium going into his last year before finishing his degree. Due to a whole bunch of coincidences this is no longer the case today. As some of you may or may not know my main passion is rendering. I can get extremely excited about implementing fancy lighting systems, next-gen rendering pipelines and everything in between. Obviously my goal was to find a job doing just this once I had my degree; the only downside to this idea was that Belgium doesn't really have an active game industry. Conclusion: I'd probably need to get my degree, get a software engineering job at a local company and try to work my way into a game development company abroad (preferrably across the atlantic ocean) one way or another after gaining some professional experience. I went to visit my cousin in Vancouver last month together with a good friend of mine. This cousin is doing a year-long marketing internship at a local company and is basically having the time of his life. Of course I had to go over there to join in on the fun. Some time before I departed from Belgium my cousin and I started talking about the organisation through which he set up his internship and all the other internship opportunites which were available in Vancouver. Apparently this organisation was in talks with a game development studio, and this studio in particular was looking for someone with experience in rendering. Of course, this piqued my interest, but I didn't give myself any illusions. I was still in university, I did not have a degree nor any professional software development experience whatsoever and my portfolio was made up out of an engine project and a bunch of small tech demos. Since there were talks about possibly setting up a meeting with this company I collected some of my best demos, wrote up a resume and made contact cards, but I still wasn't really optimistic about my odds of actually impressing anyone. The reaction I was expecting from this meeting was something along the lines of "that looks really nifty, why don't you come back in a couple of years and we might be able to talk business", and I would've been really happy with that (having contacts in this industry means a lot!). So after a week of being in Vancouver I had my first job interview. Ever. 8000 kilometers from home. And it was awesome! I was able to show off my work, talk about my engine project I've been working on for the past four years and to my amazement the discussion quickly changed to talks about an intern position for the coming year and a possible full time placement afterwards. All in all it was just a very exciting and surreal experience. After this day my life was pretty much turned upside down. I'd be leaving Belgium and move to Vancouver for at least a year. I would be giving up my studies (although my university guaranteed me that I could pick them back up from where I left them if I wanted to). I really couldn't refuse this offer since it was basically everything I ever wanted in a job. A couple of days after the meeting I arrived back home in Belgium, and the events of the past couple of days just seemed way too surreal. In the following weeks there'd be tons of paperwork, a technical interview including a programming test over Skype (which went really really awesome as well), apartment hunting and telling friends and family that I'd be moving to the other side of the world very soon. This brings us to the present day. I'm finishing up all of the required paperwork (work permit, rental contract, etc.) and I hope to be able to depart for Canada in about a week or three. I couldn't be more excited.
  15. Radikalizm

    Oculus Rift VR Development Kit...

    User interfaces for games which are not designed around the rift like TF2 or HL2 are pretty terrible indeed, a lot of them completely dissapear out of your field of view, are barely visible out of the corner of your eye or just have a terrible resolution like you said.   Of all the UI solutions for the rift I've seen the one that was most enjoyable for me was where the interface would stay at a fixed position relative to the player position without rotating with the player orientation. This gives the impression of the UI being presented as a floating screen in front of the player, which feels very natural as it's just like working with a computer screen.  An example of this would be the menu screens in the minecraft rift mod.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!