@gob@mastodon.gamedev.place
@gob@mastodon.gamedev.place avatar

gob

@gob@mastodon.gamedev.place

๐Ÿ‡ง๐Ÿ‡ช CS PhD student @uni ๐Ÿ‡ฉ๐Ÿ‡ช I do graphics and compiler things. Working on SPIR-V/Vulkan compilation for "serious" compute.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

gob, to random
@gob@mastodon.gamedev.place avatar

"Yes we have C shaders in Vulkan, but what about C shaders that lower to glsl 1.20 and run on OpenGL 2.x hardware ?"

Part of GLSL 1.20 code obtained by compiling the C shader with Vcc. Note the polyfill for xor!

gob,
@gob@mastodon.gamedev.place avatar

This experiment is of no practical use. At least one hopes so.

frog, to random

The average Microsoft Developer Community experience ๐Ÿค–๐Ÿณ

A bot posts a really long scrambled egg recipe

gob,
@gob@mastodon.gamedev.place avatar

@frog drive-through replies on Microsoft support forums are always insultingly idiotic but they're not shy about reaching new lows

jbikker, to random
@jbikker@mastodon.gamedev.place avatar

https://carette.xyz/posts/state_of_vulkan_2024/

TL;DR: Too hard to learn; many people stick with OpenGL. In the meantime, a colleague at my university asked if it would be safe to basically switch to path tracing altogether for year 2 courses next year, using the APIs to render 2 tris essentially...

gob,
@gob@mastodon.gamedev.place avatar

@jbikker Vulkan is a win for advanced use-cases and as a substrate for building layered implementations of other things. It has many qualities, and a few crucial exclusive ones.

As an API for teaching graphics, I think it is incredibly inappropriate: I've seen the tedious API boilerplate engineering take center stage and then we just have time to go through the motions of basic rendering.

Sticking with GL seems preferable to spending half a semester poorly re-implementing it on top of VK, IMO.

gob,
@gob@mastodon.gamedev.place avatar

@jbikker Things like WebGPU hardly impress me either because they are so stubbornly conservative.

Bindless and AZDO techniques were already hot topics 15 years ago but somehow we still design high-level APIs around bindful models and CPU work submission.

Vulkan 1.3 on a desktop GPU can do all these cool tricks, but because some Android sludge device ships a bad VK blob driver, it doesn't count for anything and we still design to the lowest common denominator :(

gob,
@gob@mastodon.gamedev.place avatar

@nical The tail of support is getting increasingly long: when webgl 1.0 was out, it was based on gles 2 which was 4 years old, the WebGPU draft now loosely matches Vulkan 1.0 which is nearing 10 years old.

This obviously won't work for me.

gob,
@gob@mastodon.gamedev.place avatar

@jbikker Yes there's definitely a moving target at the high-end, and Vulkan follows it. I consider modern Vulkan (BDA, non-uniform descriptor indexing, maximal reconvergence, mesh shaders, raytracing, ...) a completely different API, and a much better one at that.

But many of the things I get worked up about aren't so fast moving at all: BDA has been there since 2019, non-uniform descriptor indexing is 2017.

It's entirely viable to build a fully bindless API but nobody has so far afaik :|

aras, to blender
@aras@mastodon.gamedev.place avatar

Coding #blender from a public library, as one does. Is nice!

gob,
@gob@mastodon.gamedev.place avatar

@aras obviously a fake rendered image, public libraries don't look this good...

simonf, to random
@simonf@mastodon.gamedev.place avatar

Dear Graphics Folk,
I recently was looking through a 1998(!) SIGGRAPH paper that mentions some supplemental material (in a subdirectory) but canโ€™t find it on the web. I contacted the main author but he said itโ€™s long gone.
I was wondering if itโ€™s possibly on the 1998 CD? I have a few conference CDs from the 90s but not 98. Does anyone have it and could check?
TIA

gob,
@gob@mastodon.gamedev.place avatar

@simonf I do, but the boxes are at my parents place

gob,
@gob@mastodon.gamedev.place avatar

@simonf I also have the VHS :)

nh, to random
@nh@mastodon.gamedev.place avatar

Regardless of how the Scarlett Johansson / OpenAI thing ultimately turns out, it's a great reminder that the more pressing alignment problem isn't alignment of machine learning systems, it's alignment of the alien intelligences also known as "corporations".

gob,
@gob@mastodon.gamedev.place avatar

@nh corporations are not people and mitt romney is not my friend

thephd, to random
@thephd@pony.social avatar

It's time.

RAII in C, and why nobody's getting it right with the increasingly "simple" juggling that keeps getting tossed to me like table scraps for a dog.

The Pasture | Why Not Just Do Simple C++ RAII in C? | https://thephd.dev/just-put-raii-in-c-bro-please-bro-just-one-more-destructor-bro-cmon-im-good-for-it

gob, (edited )
@gob@mastodon.gamedev.place avatar

@thephd Have you written about or otherwise have a stance towards the idea of making C "type-less" (internally) and moving away from the type aliasing rules ? I.e. untyped pointers and memory objects are sized bags of bytes, like what modern LLVM is doing

From my rather naive perspective, tons of people already dismiss TBAA by running -fno-strict-aliasing and they don't seem to hurt too bad from that.

Would that be giving up something fundamental to C's design? Or could it be a way forward ?

gob,
@gob@mastodon.gamedev.place avatar

