Skip to content

Instantly share code, notes, and snippets.

View himanshugoel2797's full-sized avatar
🙃
Focusing

Himanshu Goel himanshugoel2797

🙃
Focusing
View GitHub Profile
@himanshugoel2797
himanshugoel2797 / schema.json
Created October 24, 2023 04:43
ESE 481 - Lab 6 - Task 3 Schema
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"properties": {
"id": {
"type": "string"
},
"name": {
"type": "string"
},
#include <stdint.h>
struct b2m_table {
uint32_t byteToMorton[256];
uint8_t mortonToByte[1 << (3 * 4)];
constexpr b2m_table() : byteToMorton(), mortonToByte() {
for (uint32_t i = 0; i < 256; i++) {
uint32_t cur_val = 0;
for (int j = 0; j < 8; j++)
/**
* Demonstrates how can map a 32-bit integer to a range faster than
* a modulo reduction.
* Assumes x64 processor.
* gcc -O3 -o fastrange fastrange.c
*/
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
using Kokoro.Math;
using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Runtime.CompilerServices;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace Kokoro.Graphics.Voxel
SAMPLE_COUNT_8_BIT
framebufferNoAttachmentsSampleCounts:
SAMPLE_COUNT_1_BIT
SAMPLE_COUNT_2_BIT
SAMPLE_COUNT_4_BIT
SAMPLE_COUNT_8_BIT
maxColorAttachments = 8
sampledImageColorSampleCounts:
SAMPLE_COUNT_1_BIT
SAMPLE_COUNT_2_BIT
#%%
import keras.backend as K
dtype='float32'
K.set_floatx(dtype)
# default is 1e-7 which is too small for float16. Without adjusting the epsilon, we will get NaN predictions because of divide by zero problems
#K.set_epsilon(1e-4)
import keras
#include "stdafx.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#define SIDE 128
#define PATH_LEN 10
#define MIN_PATH_LEN 8
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <stddef.h>
typedef struct {
uint32_t magic;
uint32_t count;
uint8_t stuff[12];
#!/usr/bin/env python3
import os.path
import struct
from idautils import *
from idc import *
INFO_SIZE = 0x5c
NAME_OFF = 4
hgoel> to continue, my previous thought: still pretty doubtful, there isn't really any incentive to merge the two
4:40 PM design wise, it's IMO far more convenient to keep them separate
4:40 PM B<bcos_> Based on recent experiments; I'm "relatively convinced" I can do extremely high quality software rendering on modern 8-core CPUs
4:41 PM ..which means, if CPU performance doubled we'd have enough CPU to not bother with GPU at all
4:42 PM H<hgoel> would that include stuff like in modern games?
4:42 PM B<bcos_> Depends what stuff
4:42 PM H<hgoel> mostly lighting equations
4:42 PM plus, if CPU math speeds double, then most likely said doubling can be applied to GPUs and we're back at the same spot
4:43 PM B<bcos_> I was doing full lighting/shadow, focal blur and "infinite supersampling"
4:43 PM ..but no reflections