I've started to do daily programming puzzles. They have been helping me hone my programming / reasoning skills. I'm going to start using the daily puzzles to learn other languages as well since I think it will be good to learn the constructs of other languages this way (even the smallest puzzles exercise my knowledge of C++ STl...not much, but I were new to C/C++ I would have a hard time).
So the website I've been looking at is http://sixrevisions.com/resources/10-puzzle-websites-to-sharpen-your-programming-skills/ , specifically the first link has tiny little puzzles on it.
So far I've done two from this website (Sum4, Scalar Product), each of them taking a short while to think and program up. They are essentially interview questions.
The other day while reading Ken Thompson's Touring Award speech "Trusting Trust", and I encountered the Quine...a self-reproducing program. For example, in C, you would write a C program that when compiled would produce the original source, character-for-character. This sounds easy, but the naive way to go about solving this will show you that it's a little trickier than it sounds. Anyways, after a canceled flight at DFW airport and a stay in the Holiday Inn Express, I gave it a try. I figured out the solution, and I got it working the next day, It's suprisingly simple once you figure it out...but I saw some of the other results (in C) and it amazed me at just how small you can get the program. In fact, this used to be a little game with Ken Thompson and Dennis Ritchie when they were in College. They used to see how small of a Quine they could produce. This also led me to the discovery of "multiquines": A program written in one language produces source code for another language, which if compiled in run would reproduce the original language's source code...this is so cool!!! I might try it some day. For now, I must move on to work on Oblivion Wars...good day.
Monday, August 20, 2012
Wednesday, August 8, 2012
Very exciting things happening in the new OpenGL 4.3 standard. I'm sitting listening to Mark Kilgard's OpenGL 4.3 talk at SIGGRAPH currently. These are the take-aways:
Compute Shaders - OpenGL now has general CUDA/OpenCL functionality built into the graphics pipeline. Same notion of using a set of threads inside a workgroup is used, and these can all communicate with each other and with global textures. Furthermore, having this inside of a shader allows one to unify the computations and outputs with OpenGL textures, vertex arrays, etc. This means no third-party API is needed for GL <-> GPGPU compute functionality.
Debug - Allows one to annotate and use debug messages help them debug their OpenGL code.
He showed a few examples: a few image processing examples, Soble filtering, Gaussian filtering, etc all in real-time. Looking forward to seeing some of the image processing techniques being used in games. Also showed a particle physics simulation where the compute shader integrated the motion of hte particles and updates the positions in a GL vertex buffer. All without going to the CPU, yay!
Many many many more. Be on the look out for Mark Kilgard's slides on this being posted soon.
Other things: Further Linux support by NVIDIA.
Bindless Graphics: Instead of binding to textures (which leads to a lot of different buffers and textures), you can map all the texture buffers into your GPU address space and access these inside the shader. This means you have access to MANY more textures in a shader, and you don't have to bind them from the CPU side. This is only on NVIDIA's Kepler architecture. Mentions this could be useful for ray-tracing where each ray needs access to the entire scene.
Exploiting the modern graphics pipeline: Similar bindless for Uniforms, materials, etc. MultiDrawIndirect -> Draw several batchs of stuff in a single call. Supports indexed subrouties.
Compute Shaders - OpenGL now has general CUDA/OpenCL functionality built into the graphics pipeline. Same notion of using a set of threads inside a workgroup is used, and these can all communicate with each other and with global textures. Furthermore, having this inside of a shader allows one to unify the computations and outputs with OpenGL textures, vertex arrays, etc. This means no third-party API is needed for GL <-> GPGPU compute functionality.
Debug - Allows one to annotate and use debug messages help them debug their OpenGL code.
He showed a few examples: a few image processing examples, Soble filtering, Gaussian filtering, etc all in real-time. Looking forward to seeing some of the image processing techniques being used in games. Also showed a particle physics simulation where the compute shader integrated the motion of hte particles and updates the positions in a GL vertex buffer. All without going to the CPU, yay!
Many many many more. Be on the look out for Mark Kilgard's slides on this being posted soon.
Other things: Further Linux support by NVIDIA.
Bindless Graphics: Instead of binding to textures (which leads to a lot of different buffers and textures), you can map all the texture buffers into your GPU address space and access these inside the shader. This means you have access to MANY more textures in a shader, and you don't have to bind them from the CPU side. This is only on NVIDIA's Kepler architecture. Mentions this could be useful for ray-tracing where each ray needs access to the entire scene.
Exploiting the modern graphics pipeline: Similar bindless for Uniforms, materials, etc. MultiDrawIndirect -> Draw several batchs of stuff in a single call. Supports indexed subrouties.
Subscribe to:
Posts (Atom)