@gfxstrand @thephd For my own purposes of doing SPIR-V shader shenanigans and parsing LLVM IR, untyped pointers create a bunch of novel (unwanted) problems for me.

The memory in many storage classes is inherently opaque and strongly-typed, and I have no choice but to do a bunch of analyses and gymnastics to recover pointee types to emit valid IR :/

It's unclear how this hurts other LLVM backends internally, but there is no way this decision doesn't bite themselves when they emit SPIR-V...

gob,
@gob@mastodon.gamedev.place avatar

@dneto @gfxstrand @thephd Yeah I think LLVM has largely forgot the supposed goal of being hackable and as a result the externalities are paid for by everyone else.

A C++ language front-end that's actually hackable and usable by other compiler stacks (Circle going foss, idk?) would be a huge breath of fresh air at this point.

I can imagine it'd take only 10 hours for someone to bolt it to NIR, for example :P

gob, to random
@gob@mastodon.gamedev.place avatar

The new place is nice but the internet really isn't that good. My easybell DSL connection has lost sync for about 7 hours now :|

roxy, to random
@roxy@chitter.xyz avatar

๐Ÿญsometimes you go to throw trash away and it bounces off for no reason??? well, I think I finally figured it out

gob,
@gob@mastodon.gamedev.place avatar

@roxy someone gets pannenkoek his honorary phd, i'm no longer kidding

litherum, to random
@litherum@masto.ai avatar

I think itโ€™s semi-hilarious that thereโ€™s a blog post going around which basically says Metal Shading Language is by far the best shading language (without actually saying it)

https://xol.io/blah/death-to-shading-languages/

Also the author gets bonus points for mentioning WGSL, but the loses them all again for complaining that WGSL isnโ€™t more expressive than the languages it compiles to

gob,
@gob@mastodon.gamedev.place avatar

@litherum Actually the current flavours of shader SPIR-V available in all Android Vulkan devices would be a massive improvement.

gob,
@gob@mastodon.gamedev.place avatar

@litherum For the first point: I gave a talk at this year's Vulkanised about making C++ shaders work within the restrictions of Vulkan SPIR-V. I've also written numerous posts about it, and I serve on the SPIR-V working group. I'm fairly confident I know my stuff.

For the second one, as a compiler writer, wgsl is a terrible compiler target, just as bad as any textual language. The fact people have done it because they were forced is in no way a validation of anything.

gob,
@gob@mastodon.gamedev.place avatar

@litherum I want real debug info and a machine-readable grammar at a minimum. WGSL currently tries to be both an IR and a HLL, and it succeeds at neither IMO.

Really it'd be better for the ecosystem at large to do the required internal lobbying to convince Apple, or whoever else blocks SPIR-V being adopted.

gob,
@gob@mastodon.gamedev.place avatar

@litherum Good, because my argument is not that characters are involved.

My argument is that an IR is optimized to be machine-readable, strips away redundant constructs, and supports things like debug information.

WGSL is none of those things.

gob,
@gob@mastodon.gamedev.place avatar

@litherum Parsing SPIR-V is incredibly easy and that was a design decision. Generating it is similarly straightforward.

The other link you sent me is just the spec, the folder it's in includes an incomplete grammar, nothing like spirv.json that you can actually use in real compilers to generate boilerplate (like mine).

gob,
@gob@mastodon.gamedev.place avatar

@litherum
> I also donโ€™t know what you mean by โ€œredundant constructs.โ€

How about having 3 loop statements ?
https://www.w3.org/TR/WGSL/#control-flow

> I do not understand the claim that textual languages cannot hold debug information

Probably because I never claimed that.

gob,
@gob@mastodon.gamedev.place avatar

@litherum This machinery isn't in the standard today, and does not look appealing at all.

It solves an extra layer of complexity (mapping source to source) that simply isn't there in a format like LLVM IR or SPIR-V, where every instruction gets an integer ID.

gfxstrand, to random
@gfxstrand@mastodon.gamedev.place avatar

This week's project: Reworking NVK cbuf support. We've had a lot of issues with too much internal stalling and I think a lot of them come down to the fact that we're re-binding cbufs every draw call.

My plan for root constants, is to do inline updates with the LOAD_CONSTANT_BUFFER command. I don't know how much of a difference there is but I strongly suspect this pipelines much better.

For bound cbufs, I'm planning to just make our dirty tracking way more competent.

We'll see how it goes!

gob,
@gob@mastodon.gamedev.place avatar

@gfxstrand This reads like hell. What the hell was nvidia smoking?

Is this stuff only meant to be used in a prologue and/or maybe even vestigial ?

The whole notion of "uniformity" seems like it should be a lost cause once you have hardware that may "spontaneously" diverge and reconverge.

gob,
@gob@mastodon.gamedev.place avatar

@gfxstrand If that's really the case I wouldn't torture for making "optimal" use of it...

  • All
  • Subscribed
  • Moderated
  • Favorites
  • โ€ข
  • JUstTest
  • mdbf
  • ngwrru68w68
  • InstantRegret
  • magazineikmin
  • thenastyranch
  • rosin
  • khanakhh
  • tacticalgear
  • Youngstown
  • slotface
  • Durango
  • kavyap
  • DreamBathrooms
  • provamag3
  • ethstaker
  • GTA5RPClips
  • modclub
  • tester
  • Leos
  • osvaldo12
  • cisconetworking
  • everett
  • cubers
  • normalnudes
  • anitta
  • megavids
  • lostlight
  • All magazines
    •