Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bunnymark GL in Jai – 200k sprites at 200fps [video]

youtube.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#41

Post by aappleby »

Very rough guesstimates:

200000 * 200 * 2 = 80M tris/sec

200000 * 200 * 32x32px = 40 gpix/sec (if no occlusion culling)

Neither of those numbers are particularly huge for modern GPUs.

I'd wager that a compute shader + mesh shader based version of this could hit 2M sprites at 200 fps, though at some point we'd have to argue about what counts as "cheating" - if I do a clustered occlusion query that results in my pipeline discarding an invisible batch of 128 sprites, does that still count as "rendering" them?

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#42

Post by HWR_14 »

iliketrains wrote: post #22
chrisseaton wrote: post #20

Earlier quoted context omitted.

> Isn't this akin to 400k triangles on a GPU? Is it faster to render two triangles with slightly less area, or one triangle with slightly more area, to draw the same sprite?

Rendering only one large triangle can be faster than two. First one triangle needs less memory, less vertex processing, etc. Second, modern GPUs render pixels in groups of 2x2 up to 8x8 "tiles". If only one pixel from this group is part of a triangle, the entire group will be rendered. When two triangles form a quad, the entire area along the diagonal "seam" will be rendered twice. The smaller quads you have, the mor…

I disagree, with the exception of the case you link to where half the pixels are outside the viewport or maybe where a sufficient percentage are outside the viewport.

> When two triangles form a quad, the entire area along the diagonal "seam" will be rendered twice

This may be true, but I'm pretty sure that this is more than made up for by the additional pixels in the single triangle circumscribing the quad. In fact, I'm willing to bet that it's a mathematical certainty for any rectangle, although I didn't do enough of the math to prove it.

Instead, I would say that most rendering, especially of hundreds of thousands of 2D shapes, are going to be pixel limited. So trading pixels for vertices is a poor trade.

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#43

Post by p1necone »

fao_ wrote: post #19
kingcharles wrote: post #14

Earlier quoted context omitted.

Just to be clear - you're writing a "software-based" 3D renderer, right? This is the sort of thing I excelled at back in the late 80s, early 90s, before the first 3D accelerators turned up around 1995 I think. What features does your renderer support in terms of shading and texturing? Are you writing this all in a high-level language, e.g. C, or assembler? If assembler, what CPUs and features are you targeting? And o…

Unrelated but wrt. modern rendering versus 90s rendering I'd imagine that a lot of the performance shims used in the 90s might not apply because the critical problem is different. Performance based development these days isn't so much on maximizing usage of the cycles of the machine (I mean, ok fundamentally it's still about that, but-), rather it's about getting the microcode to do the right thing. E.g. LUTs being e…

Even if your mental model is as simple as "CPU processing + L1 cache is infinitely fast, having to fetch data from anywhere else is dog slow" you'll be able to optimize code pretty well given the characteristics of modern processors.

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#45

Post by Jasper_ »

quadcore wrote: post #25
chrisseaton wrote: post #20

Earlier quoted context omitted.

> Isn't this akin to 400k triangles on a GPU? Is it faster to render two triangles with slightly less area, or one triangle with slightly more area, to draw the same sprite?

Pretty sure overdraw / fillrate bottlenecks before vertex processing. Also you could draw that quad using strips which would then amount for only one more processed vertex compared to triangle. Edit: okay surely with modern architecture there is no pixel write because of some early alpha cut but you still have to fetch the texture to make it so texture fetch (memory) will bottleneck first. I guess.

You shouldn't use strips, they're slower than triangle lists on most GPUs.

If by alpha cut you mean "discard", that's going to be much slower than two triangles. Two triangles will have a tiny bit of quad overshading on the seam, compared to a full extra triangle's worth in the alpha cut case.

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#46

Post by leowbattle »

fao_ wrote: post #19
kingcharles wrote: post #14

Earlier quoted context omitted.

Just to be clear - you're writing a "software-based" 3D renderer, right? This is the sort of thing I excelled at back in the late 80s, early 90s, before the first 3D accelerators turned up around 1995 I think. What features does your renderer support in terms of shading and texturing? Are you writing this all in a high-level language, e.g. C, or assembler? If assembler, what CPUs and features are you targeting? And o…

Unrelated but wrt. modern rendering versus 90s rendering I'd imagine that a lot of the performance shims used in the 90s might not apply because the critical problem is different. Performance based development these days isn't so much on maximizing usage of the cycles of the machine (I mean, ok fundamentally it's still about that, but-), rather it's about getting the microcode to do the right thing. E.g. LUTs being e…

If modern high performance code relies on making the microcode do "the right thing", and making sure the right data is in cache then why don't CPU manufacturers allow control over such things?

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#47

Post by OskarS »

daenz wrote: post #27

It's been awhile since I've done game engine work, but is this impressive? The first thing that comes to mind is they're using instanced rendering. This allows the CPU to only deal with 1 sprite, while telling the GPU to render multiple instances of the sprite, and use a GPU buffer to find each sprite's transformation matrix. All the CPU has to do is update that mmap'ed buffer with new position information (or do som…

> All the CPU has to do is update that mmap'ed buffer with new position information

Doesn’t even have to do that, this is child’s play for a compute shader. The CPU can go take a 16 millisecond nap and let the GPU do all the work.

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#48

Post by farzher »

daenz wrote: post #27

It's been awhile since I've done game engine work, but is this impressive? The first thing that comes to mind is they're using instanced rendering. This allows the CPU to only deal with 1 sprite, while telling the GPU to render multiple instances of the sprite, and use a GPU buffer to find each sprite's transformation matrix. All the CPU has to do is update that mmap'ed buffer with new position information (or do som…

you're not missing anything, it's not impressive. i was just checking how fast computers are and sharing the results. my original title was "an optimized 2d game engine can render 200k sprites at 200fps" but the mods changed it to match my youtube title (which made it a lot more popular). and the fact it's written in jai isn't relevant, it's just what i happened to use

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#49

Post by farzher »

bob1029 wrote: post #10
xaedes wrote: post #6

Nice demo! We need more of this approach. You really can achieve amazing stuff with just plain e.g. OpenGL optimized for your rendering needs. With todays GPU acceleration capabilities we could have town-building games with huge map resolutions and millions of entities. Instead its mostly only used to make fancy graphics. Actually I am currently trying to build something like that [1]. A big big world with hundreds o…

> We need more of this approach. 1000% agree. I recently took it upon myself to see just how far I can push modern hardware with some very tight constraints. I've been playing around with a 100% custom 3D rasterizer which purely operates on the CPU. For reasonable scenes ( single thread. On a 5950x, I was able to support over 10 clients simultaneously without any issues. The GPU in my workstation is just moving the f…

> One fun thing I discovered is just how low latency a pure CPU rasterizer can be compared to a full CPU-GPU pipeline

i'm definitely going to have to test that! always trying to minimize input delay

Re: Bunnymark GL in Jai – 200k sprites at 200fps [video]

#50

Post by farzher »

sqrt_1 wrote: post #12

I assume each sprite is moved on the CPU and the position data is passed to the GPU for rendering. Curious how you are passing the data to the GPU - are you having a single dynamic vertex buffer that is uploaded each frame? Is the vertex data a single position and the GPU is generating the quad from this?

you can write 100% of the code on the gpu. but that's impractical to work with. i did that here to see how fast webgl can go, since javascript is so slow https://www.youtube.com/watch?v=UNX4PR92BpI

for this bunnymark i have 1 VBO containing my 200k bunnies array (just positions). and 1 VBO containing just the 6 verts required to render a quad. turns out the VAO can just read from both of them like that. the processing is all on the CPU and just overwrites the bunnies VBO each frame

Post reply on HN