Fwog and co.

[long robin]

actually I was thinking of that

how it achieves a similar result

[golden schooner]

and it adds one important bit

you cant randomly mix and call functions

you can force specific flows

similar to Frame/Render Graphisms

using it probably feels nicer too than calling functions with 20 arguments

[long robin]

perhap

[golden schooner]

😄

(i cant share the link to that message, since its in a deleted channel)

[gilded widget]

GL_NICEST coupling

[hexed bay]

https://youtu.be/cvJ2BDkcLjE?si=4TaLnZcXbfUXTFiN&t=73
Me after building a time machine so that I can slap myself for my mistakes

[golden schooner]

xD

[hexed bay]

Also I remembered this, very relevant

^ flagspeak is strong with this one

[golden schooner]

lol i got it and indeed

[long robin]

btw https://github.com/msqrt/ssgl

[heavy cipher]

undelete the treasures this instant

[golden schooner]

template hell

[heavy cipher]

hmm

ah its crap

[long robin]

rip

It is a good poc (piece of crap) though

[heavy cipher]

i had a poc (phucked obsolote code) before that relied on macro embedded glsl string

but meh i wouldn't do that crap irl

[long robin]

irl

hmm I kinda recall you talking about it

or maybe it's some kind of quantum interference with the shared neuron

[heavy cipher]

https://github.com/martty/vuk/blob/7021563ea16734fcf599818403c0a00b05204960/examples/08_pipelined_compute.cpp#L100

as you can see from the link, its an L 💯

[long robin]

The macro yelling at me means something epic is about to happen

[daring surge]

sorry, , a filepath?

if so, why? i suppose it depends on what the texture is entirely supposed to represent, i.e. a handle to the asset system, vs direct into the renderer

[long robin]

Yeah so imagine trying to create a g-buffer texture with that setup

It's just a layer below what I'd prefer to have it at

[daring surge]

oh, the only constructor is a path?

the very neat and cool thing about constructors is that you can have multiple!

[long robin]

illegal

I still don't think loading texels from a file belongs at the low level abstraction layer

[daring surge]

i think the question is whether a small-scale enough renderer can just embed the asset systeme

the renderer basically has to embed a cpu->gpu upload system

disk->gpu doesn't seem like a ton more, especially if you're not doing much with that info on the cpu

[long robin]

disk->cpu requires an arbitrarily complex decoding process though

[daring surge]

i'm not exactly sure why that's something to be scared of when renderers are out there using BC formats

if you want to keep stb out of your standalone renderer, i get it

it really depends for me what scale of renderer you're talking about

[long robin]

I'm just saying they belong at different levels of abstraction

[daring surge]

umm, okay :)

[long robin]

in the case of fwog (the channel we're in), that behavior isn't what I want

the person making the renderer should decide how they want to load textures from disk

[daring surge]

yeah i could agree with that

i think i'm thinking more on the engine-side than the lib side, that's what i meant by this ->if you want to keep stb out of your standalone renderer, i get it

if you only meant on the lib side, then we prob agree fully 🤠

[long robin]

ye

[golden schooner]

i also agree, loading images from disk belongs somewhere else

a factory 😉

[golden schooner]

i saw gracien like this one https://github.com/yslib/Cameray perhaps something for later later later later

[digital lion]

btw the FSR2 bindings were fine all along.
The FSR2 OpenGL backend was binding some UBOs and my app wasnt rebinding its UBOs. That caused the crash

@dim bluff if you are still interested https://www.nuget.org/packages/FFX_FSR2/1.0.0

[long robin]

I'm glad you figured it out 🥳

I wonder how that caused a crash though

[digital lion]

one of the UBOs was meant to contain bindless textures

[golden schooner]

oopsi

[long robin]

Ah

[digital lion]

in order for FSR2 to work correctly do I need glClipControl(GL_LOWER_LEFT, GL_ZERO_TO_ONE); because DeviceDepthNegativeOneToOne == 1 is not yet implemented?

[long robin]

Yeah although I noticed it still kinda works even if you omit that gl call

Btw if you change the clip convention you'll need to change your projection matrices

If you ever figure out the math to make the -1 to 1 convention correct please let me know lol

[digital lion]

i am afraid I wont be that guy

[long robin]

Lol yeah I tried to get criver's help and he didn't know either

The default convention is bad anyway

[digital lion]

uh what I have now is to keep the projection matrix and instead change how I convert from uv to ndc.
Like ndc = vec3(uv * 2.0 - 1.0, depth); where as before vec3(uv, depth) * 2.0 - 1.0.
This is dump right? I dont know what I am doing

[long robin]

Why not change the projection

[digital lion]

will do now

[long robin]

Also what is that code for

[digital lion]

for example when reconstructing frag pos in lighting pass

[long robin]

Oh ok

Yeah that's correct

You'll have to change that plus change the projection

I thought you were doing this in the VS instead of changing the projection lol

[digital lion]

okok

[dim bluff]

Holy shit nice

[digital lion]

9.3 ms for FSR2 on RTX 3050 Ti Laptop@FullHD

thats a lot of time

[long robin]

Yeah one of the passes runs way slower than it should. You can try profiling if you want

For whatever reason, nv optimizes the shader differently and it performs a lot worse in GL

[daring surge]

i believe that's because vulkan is faster (and better)

have you seen the benchmarks?

[long robin]

[daring surge]

there were not as many dumb gamer charts on google as i was hoping :(

[digital lion]

oh ok. Well it does perform as expected on RX 5700XT, 1ms at FullHD and Im very happy with the results. Cant even tell the difference between (0.75x + FSR2) and (Native + TAA)

[long robin]

yeah on AMD it's fine

NV perf is horrible for some reason

I profiled and there was a pass that was taking a very long time. I noticed a comment in the source code that said something needed to be {dis, en}abled to fix perf for that pass in Vulkan, but I couldn't replicated it myself

https://juandiegomontoya.github.io/porting_fsr2.html#performance

[digital lion]

interesting

[long robin]

if you want to investigate the issue yourself, that link should be a start

actually I'll make an issue so people looking at the repo are informed

[digital lion]

thats what I thought too you documented it well

[long robin]

hmm where else did I document that 👀

[digital lion]

idk

[long robin]

this won't help you but
https://github.com/JuanDiegoMontoya/FidelityFX-FSR2-OpenGL/issues/8

[digital lion]

btw I am experiencing a memory leak when recreating fsr2 context for resizing. It might have to do with my application still need to look into but getting the same behaviour in your 03_gltf_viewer

[long robin]

hmm

cpu leak?

I can't see a CPU nor GPU leak in my own application

[long robin]

my GPU readings are not precise though since I'm looking at task manager lol

ok that's interesting

which GPU?

[digital lion]

RX 5700XT, 23.9.1 driver

same behaviour on RTX 3050 Ti (tested only with my application)

[long robin]

okay I see it in my things now

I was looking at the wrong numbers

hmm yeah must be an fsr2 leak because I don't see it when fsr2 is disabled

looks like I'm properly cleaning up all GL objects at a glance

I also see no calls to new or malloc in that the backend that could leak

[golden schooner]

if (vendorId == 0x01de) { Sleep(0.1f); }

[viral haven]

I have observed similar things in the past (but not sure how correct my conclusions are) : When you resize the swapchain to a larger size, the memory usage increases (obviously since swapchain now has larger images).
As for the continuous resizing, if you leave the swapchain size unchanged for a few seconds, memory usage will stabilize

[long robin]

FYI BBK PR'd a fix for it

so it was actually a bug heh

[viral haven]

oh sorry didnt read the message on the fsr2 disabiling thing

[digital lion]

Perhaps you might want to mention your OpenGL backend here.
https://github.com/GPUOpen-Effects/FidelityFX-FSR2/issues/10

[long robin]

I'm iffy about posting it there because I don't want to make people think it's officially sanctioned

any posts of mine there could be interpreted as "official AMD" since I work there

I can see if it's chill for me to post there though

[digital lion]

ok I see. Yeah and I guess you could just point out that its a private unofficial thing

[long robin]

ye

[digital lion]

if you are not gonna do it I will : )

[long robin]

I also noticed that rys said he'd consider PRs that add GL support

I doubt such a PR would be merged tbh

it's another big chunk of code to maintain

[digital lion]

true

[long robin]

plus I didn't follow official style or follow good practice with the cmake

[heavy cipher]

needs more acronyms TBH

[long robin]

*NMA TBH (FTFY)

[heavy cipher]

OGISYFR (JK OFC ILY)

[long robin]

https://tenor.com/view/stoned-cat-stoned-cat-funny-huh-gif-19222132

[long robin]

I like when random warnings are colored red

context: trying to fix this

bruh

[rugged notch]

just a CRITICAL failure, nothing to see here

[long robin]

what the fuck, the solution to the critical errors was to add an extra magic underline after hyperlinks
https://github.com/sphinx-doc/sphinx/issues/3921

[rugged notch]

genuine insanity

most intuitive webdev system

[long robin]

yeah this lang is absolute shit

random whitespace and formatting are important syntactical constructs

like it's an error to remove the "extraneous" newline here

.. code-block:: cpp

    Fwog::RenderColorAttachments colorAttachments[] = {aAlbedo, aNormal, aMaterial};

I was getting an error for the number of dashes here not exactly matching the length of the title

`Shader.h`
---------

I pushed, and yet

rebuilt and the critical errors are back

[valid oriole]

most stable web framework

[long robin]

the error isn't even pointing to a line where it could happen

eh whatever, I'll just keep working on VSM

[golden schooner]

perchance i can take a look at it next weekend

[long robin]

it's not that important, just annoying to look at the "docs failing" on the github

[golden schooner]

yeah

[hexed bay]

top 5 repos to check
Honorable mention: Fwog

[heavy cipher]

right next to annotadted

[hexed bay]

me fail english? that's unpossible

[golden schooner]

its just tad, talking at ted, reading annotated mario assembly

[final cove]

bravo anno

[golden schooner]

excuse me jaker

but wtf is this

: D

return *new (this) Buffer(std::move(old));

Fwog/Buffer.cpp:45

[dapper gorge]

a lazy way of doing move constructors

do not do this

use the copy&swap idiom

[golden schooner]

yestergestern i learnd copy and swap

and then i see this 😄

lustri, do you implement copy & swappino properly in iris? 🙂

[dapper gorge]

yes

[golden schooner]

my man

[dapper gorge]

https://github.com/LVSTRI/IrisVk/blob/e7c0197e1cfda10ae03e22bdc84bac59ca638ebb/include/iris/gfx/clear_value.hpp#L74-L97

[final cove]

a less wacky way I've seen is to have the operator= be the 'master' and just have your move ctor be

*this = std::move(other);

[heavy cipher]

IR_CONSTEXPR

[dapper gorge]

nvcc doesn't like constexpr on some schtuff

[golden schooner]

isnt the new thing to avoid std::move?

[long robin]

It works when you have const and reference members, unlike the other methods

Idk what's lazy about it

[heavy cipher]

the c in nvcc stands for cringe

[dapper gorge]

true

ye jaker's method technically works best

[long robin]

This is in a move assignment operator btw

It's reusing the move constructor

[dapper gorge]

but it's unsightly

[long robin]

And my linter complains about it being unusual

[golden schooner]

im also slightly weirded out by your using self = buffer_t; thing lvstri

[dapper gorge]

I copied rust for that one

[golden schooner]

: )

[dapper gorge]

Rust has this nice thing where you don't need to type out the full type name everytime, you can just use Self

[golden schooner]

but im weirded out because i dont understand anything c++

yeah its common in c# too

[final cove]

I saw the C++ weekly regarding this pop up in my feed

haven't watched it yet

[final cove]

you should try the thing I posted above and reverse it

reuse the assignment operator in the constructor instead of vice versa

[heavy cipher]

wdym

[final cove]

https://www.youtube.com/watch?v=6SaUwqw4ueE

le shrug

[long robin]

I was using that before, but it doesn't work when you have const or reference members as I stated

[final cove]

oh missed that

[long robin]

You have to reconstruct the object to change em

Btw somehow I'm only learning about the copy & swap idiom now, but it doesn't seem that epic unless you're doing exception-safe programming

[heavy cipher]

schmells like bait

[long robin]

I'm srs

I mean I've probably seen it but didn't care or something

[heavy cipher]

i meant the vid, but i am willing to make an exception

[long robin]

Ah

[heavy cipher]

except it wouldn't be safe to do that, wouldn't it

[long robin]

Exceptions my beloved

[dapper gorge]

I am qualifying this convo with noexcept

[heavy cipher]

throw up;

[golden schooner]

yep, that video from jason, DR linked : )

[long robin]

totally related, I found this awesome jif

[golden schooner]

and i think some cppcon talk was talking about it too, but i dont remember which one it was

[dapper gorge]

shit

this is too real

[long robin]

Btw going to the gym can help with back pain

[dapper gorge]

I'm gonna go soon™️

[long robin]

It sure helped me

[long robin]

I know it's common to overuse std::move as if it's some kind of magic incantation to improve perf

But there aren't actually that many places where it's useful to have (and sometimes it's detrimental as pointed out)

Cargo culting is kinda fun doe

[golden schooner]

yeah

and i also wouldnt know what is cargo and what is cult

while trying to pick up some of the c++isms

[long robin]

spamming std::move probably isn't as bad as not including it where it's necessary

but it's still painful, especially since it clutters your code

[dapper gorge]

it's reassuring to know that I never wrote std::move once in my entire IrisVk codebase

it's all NRVO

[heavy cipher]

lel

[dapper gorge]

always has been

jk I probably have some moves here and there

[long robin]

Most of the time I write std::move, it's because I'm coping for a poor choice I made previously

As a fun exercise, you can ctrl+f std::move in this file and try to see how I could've avoided them
https://github.com/JuanDiegoMontoya/Frogfood/blob/main/src/SceneLoader.cpp

[golden schooner]

: )

the back to basics RAII talk on cppcon, was talking about copy and schlepp

is that something you should go for still

[long robin]

schleppy constructor

idk I never did copy+swap except maybe in school

[golden schooner]

and not write a separate schlepp function then i suppose

ah

are you a bad example then to sample from 😛 (jk)

[long robin]

Maybe

Fwog doesn't have any user defined copy constructor probably

So it's the same amount of work to just write a correct move constructor and assignment op

[golden schooner]

hmm

i dont know what a user defined copy ctor is... whats the diffrence to an ordinary copy ctor?

or do you mean = default vs non default

[final cove]

the fact you apparently can't use std::move as hints for copy ellision is annoying

[long robin]

Ye

[golden schooner]

ah

til

[final cove]

though hopefully the compiler is smart enough to do it either way

[long robin]

Default move and copy functions are perfect a lot of the time

[golden schooner]

copy elisionisms

[long robin]

Especially if the members of your class already have correct copy and move semantics

[golden schooner]

quite magical what compilers can do

[heavy cipher]

pet peeve: mixing copy elision and nrvo

[golden schooner]

nrvono

[final cove]

I mean stuff like this

I hope its smart enough to ellide the copies one way or another

[heavy cipher]

moving those floats will not do anything

its not "please optimize compiler please"

[final cove]

hopefully the compiler will hear my prayer iether way 🙏

[long robin]

God is dead and we killed him

[dapper gorge]

true and real

[heavy cipher]

this time i will not comment '*gob' 😳

[final cove]

poor lifetime management

[golden schooner]

good deadtime management

[long robin]

if only they called it rvalue_cast like it really is

[heavy cipher]

dingus_cast pls

[heavy cipher]

this would help the difference set of people who don't understand what move does but know what an rvalue is (the empty set)

[long robin]

speaking of which, @golden schooner
https://scryfall.com/search?q=dingus

[long robin]

But at least people won't be tricked by the name into thinking it performs some kind of magic

[dapper gorge]

by the law of big numbers there is at least one person who fits this description

[final cove]

I wrap all my calls in std::magic just in case

[heavy cipher]

current name move (too magical)
new name: cast (not magical)
alr

[long robin]

std::shrooms

[final cove]

if you tell me its a no-op I won't believe you

[dapper gorge]

what if it's a magic noop

[long robin]

std::move_but_pls_read_the_docs_before_using

[heavy cipher]

your case 7 up there is dingus_cast

[final cove]

if it wasn't magic why would I be casting it?

checkmate

[long robin]

case 7 could go in the iceberg

as a symbol

[heavy cipher]

whats the ETA for this year's frozen treat

[final cove]

last year's was 12/19 iirc

[long robin]

sometime around christ mass probs

[heavy cipher]

dunno what christ mass is, but christ density is very low since he walked on water

[long robin]

man did you know that you can express acceleration as pounds per kilogram

[final cove]

which is a constant 2.2, and that's why the universe is constantly accelerating outwards

[long robin]

pounds (force) / kilograms (mass) = acceleration

[dapper gorge]

oh wow

fisics

[heavy cipher]

you can express 1.151 as mile / mile

[long robin]

https://en.m.wikipedia.org/wiki/Pound_(force)
https://en.m.wikipedia.org/wiki/Pound_(mass)

[dapper gorge]

I will personally kill all imperial users

[long robin]

you could also express acceleration as pounds per pound if you're unhinged enough

[heavy cipher]

just don't look up pressure

fucking torr, psi, bar

[long robin]

number of open jira tickets is my favorite

[dapper gorge]

there are only two necessary pressure units

pascal and atm

no need for more

[heavy cipher]

your honor, that comment

[final cove]

mmhg

[dapper gorge]

I measure my blood pressure in hPa

fight me

[snow sun]

i imagine this is deccer reading gp

[golden schooner]

https://tenor.com/view/sinnlos-im-weltraum-fiese-fresse-siw-gif-27283330

@snow sun 😄

[snow sun]

[hexed bay]

Several random questions I have about fwog (sorry if was asked before)

1. How does it compare to other GL wrappers? I've seen a few of them around but not sure if there are some quality ones
2. If I made something similar in 3.3, how much different would it be?
3. If I suddenly wanted to change to a different API (e.g. webgpu or Metal, idk), how much pain would it be? Do you need even more abstractions to make it easier for yourself?

[golden schooner]

1. its not just your ordinary Texture, Shader, Buffer abstraction, its a toolset to let you define renderpasses and pipelines (graphics/compute) opengl state is somewhat hidden from you and you dont have to manage fbos either. you still can use raw gl here and there where you think its necessary

2. not much, Fwog is just using DSAisms where possible, and you wont have kompoot in 3.3

3. fwog is very tied to gl as it is, but given its architecture as mentioned in 1) it "shouldnt"(tm) be too hard to switch to something else

[golden schooner]

idk what you are trying to say martty

[long robin]

I think he's making a frog face

According to sources

[golden schooner]

. _ .

[long robin]

Idk if I've seen a "good" gl wrapper besides the one in erhe

[golden schooner]

the ones im aware of are just glX wrapped in classes 1:1

[long robin]

Most of them are your classic buffer, texture, etc. abstraction with non-existent move semantics

AKA what beginners make

So yeah fwog is that but it also has pipelines and "render passes" to minimize the amount of global state that needs to be touched

Uh oh there is some oldism in the docs (non-lambda render pass example)
https://fwog.readthedocs.io/en/latest/pipelines.html

[golden schooner]

good times hehe

[long robin]

Too bad the docs inexplicably no longer build

Anyways @hexed bay if you want an annotated example, check my le triangle
https://github.com/JuanDiegoMontoya/Fwog/blob/a190998a24c32df63849981c803ec26d6dbbbfb3/example/01_hello_triangle.cpp

As far as abstractions go, it's pretty thin (there is a lot of low-hanging fruit in OpenGL), and most of it could be recreated in GL 3.3 with slightly more effort

So basically what deccy said

The most "radical" (not if you ever saw d3d12 or Vulkan) thing it does is 360 noscope the global state

Also, this post is the precursor to fwog
https://juandiegomontoya.github.io/modern_opengl.html

A lot of handy modern gl features aren't difficult to emulate with a 3.3 wrapper

[hexed bay]

What are your thoughts on more abstractiony abstractions? E.g. bgfx, magnum, etc. 😄

[tired sandal]

Fwog is my go-to abstraction for ogl.

[long robin]

I don't have many

I "tried" bgfx once and wasn't too impressed, though I don't benefit much from its cross-platformness

In general you lose nice features as you start to support more APIs and lock yourself into the least common denominator

[golden schooner]

bgfx feels weird

[long robin]

Building bgfx is a massive pain in the a$$ too

[golden schooner]

it feels like a "better" raylib

[long robin]

Or at least that's how it appeared when I saw my colleague do it in college

[golden schooner]

but can probably do more

[long robin]

It seems lower level to me

But it has some random high levelisms that feel random

I'm not the best person to comment on it though

Personally the two kinds of abstractions I'm vaguely aware of are near-1:1 abstractions like Fwog, and render graphs

[heavy cipher]

how fwog compares to other wrappers

[long robin]

(B

[signal widget]

That sums up pretty much my experience with it. Tried installing it, struggled, then decided it wasn't worth it.

[hexed bay]

Did you try any other gfx abstraction libs?

[signal widget]

Does Ogre count ? 🤔

Was a long time ago tho

(I don't think I tried any other otherwise, but I got tired of C++ as well so that didn't motivate me to try more)

[hexed bay]

Mike Acton roasted Ogre, so it’s dead to me now

Tfw you love glm so much, you stop using standard types

[hexed bay]

My first reaction: where VBO

[signal widget]

He did it on Ogre 1, Ogre 2 addresses many things if I'm not mistaken.

[hexed bay]

Btw, he’s doing streams on his Substack on porting a Unity game to C++ (it’s pure C) for now
And I’m so impressed by his programming powers. It’s truly next level skills: 😂

[signal widget]

Ha interesting

[hexed bay]

It looked like this for 20+ hours though
He wasn’t kidding when he said "data oriented design" 😂
(He then writes a script which exports spreadsheet into a binary file and even generates a header to read it without parsing)

[golden schooner]

vertexPosBuffer

[hexed bay]

I read fwog examples before, and now I understand a lot more. But kinda think that I’ll live with more immediate more rendering for now 🙂
Pipelines are cool, but I think that reimplementing this would lead me to make fwog 2 (instead of making an actual game ) 😅

Gotta say that fwog features some of the cleverest (in good sense) C++ code I’ve seen. My code is like C++98 in comparison

[golden schooner]

pipeline is nothing else but grouping state calls to prepare draws/computedispatch

[hexed bay]

Yeah, it makes sense to me, but I feel like it requires a lot of abstractions/code to make it flexible enough compared to (almost) raw gl calls

[golden schooner]

not really

and it depends 🙂

if you have tons o f effects where a horde of fbos is involved, then you have more BeginRendering/EndRender sections

when more shaders are involved then you have more pipelines to setup, but all that setup is abstracted away nicely

[long robin]

Yeah I don't do cringe vbo classes

[long robin]

Fr I'm not even convinced myself that pipelines are the endgame

They are useful for the way I use gl

[daring surge]

its better than

[hollow crystal]

Have you guys tried LLGL yet

[long robin]

I haven't

idk if I've seen this one

[long robin]

(needed this emoji for another server)

[golden schooner]

banana's low level gl libraryframework thing its quite old as in around for some time

[hexed bay]

fwog Emscripten when
You must experience how bad Emscripten/WebGL/OpenGL ES are

[long robin]

is it even possible

[golden schooner]

i can make elias disappear

with connections in Berlin

[burnt fog]

Jesus Christ,why so many switches in ApiToEnum

[golden schooner]

because there are a lot of values in a lot of domains to cover

[burnt fog]

but they dont include all Format enums.Like isFormatNormalizedGL does not include compressed formats

[golden schooner]

yeah because its most likely not necessary in that case

and possibly jaker is just a lazy bum and didnt add all formats back when, before adding compression support when loading ktx : >

if you have code relying on missing formats, feel free to send a PR

[burnt fog]

planning to encode almost everything inside 32bits

[golden schooner]

: >

[burnt fog]

im half way though

[golden schooner]

GL_LUMINANCE is probably not needed

if thats where you are coming from

[burnt fog]

im coming from this point that he cant have all this stuff in his head, adding format to a hundred enums

[golden schooner]

i mean they are all defined : )

but were probably not necessary

half of it is part of legacy opengl, which fwog isnt exactly supporting anyway

[burnt fog]

starting to wonder what looks better

[golden schooner]

i understand why you (would) format it like that

but i find it ugly, personally

if you want to PR then stick with the style of the project

[long robin]

Because compressed formats don't make sense for vertex attributes

[long robin]

This is also sometimes true

However, I think I just copied valid vkFormats where necessary

If I made Fwog again, I'd just get rid of all the vertex attrib stuff which would simplify that file greatly

[golden schooner]

yep i wasnt serious here either

i sometimes wonder when VP became a thing and why John didnt come up with it himself back then already to push card manufacturers to support this sort of stuff

[tired sandal]

I am trying to install Fwog via xmake (by using cmake import)

         C:\Users\Raildex\AppData\Local\.xmake\cache\packages\2404\f\fwog_git\v0.2.1\source\src\Fence.cpp(40,43): error C2039: 'numeric_limits': is not a member of 'std' [E:\2drpg\build\.packages\f\fwog_git\v0.2.1\cache\build_70a1113b\fwog.vcxproj]
         C:\Users\Raildex\AppData\Local\.xmake\cache\packages\2404\f\fwog_git\v0.2.1\source\src\Fence.cpp(40,58): error C2275: 'GLuint64': expected an expression instead of a type [E:\2drpg\build\.packages\f\fwog_git\v0.2.1\cache\build_70a1113b\fwog.vcxproj]
         C:\Users\Raildex\AppData\Local\.xmake\cache\packages\2404\f\fwog_git\v0.2.1\source\src\Fence.cpp(40,69): error C2039: 'max': is not a member of '`global namespace'' [E:\2drpg\build\.packages\f\fwog_git\v0.2.1\cache\build_70a1113b\fwog.vcxproj]
         C:\Users\Raildex\AppData\Local\.xmake\cache\packages\2404\f\fwog_git\v0.2.1\source\src\Fence.cpp(40,69): error C3861: 'max': identifier not found [E:\2drpg\build\.packages\f\fwog_git\v0.2.1\cache\build_70a1113b\fwog.vcxproj]
         C:\Users\Raildex\AppData\Local\.xmake\cache\packages\2404\f\fwog_git\v0.2.1\source\src\Fence.cpp(38,21): error C2198: 'PFNGLCLIENTWAITSYNCPROC': too few arguments for call [E:\2drpg\build\.packages\f\fwog_git\v0.2.1\cache\build_70a1113b\fwog.vcxproj]

Did you forget to add WIN32_LEAN_AND_MEAN? and NOMINMAX?

[long robin]

hmm I thought I fixed that issue

[tired sandal]

i am using v0.2.1

[long robin]

ah

try pulling from the latest on main

[tired sandal]

does fwog use glad internally, or do i have to load the functions myself?

i receive an access violation on Fwog::Initialize and wondered whether its because i do not load glad.

Initializes Fwog’s internal structures.

Call at program start to initialize Fwog’s internal state. Must be called after an OpenGL context has been acquired.

To create a Fwog (context), you will first need an OpenGL 4.6 context (e.g., one created with GLFW) and have loaded OpenGL function pointers in the appropriate location. Then, you can call Fwog::Initialize().

[long robin]

you are expected to load gl functions yourself via glad or some other means, then provide the gl headers. however, glad's gl header is used by default and fwog vendors glad so you should be able to just use it

let me see what I do in my own project

ye looks like fwog exports lib_glad in cmake so you should be able to link that to your project if you don't want to vendor it yourself
target_link_libraries(MyRenderer PRIVATE lib_glad)

then you just need something like this before you initialize fwog

#include FWOG_OPENGL_HEADER
...
int version = gladLoadGL(glfwGetProcAddress);
if (version == 0)
{
  glfwTerminate();
  throw std::runtime_error("Failed to initialize OpenGL");
}

hmm you might not need to explicitly link glad in your project since fwog already does it . I think you just need to include FWOG_OPENGL_HEADER or <glad/gl.h> (which is what FWOG_OPENGL_HEADER expands to by default)

[golden schooner]

i think lib_glad needs to be linked publicly then by fwog

[long robin]

idk what the default visibility is, but fwog does this
https://github.com/JuanDiegoMontoya/Fwog/blob/main/CMakeLists.txt#L88

[golden schooner]

i believe i had that "problem" in my cmake-starter template thing

[tired sandal]

should be public, otherwise I can't find it's headers

[long robin]

target_link_libraries(<target> <item>...)

Library dependencies are transitive by default with this signature. When this target is linked into another target then the libraries linked to this target will appear on the link line for the other target too.

should be good then

[wind jasper]

is this for an older version of glad? I had to do this:

add_subdirectory(${FASTGLTF_DEPS_DIR}/glad/cmake glad_cmake)

glad_add_library(fg_glad_gl46 REPRODUCIBLE EXCLUDE_FROM_ALL LOADER API gl:core=4.6)

target_link_libraries(fastgltf_gl_viewer PRIVATE fg_glad_gl46)

[long robin]

glad is vendored

er, the generated headers + source are

[long robin]

@tired sandal did you manage to fix your issue with glad?

[tired sandal]

kinda. Since I am using xmake i had to resort to putting glad into my source tree

[long robin]

ah I am unfamiliar with xmake

[tired sandal]

since glad is mandatory anyway, why isn't it automatically initialized in Fwog::Initialize?

[long robin]

vendoring glad's files is perfectly fine though

[tired sandal]

I prefer not to care about opengl extensions and let Fwog handle it

[long robin]

it's for flexibility. the user may already be loading opengl functions and/or use another header for it

I did think about it last night. I think using glad's loader by default (but still offering an option to disable that) would help

in fact I can add that right now

[tired sandal]

would you accept a xmake.lua PR?

would be CMakeLists equivalent for xmake

[long robin]

uh maybe, but I won't be able to maintain it probably

you could make a PR and then I could link to it in the readme instead of merging it

if it's frozen in time then I won't accidentally break the xmake build in the future

ugh I need to make Fwog::Initialize take a pointer to the load function

at least I won't need a compile-time option

[tired sandal]

how would that load function look like?

std::function<void()> ?

[long robin]

  using ApiProc = void (*)(void);

  using ApiLoadFunc = ApiProc (*)(const char* name);

  struct ContextInitializeInfo
  {
    ApiLoadFunc glLoadFunc = nullptr;
    ...
  };

then you just pass glfwGetProcAddress or it won't load the functions

[tired sandal]

Sounds good to me

[long robin]

@tired sandal pushed

  Fwog::Initialize({
    .glLoadFunc = glfwGetProcAddress,
  });

hrm you will still need the gl headers if you want to make your own debug callback

[tired sandal]

Fwog::ContextInitializeInfo init_info{
    .glLoadFunc = glfwGetProcAddress,
    .verboseMessageCallback = [](std::string_view msg){
        rpg::logd("[Fwog] %s\n", msg.data());
    }
};

and it fucking works without linking glad now

bye bye glad

[long robin]

epic

[tired sandal]

thank you very much!

[golden schooner]

Hmm Jaker my frog

i was wondering if it makes sense to move the INFER_FORMAT values out of UploadFormat/UploadType and make the UploadFormat/UploadType std::optionals in CopyBufferUploadInfo instead

per chancekowski i should just fiddle a PR together

[long robin]

I think I prefer this

The current design I mean

std::optional slightly obfuscates it imo

[golden schooner]

oki

[long robin]

3:33

I find it interesting that OpenGL debug labels can be null terminated or explicit length, but Vulkan's are only null terminated

That means I can't use string_view for Vulkan

Seems like a step back imo

[golden schooner]

: (

[golden schooner]

didnt know there was a part 2 of galuga

[long robin]

made using proto-fwog: #wip message

[robust bough]

@tired sandal you only need glfw / fwog?

or do i still need another library to load stuff

[tired sandal]

GLFW and Fwog is the only thing you need now.

[robust bough]

epic

[tired sandal]

ikr

[robust bough]

Does anyone know if I'm missing something here?

    while (!glfwWindowShouldClose(window)) {
        Fwog::RenderToSwapchain({
                                    .viewport = Fwog::Viewport{.drawRect{.offset = {0, 0}, .extent = {1920, 1080}}},
                                    .colorLoadOp =  Fwog::AttachmentLoadOp::CLEAR,
                                    .clearColorValue = {.1f, .2f, .4f, 1.0f},
                                },
                                [&] {
          
                                });
        glfwPollEvents();
    }```

Im just trying to clear the window for now

[tired sandal]

whats happening?

[robust bough]

nothing

the window is just white

[tired sandal]

did you setup Fwog correctly?

[robust bough]

this is my entire program

int main() {
    auto info = Fwog::ContextInitializeInfo {
        .glLoadFunc = glfwGetProcAddress,
        .verboseMessageCallback = [](std::string_view msg) {
            std::cout << msg << std::endl;
        }
    };
    glfwInit();

    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 6);
    auto window = glfwCreateWindow(1920, 1080, "CFD", nullptr, nullptr);
    glfwMakeContextCurrent(window);

    Fwog::Initialize(info);

    while (!glfwWindowShouldClose(window)) {
        Fwog::RenderToSwapchain({
                                    .viewport = Fwog::Viewport{.drawRect{.offset = {0, 0}, .extent = {1920, 1080}}},
                                    .colorLoadOp =  Fwog::AttachmentLoadOp::CLEAR,
                                    .clearColorValue = {.1f, .2f, .4f, 1.0f},
                                },
                                [&] {

                                });
        glfwPollEvents();
    }

    return 0;
}```

[tired sandal]

you need error checking lol

[robust bough]

;-;

right

[tired sandal]

    void on_error(int error_code, const char* description) {
        loge("[GLFW ERROR %d] %s\n",error_code,description);
    }
    GLFWwindow* create_glfw_window() {
        if(glfwInit() != GLFW_TRUE) {
            return nullptr;
        }
        //...//
        glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_API);
        glfwWindowHint(GLFW_CONTEXT_CREATION_API, GLFW_NATIVE_CONTEXT_API);
        glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
        glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR,6);
        glfwSetErrorCallback(on_error);
        return glfwCreateWindow(800, 600, "Test", nullptr, nullptr);
    }
    void destroy_glfw_window(GLFWwindow* window) {
        glfwDestroyWindow(window);
        glfwTerminate();
    }
    void on_window_should_close(GLFWwindow* window) {
        glfwSetWindowShouldClose(window, GLFW_TRUE);
    }
    std::expected<std::unique_ptr<GLFWwindow,void(*)(GLFWwindow*)>,error_code> create_window() {
        auto window = std::unique_ptr<GLFWwindow, void(*)(GLFWwindow*)>(create_glfw_window(),destroy_glfw_window);
        if(!window) {
            return std::unexpected<error_code>(error_code::glfw_create_window);
        }
        glfwSetWindowCloseCallback(window.get(),[](GLFWwindow* w){
            glfwSetWindowShouldClose(w, GLFW_TRUE);
        });
        glfwSwapInterval(1);
        glfwMakeContextCurrent(window.get());
        return window;
    }

int main() {
    auto window = rpg::create_window();
    if(!window) {
        //...//
    }
    glfwShowWindow(window->get());
    Fwog::ContextInitializeInfo init_info{
        .glLoadFunc = glfwGetProcAddress,
        .verboseMessageCallback = [](std::string_view msg){
            rpg::logd("[Fwog] %s\n", msg.data());
        }
    };
    Fwog::Initialize(init_info);
    //...//
    float accumulator = 0.0f;
    while(!glfwWindowShouldClose(window->get())) {
        glfwPollEvents();
        //...//
        glfwSwapBuffers(window->get());
    }
    Fwog::Terminate();
}

[tired sandal]

@long robin Fwog::Render takes a const std::function<void ()> & func.
Wouldn't be a std::invocable<void()> or a template<typename Func> (if no concepts) better?

[long robin]

I think I used std::function instead of a template so I could avoid putting the function definition in the header

[tired sandal]

ah I see. Makes sense. I wouldn't leak that as well

[tired sandal]

@long robin Any chance to add SPIRV shader compilation?

[long robin]

can you elaborate

[tired sandal]

I have a spirv file that contains multiple entry points.

[long robin]

yeah I could whip something up

[tired sandal]

in plain OGL, I would use glShaderBinary and glSpecializeShader

[long robin]

right now the interface accepts this struct, but the string view is a little problematic if I want to add spirv support

  struct ShaderSourceInfo
  {
    /// @brief Specifies the language of the source string
    SourceLanguage language = SourceLanguage::GLSL;
    /// @brief A GLSL or C++ source string
    std::string_view source;
  };

I could just make it so you treat the string view as a span of bytes for your spirv module, but that seems kinda meh

meh I'll just make another struct for spirv specifically

[wind jasper]

also needs a entry point string

[long robin]

yep

that's why another struct is in order

[wind jasper]

idk what source languages you support but there could be multiple entry points there, too

[long robin]

eh true, vcc supports it

but spirv is the only one with spec constants

I could just not support those however

@tired sandal do you need spec constants?

actually I can just put spec constants in and have them do nothing if you're not targeting spirv

[tired sandal]

I guess it would be convenient to have them at some point

[tired sandal]

that sounds less error-prone

[long robin]

ok, I got a spirv triangle in fwog

the API is probably good enough

@tired sandal I pushed spirv support. let me know if there are any issues

[tired sandal]

wtf

how fast

[long robin]

I've got nothing better to do

[tired sandal]

@long robin I think you are missing a
#if FWOG_VCC_ENABLE==1
in Shader.cpp

the constructor is not declared and ShaderCppInfo is not defined when FWOG_VCC_ENABLE is 0

  #if FWOG_VCC_ENABLE == 1
  Shader::Shader(PipelineStage stage, const ShaderCppInfo& cppInfo, std::string_view name)
  {
    const auto glsl = detail::CompileShaderCppToGlsl(cppInfo.source);
    id_ = detail::CompileShaderGLSL(stage, glsl);

    detail::ValidateShader(id_);
    if (!name.empty())
    {
      glObjectLabel(GL_SHADER, id_, static_cast<GLsizei>(name.length()), name.data());
    }
    detail::InvokeVerboseMessageCallback("Created shader with handle ", id_);
  }
  #endif

This compiles

[long robin]

Damn, I knew I should've tested with the define disabled

I'm in bed now so I'll fix it tomorrow

[golden schooner]

let raildex send in a PR

[long robin]

He can keep the bandaid until I push my fix. It'll be easier I think

[tired sandal]

https://github.com/JuanDiegoMontoya/Fwog/pull/101

[tired sandal]

are spirv binaries really integers and not bytes?

[wind jasper]

yes 32-bit words

[tired sandal]

I am trying to compile the following spirv file:

Fwog::ShaderSpirvInfo spirv_vertex{"vertex",spirv_span};
Fwog::ShaderSpirvInfo spirv_fragment{"pixel",spirv_span};
auto fullscreen_vertex = Fwog::Shader(Fwog::PipelineStage::VERTEX_SHADER,spirv_vertex,"fullscreen_vertex" );
auto fullscreen_fragment = Fwog::Shader(Fwog::PipelineStage::FRAGMENT_SHADER,spirv_fragment,"fullscreen_fragment" );
Fwog::GraphicsPipelineInfo info {
    "Fullscreen",
    &fullscreen_vertex,
    &fullscreen_fragment,
    nullptr,
    nullptr,
    {Fwog::PrimitiveTopology::TRIANGLE_LIST},
    {},
    {},
    {
        true,
        Fwog::PolygonMode::FILL,
        Fwog::CullMode::BACK,
        Fwog::FrontFace::COUNTERCLOCKWISE,
        false,
        0.0f,
        0.0f,
        0.0f,
        0.0f,
    },
    {},
    {false,false},
    {},
    {}
};

But I receive a linker error.
Maybe I am missing something?

[long robin]

I'm investigating this rn

btw I suggest using designated initializers for GraphicsPipelineInfo so you don't have to specify everything (everything defaults to zero, null, or some other sane value)

so I am unable to compile the vertex shader

  auto [ptr, size] = Application::LoadBinaryFile("shaders/fullscreen.spirv");
  auto code = std::span{reinterpret_cast<const uint32_t*>(ptr.get()), size / sizeof(uint32_t)};
  auto vertexInfo = Fwog::ShaderSpirvInfo{.entryPoint = "vertex", .code = code};
  auto fragmentInfo = Fwog::ShaderSpirvInfo{.entryPoint = "pixel", .code = code};
  auto vertexShader = Fwog::Shader(Fwog::PipelineStage::VERTEX_SHADER, vertexInfo, "Triangle VS");
  auto fragmentShader = Fwog::Shader(Fwog::PipelineStage::FRAGMENT_SHADER, fragmentInfo, "Triangle FS");

I get a bunch of (0) : error C8001: SPIR-V: Invalid opcode followed by (0) : error C8006: SPIR-V: Invalid entry point vertex

I get essentially the same errors with the fragment shader

can you show how you are loading the spirv from the file? alternatively, you could send an array of hex literals that I can simply paste into my code

[golden schooner]

i cant read

but if you deconstruct binary it would look neater [shaderBlob, shaderBlobLength]

no .first and .second isms

[long robin]

ok

[golden schooner]

is the spirv file blocked by the os perchance?

since it was downloaded from an obscure source

[long robin]

I can see that there are 1234*4 bytes in the loaded data

[golden schooner]

ah

[long robin]

hmm

I noticed that there is nonsemantic debug/source info in the spirv. I wonder if that's an issue

but raildex has apparently gotten the shaders to compile, so idk

[golden schooner]

maybe not with the opengl semanticle

maybe those are vulkan glsl spirveeticles

[long robin]

raildex and I are ostensibly both using the same spirv and loading it into gl

[golden schooner]

using the same version of the tools?

[long robin]

what tools

[golden schooner]

my understanding is, raildex gets a linker error

[long robin]

only thing that might be different is the cpp code, the spirv itself, or the os/gpu/driver

[golden schooner]

and you get one too

[long robin]

I get a compile error

[golden schooner]

oh

[long robin]

it can't specialize the shader

[golden schooner]

mayhaps they mispelled that one

and the spv is just not made for opengl glsl, but vulkan glsl

[long robin]

raildex is using fwog though, which is gl

[golden schooner]

yes, but only feeding it binary spvs?

[long robin]

ye

[golden schooner]

so

when you use glslangvalidator to cook spv, you need to specify that you want to cook for opengl or not

[long robin]

I can see how it was compiled

raildex is using slang

[golden schooner]

-G missing

[long robin]

anyways I presume it's opengl-viable since he was apparently able to get it to specialize

maybe not

[golden schooner]

ah wait, -G is for glslangvalidotor

[long robin]

yeah this is slang

[golden schooner]

ye

[long robin]

I'm guessing raildex shared different spirv than what he tried

I'll just wait

[golden schooner]

also no hint of opengl in slang cli reference

[long robin]

spooky

I think slang has a way to output glsl too, but I'd guess it's vulkan glsl

[golden schooner]

perchance its worth to compile whatever glsl with the slang competitor and see if that wor.... ah nvm, as you said, wait for raildex

[tired sandal]

sry, i can send you the file today evening, since i am not at home. I use the profile glsl_460 and target spirv . but i do not specify entrypoints.

i had the impression i can have multiple entry points for glsl, since glSpecializeShader can specify them

[long robin]

it's not glsl though, but multiple entry points are allowed in spirv

I think the glsl spec says only main is allowed as the entry point, but

• glslang (glsl->spirv) ignores that
• you're compiling to spirv so it shouldn't matter anyway

[tired sandal]

so, what do you need? @long robin

struct vertex_out {
    float4 screen_pos : sv_position;
    float2 texture_coord;
};

struct pixel_out {
    float4 color : sv_target0;
};

[shader("vertex")]
vertex_out vertex(uint vertex: sv_vertexid) {
    vertex_out output;
    output.texture_coord = float2((vertex << 1) & 2, vertex & 2);
    output.screen_pos = float4(output.texture_coord * float2(2, -2) + float2(-1, 1), 0, 1);
    return output;
}

Texture2D texture;
SamplerState sampler;

[shader("pixel")]
pixel_out pixel(vertex_out input) {
    pixel_out output;
    output.color = texture.Sample(sampler, input.texture_coord);
    return output;
}

This is fullscreen.slang

And the compile args:
compileargs = {"-lang","slang","-profile","glsl_460" ,"-target" ,"spirv","-g3", "--",path.absolute(sourcefile_bin) }

-lang slang -profile glsl_460 -target spirv -g3

[long robin]

The spirv you sent earlier wouldn't specialize when I tried to reproduce your linker error, so I wanted to be sure it was the right spirv

I am on a 3070 with the latest Windows drivers

[tired sandal]

its definitely the same spirv i use

[long robin]

What gpu+driver are you using?

Also can you send me an array of bytes or uint32 so I can be sure it wasn't an issue loading the code on my end

[tired sandal]

wouldn't the Fwog::ShaderSpirvInfo throw an error if the spirv data would be wrong?

or rather the Shader Objects

[long robin]

Yeah I get an error when trying to create the shader

But you get the error when linking

I'm trying to figure out why

[tired sandal]

little vs big endian?

spirv is little endian iirc

[golden schooner]

[deccer@rootfs tmp]$ $VULKAN_SDK/bin/glslang -lang slang -profile glsl_460 -target spirv -g3 ./test.hlsl 
/home/deccer/Storage/Tools/Vulkan/1.3.268.0/x86_64/bin/glslang: Error: -profile: unrecognized command-line option (use -h for usage)

ah you are on windows, neh?

[tired sandal]

glslang?

[golden schooner]

is slang yet another thing? 🙂

[tired sandal]

ye

[golden schooner]

shiet

[tired sandal]

this is my "binary to spirv" conversion:

spirv convert_binary_to_spirv(const std::span<const unsigned char> binary) {
        auto target_size = binary.size() / sizeof(std::uint32_t);
        auto ptr = std::make_unique_for_overwrite<std::uint32_t[]>(target_size);
        std::memcpy(ptr.get(),binary.data(),binary.size()); // UB?

        return spirv{.binary= std::move(ptr),.count = (unsigned int)target_size};
    }

[golden schooner]

interesting

when i run it i get no binary spv, but the spv as text

[long robin]

what the heck is make unique for overwrite

[tired sandal]

it skips default initialization

c++23 i think

[long robin]

Ok I see

[tired sandal]

looks binary to me @golden schooner

the text is just debug info, isn't it?

[long robin]

Ye

Let me get out of bed to try this schtuff

[tired sandal]

@long robin do you have a spirv file i can test?

[golden schooner]

i piped it into test.spv

[long robin]

It's just the one you sent lol

[golden schooner]

slangc v2024.1.18

[tired sandal]

maybe vblanco knows, something, he recommended slang to me

[golden schooner]

their wiki is also legendary

[long robin]

I thought you were embedding the spirv as bytes in your program

[tired sandal]

I am

[long robin]

Can you send it

The array

[tired sandal]

wait a sec maybe I am doing something wrong then?
the spirv file i sent is binary, isn't it?

[long robin]

I'm loading the spirv as a file and fear I screwed it up

You're getting farther by having a linker error in the pipeline. My shaders won't even specialize correctly

[long robin]

Hmm

I meant the c++ code, like an array of uint32 or char

[tired sandal]

thats gonna be difficult because this stuff is auto generated 😄

[long robin]

Epic

https://tenor.com/view/undertaker-still-alive-back-from-the-dead-gif-14592821

I'm getting on my computer now

[tired sandal]

sorry for the inconvenience

[golden schooner]

xxd and hexdump can do that if you are on a linuxlike

[long robin]

It's past noon, I need to get up lol

[golden schooner]

https://tenor.com/view/morning-wake-yo-ass-up-wake-up-get-up-gif-16653947

[tired sandal]

i wrote this tool myself and i love it

[heavy cipher]

its before noon somewhere in the world

[long robin]

True

https://tenor.com/view/i-sleep-meme-sleep-meme-go-sleep-sleepi-ng-gif-26260737

[golden schooner]

https://tenor.com/view/wake-up-good-morning-hooman-gif-23759566

[long robin]

so I get the same invalid spirv opcodes and entry point as before

what's the error you're getting exactly?

[tired sandal]

GraphicsPipelineCompilationException

[long robin]

weird

what gpu are you on?

also can you show what's in the info log/exception message

[tired sandal]

Amd Radeon RX 7900 XT

[tired sandal]

unknown reason

[long robin]

ok that could explain the discrepancies

[tired sandal]

Linking fails for unknown reason

[long robin]

PS H:\Repositories\Fwog\example\shaders> spirv-val.exe --target-env opengl4.5 .\fullscreen.spirv
error: line 0: Invalid SPIR-V binary version 1.5 for target environment SPIR-V 1.0 (under OpenGL 4.5 semantics).

without --target-env opengl4.5 it passes

I am pretty sure you can use higher spirv versions with opengl though

[heavy cipher]

nah

the required support level is 1.0

[long robin]

Implementations must support the 1.0 version of SPIR-V and the 1.0 version of
the SPIR-V Extended Instructions for the OpenGL Shading Language (see sec-
tion 1.3.4).

it's so joever

[heavy cipher]

it never bidentered

[long robin]

why does glslang support --target-env opengl --target--env spirv1.6 then

wtf does that do

[heavy cipher]

it makes the error machine go brrr

[long robin]

bababoment

well I guess that's your issue @tired sandal

can slang emit spir-v 1.0?

[golden schooner]

A capability describes an optional feature that a target may or may not support. When a -capability is specified, the 
compiler may assume that the target supports that capability, and generate code accordingly.

  spirv_1_{ 0, 1, 2, 3, 4, 5 }: minimum supported SPIR - V version
...

[long robin]

is this from the slang wiki

[golden schooner]

from slangc -h

[long robin]

cool, raildex should try that

[golden schooner]

[deccer@rootfs ~]$ ~/Tools/slang/bin/linux-x64/release/slangc -lang slang -profile glsl_460 -target spirv -g3 -capability spirv_1_0 /tmp/test.hlsl > test.spv

that spits out an actual binary here

[tired sandal]

lemme try

[long robin]

is this raildex's code

[golden schooner]

yes

[long robin]

rip it still fails with invalid opcodes

[golden schooner]

is binary spv portable like that?

[long robin]

I don't see why not

it's supposed to be shipped with apps

[tired sandal]

@golden schooner there is no difference between your file and my file.

[long robin]

hmm you're right, the only difference is the path that's embedded

[golden schooner]

weird

[tired sandal]

I use this
https://www.khronos.org/spir/visualizer/

[golden schooner]

ran it on a rtx4070 if that matters

[heavy cipher]

λ spirv-dis.exe test.spv
; SPIR-V
; Version: 1.5

womp womp womp

[golden schooner]

: )

A capability describes an optional feature that a target may or may not support. When a -capability is specified, the 
compiler may assume that the target supports that capability, and generate code accordingly.

  spirv_1_{ 0, 1, 2, 3, 4, 5 }: minimum supported SPIR - V version
  Invalid
  textualTarget
  hlsl
...

[long robin]

so perhaps -capability spirv_1_0 is broken

🇭🇲

[heavy cipher]

PDD (potrick driven development) strikes again

[long robin]

prepare for RDD

raildex is probably the literal first person to try using slang for opengl

btw can't slang emit glsl?

[golden schooner]

have PDiDdy create an issue

[golden schooner]

i think it can

[long robin]

inb4 it uses vulkanisms only

[golden schooner]

nice -target glsl doesnt do anything though 😄

no error either

[long robin]

[golden schooner]

ah there it is

[long robin]

pls send

[long robin]

gl_VertexIndex
it's bover

[heavy cipher]

truly we must embrace: slang (spv 1.5) -> spirv-cross (glsl) -> glslang (spv 1.0)

[long robin]

and separate textures and samplers

[golden schooner]

there is also glsl_spirv_1_0

whatever that is

[tired sandal]

i tried all the spirv_1_0 capabilities and it does not change anything

[heavy cipher]

because they specced it as a minimum cap smh

[golden schooner]

you cant even pipe slangc -h into a file 🇹🇫

[long robin]

this is khronos punishing us for trying to use something other than glsl

[golden schooner]

it wouldnt surprise me if John had his fingers in slang too, just didnt tell anyone

[tired sandal]

welp, I guess slang is done for me then.
Thanks guys. Guess I am doomed writing GLSL then

atleast Fwog has SPIRV support now

[long robin]

I think you or deccer should open an issue or two in the slang repo

it seems like it wouldn't be much effort for them to properly support opengl

[heavy cipher]

also i may have posted it as a meme, but tripping through spirv-cross does work

[golden schooner]

yop

[deccer@rootfs ~]$ $VULKAN_SDK/bin/spirv-cross /tmp/test.spv 
#version 450

struct vertex_out
{
    vec4 screen_pos;
    vec2 texture_coord;
};

layout(location = 0) out vec2 vertex_texture_coord;

void main()
{
    uint _34 = uint(gl_VertexID);
    vec2 _77 = vec2(float((_34 << uint(1)) & 2u), float(_34 & 2u));
    gl_Position = vec4(fma(_77, vec2(2.0, -2.0), vec2(-1.0, 1.0)), 0.0, 1.0);
    vertex_texture_coord = _77;
}

[tired sandal]

I might as well just write GLSL then

[golden schooner]

why not

[tired sandal]

glsl is ugly

HLSL and thus slang have a much nicer syntax and better features

[golden schooner]

stuff you actually use?

[long robin]

namespaces, member functions, and operator overloading alone are nice

[tired sandal]

or y'know, returning actual structs from the shader functions instead of writing to some globals

[heavy cipher]

y tho

[tired sandal]

i need the source code of GLSL shaders so they can be compiled at runtime.
Slang->SPIRV->SPIRV-Cross->GLSL is just a weird route when I need to include the source in my program anyway

[heavy cipher]

huh?

[tired sandal]

@golden schooner can you try this one?

this is a SPIRV 1.0

two entry points: vertex and pixel

[golden schooner]

try what

[tired sandal]

the hell

it works now

by separating the entry points into separate files and specifying "main" as the entry points, the GraphicsPipeline compiles now

[long robin]

I'll try it

[golden schooner]

what do you want me to try

spirvcross or what

[tired sandal]

nothing anymore

[golden schooner]

so Fwog has no entry point in the shadercreate struct and uses "main" always (hardcoded), but Fvog should have it

[long robin]

that's not the issue

also fwog does let you specify the entry point

[golden schooner]

i know its not the issue, but a consequence

[long robin]

now I just straight-up crash inside glSpecializeShader when I try these

(it's okay for the last two params to be null, and entryPoint is hardcoded to be "main")

I guess nv drivers just really don't like these shaders

[tired sandal]

AMD does not seem to be working correctly as well, using the Pipeline for rendering crashes my app

I'll be using plain GLSL then. fuck SPIRV

[long robin]

vulkan drivers already barely cope with spirv that wasn't generated by glslang. now imagine their dusty gl spirv integration

[long robin]

understandable tbh

[tired sandal]

thanks anyway for the integration of SPIRV shader compilation. maybe in 30 years we get proper SPIRV support in GL

[long robin]

martty's troll suggestion to use spirv-cross unironically might be the most robust way to use spirv that didn't originate from glslang

in gl that is

but no one should be subjected to that kind of tooling

[tired sandal]

yeah but spirv-cross just spits out GLSL. I dont see a reason to use SPIRV-Cross when I can write GLSL directly

[long robin]

well you aren't writing glsl

[heavy cipher]

it is so that you can write slang directly

[long robin]

in fact it doesn't really matter what it emits as long as the API accepts it

[heavy cipher]

slightly better on the sliding scale of shader language cringe

[golden schooner]

slangtly

[tired sandal]

30th August 2021, is that the latest version of SPIRV-Cross?

I'll try it

[golden schooner]

released version mayhaps

[long robin]

there are commits from a few weeks ago

[heavy cipher]

λ spirv-cross.exe
Git commit: 117161dd Timestamp: 2024-01-15T13:32:26

this is what i have on my path from the sdk

[wind jasper]

hell no

isnt that the version on shader-playground?

[golden schooner]

[deccer@rootfs ~]$ spirv-cross --revision
Git commit: 2de1265f Timestamp: 2023-10-20T19:55:51
``` : o ah im on 1.3.268.0

[wind jasper]

ok no shader-playground's is from 2021-06-22

but that's ancient too

[tired sandal]

wait, no need for SPIRV-Cross, I can just compile slang to GLSL

[golden schooner]

it will compile to vulkan glsl

and there is no switch for opengl glsl, as we figured out last night

suggestion was to open an issue at slang mcslanglington

you could try make Potrick do it, he basically lives there anyway

[tired sandal]

it has separate glsl-vulkan target

#version 450
layout(row_major) uniform;
layout(row_major) buffer;

#line 1 0
layout(location = 0)
out vec2 vertex_texture_coord_0;


#line 1
struct vertex_out_0
{
    vec4 screen_pos_0;
    vec2 texture_coord_0;
};


#line 11
void main()
{

#line 11
    uint _S1 = uint(gl_VertexIndex);
    vertex_out_0 output_0;
    vec2 _S2 = vec2(float(_S1 << 1 & 2U), float(_S1 & 2U));

#line 13
    output_0.texture_coord_0 = _S2;
    vec4 _S3 = vec4(output_0.texture_coord_0 * vec2(2.0, -2.0) + vec2(-1.0, 1.0), 0.0, 1.0);

#line 14
    output_0.screen_pos_0 = _S3;
    vertex_out_0 _S4 = output_0;

#line 15
    gl_Position = output_0.screen_pos_0;

#line 15
    vertex_texture_coord_0 = _S4.texture_coord_0;

#line 15
    return;
}

Unless I am mistaken, this is valid OGL GLSL.

[golden schooner]

we looked at glsl generated by glsl last night

it had gl_xxxIndex in it, rather than gl_xxxID

hence the whole kerfuffle about opening an issue

[tired sandal]

oh yes you are right

[golden schooner]

kerfuffle

[long robin]

Yes someone should do this

That seems like a clear bug and an easy one to fix

[sinful nexus]

Quick question - the docs show to pull the master... is that intended when releases are present? Asking as the latest master doesn't compile

I actually wonder if this will even try to run on MacOS

[golden schooner]

no

it wont run on mac

main target is opengl 4.6

it might via mesa and forced gl46 in software, or zinc, but no idea if that is also supported on macos

[sinful nexus]

I am thinking of using MGL (https://github.com/openglonmetal/MGL), but I am not sure if Fwog doesn't by default require some bleeding-edge (in terms of OpenGL) feature it doesn't cover

[golden schooner]

still

[wind jasper]

it doesnt cover a lot of things

[sinful nexus]

ah

goddamnit

[golden schooner]

what could be worth though, is, if you ported Fwog to Metal, for science

Mwog so to speak 🙂

[wind jasper]

Fmog

[golden schooner]

hehe

or you sell your mac thing and get an actual pc

[sinful nexus]

I think it would be more worthwhile to port it to vulkan at that point

[golden schooner]

jaker is porting to vulkan already

[sinful nexus]

oh nice

[golden schooner]

theres a bulkan port branch

[wind jasper]

could check if that runs over MVK

[sinful nexus]

Is that in some usable state already? Or heavy-in-dev state?

[golden schooner]

its not fully working yet

flickering and upsidedownisms are still a thing

among other things

[sinful nexus]

All I want for christmas is something that lets me get into the meat of graphics programming without the incredible amount of boilerplate required by like every graphics API

[golden schooner]

then dive into webgpu

elimichiel posted his tutorial thing in #1019722539116802068 yestergestern

for webgpu dawn

[sinful nexus]

Damn that looks nice

[golden schooner]

the most important thing it also will run on your mac thing

[long robin]

The docs are broken atm so they're a bit old

[long robin]

There isn't

[golden schooner]

: o

oh

[long robin]

The Vulkan port is #1128020727380054046

[golden schooner]

its in frogfodder

my b

[long robin]

I'm making a fwog-like thing there too, however

But it's not a library

[golden schooner]

knedlikkowitsch is bound to mac anyway

[long robin]

Ja

[dapper gorge]

Jaker could you merge this real quick https://github.com/JuanDiegoMontoya/Fwog/pull/101

[long robin]

Ok but I was hoping raildex would make the change I suggested

[dapper gorge]

ah rip

it's fine then

[long robin]

I merged anyway

[dapper gorge]

I'll cope

alright thank

[long robin]

Nah it's literally just some bs

That barely matters compared to main not building

Btw how come you're using fwog suddenly?

[dapper gorge]

mm secret

(I need to impress my image processing prof)

((I figured using my humongous Vulkan abstraction would be too much ))

[long robin]

Tell them a frog whispered in your ear

[dapper gorge]

I will shill your lib

[long robin]

Just lmk if anything sucks when you try it. I want you to have a good time

Although I know you used it a bit when you were working on frogfood

[dapper gorge]

ye it's probably gonna be just fine

I don't have to do nanite

[long robin]

why

[wind jasper]

ubuntu 18 or 20?

[long robin]

ubuntu-latest

that's probably the cause of builds randomly breaking

[wind jasper]

13.2 should be preinstalled

[long robin]

hmm idk then

[wind jasper]

probably just called gcc for ubuntu 22.04 apt

[long robin]

@ deccr pls fix

[golden schooner]

default gcc on obotnu is 10.2 ;B

[long robin]

*œbœntœ

meh linux users can just cope

[golden schooner]

https://github.com/actions/runner-images/blob/ubuntu22/20240603.1/images/ubuntu/Ubuntu2204-Readme.md das is whats installed on the default image... ill look

[long robin]

should the apt-get thingy get gcc 13 though

or is that not there for some reason

[golden schooner]

https://github.com/JuanDiegoMontoya/Fwog/pull/102

[long robin]

thanks mwa grenouille

[golden schooner]

pas de sauci

[dire arch]

what witchcraft is this

[long robin]

volumetric fog

[golden schooner]

almost 2 years already

[burnt fog]

smol question, why hashing is not used for getting cached samplers?

[long robin]

I did have hashing at one point but I think I removed it because it was an annoying amount of code for questionable gain

[burnt fog]

understandable, thanks

[viral haven]

Hope you don't mind my replying to a 2 year old message, but how much vram did your GPU have at the time of this recording 🤔

I remember trying to load intel sponza with textures on my gtx 1650 (4 gigs of vram) and it was way to less. But note that this was with no fancy streaming and such

[signal widget]

Jaker got married since and had 5 kids

[wind jasper]

well intel sponza has 4K images so you could also just downscale before uploading

[viral haven]

I see, so it was basically a skill issue and not a gpu-vram issue

[wind jasper]

always is

[long robin]

3070 so like 8 gigs

But the scene wasn't heavy at all

[digital lion]

Uncompressed Intel Sponza also didnt fit into 8GB VRAM for me. But with KTX textures its no problem

[long robin]

ktx on top 💪

[robust bough]

@long robin I would like to see if I can get a metal backend working for fwog, is this something that could go into the "main repo" or should I keep a fork?

[wind jasper]

👀

[long robin]

I'd say fork because I wouldn't be able to maintain it at all

I could link to it from the main readme though

[robust bough]

Alright

[burnt fog]

I am once again with my questions, in your

void CopyBufferToTexture(const CopyBufferToTextureInfo& copy)
  {
    glPixelStorei(GL_UNPACK_ROW_LENGTH, copy.bufferRowLength);
    glPixelStorei(GL_UNPACK_IMAGE_HEIGHT, copy.bufferImageHeight);

    glBindBuffer(GL_PIXEL_UNPACK_BUFFER, copy.sourceBuffer.Handle());

    copy.targetTexture.subImageInternal({copy.level,
                                         copy.targetOffset,
                                         copy.extent,
                                         copy.format,
                                         copy.type,
                                         reinterpret_cast<void*>(static_cast<uintptr_t>(copy.sourceOffset)),
                                         copy.bufferRowLength,
                                         copy.bufferImageHeight});
  }
```What is the point of calling glPixelStorei if subImageInternal will call it anyway?
And shouldn't it unbind pixel unpack buffer after updating texture?

[long robin]

It's possible I forgor

Not unbinding shouldn't be a problem however, as long as I consistently bind and don't rely on old bindings

[robust bough]

@long robin I believe there might be a bug in fwog

I have a very shrimple fragment shader

#version 460 core

layout(location = 0) out vec4 o_colour;

layout(location = 0) in vec2 tex_coord;

layout(binding = 0) uniform sampler2D albedo;

layout(binding = 2, std140) buffer PlanetBuffer { mat4 planet_transforms[]; };

void main()
{
    if (planet_transforms.length() > 0) {
        o_colour = vec4(1.0f);
    } else {
        o_colour = vec4(vec3(0.0f), 1.0f);
    }
}```

        Fwog::RenderToSwapchain(
            Fwog::SwapchainRenderInfo{
                .name = "Render Grid",
                .viewport = Fwog::Viewport{.drawRect{.offset = {0, 0}, .extent = {render_context.width, render_context.height}}},
                .colorLoadOp = Fwog::AttachmentLoadOp::CLEAR,
                .clearColorValue = {.2f, .0f, .2f, 1.0f},
            },
            [&]
            {
              Fwog::Cmd::BindSampledImage(0, frame_albedo, nearest_sampler);
              Fwog::Cmd::BindStorageBuffer(2, planet_buffer);

              Fwog::Cmd::BindGraphicsPipeline(shading_pipeline);
              Fwog::Cmd::Draw(3, 1, 0, 0);
            });```

This is what renderdoc says is in the buffer

But the output is just a black screen

[golden schooner]

wrong winding of your tringle?

check the pipeline state

depth test should fail

[robust bough]

if I make it display white then it works

void main()
{
    if (planet_transforms.length() > 0) {
        o_colour = vec4(vec3(0.0f), 1.0f);
    } else {
        o_colour = vec4(vec3(1.0f), 1.0f);
    }
}```

[golden schooner]

still

check the geometry

[golden schooner]

now the texture output, check the depth test overlay

[robust bough]

where is that?

[golden schooner]

select draw call

then texture viewer

on teh right output tab

and overlay is a combobox in the texture viewer

[golden schooner]

: (

you know how it works

check the overlay for depth test

if its red then the vertices of your FST are in the wrong order

[robust bough]

i dont know how it works

it's been a while since i've used renderdoc 💀

I am still a bit confused

how could this have any impact on the output?

[golden schooner]

if the depth test fails the FST is not drawn

[robust bough]

Yeah, but I can make it display stuff

[golden schooner]

then you didnt reveal all relevant information

[robust bough]

.

[golden schooner]

kk

[robust bough]

let me try again though

void main()
{
    if (planet_transforms.length() > 0) {
        o_colour = vec4(vec3(1.0f), 1.0f);
    } else {
        o_colour = vec4(vec3(0.0f), 1.0f);
    }
}```

[golden schooner]

what is supposed to be visible?

[robust bough]

It's supposed to be white

[golden schooner]

can you send the rdc

[robust bough]

Ye

sec

there ya go

[golden schooner]

this is weird

[robust bough]

how so?

[golden schooner]

it looks correct

bindings check out

your albedo texture is empty

but that shouldnt matter

[robust bough]

yeah before i did this in a compute pass

im doing it in a fragment shader now to shrimplify

[golden schooner]

the only odd thing is

there is no vao

i suppose you do vertexpulling there later

how do you setup shading_pipeline

[robust bough]

    auto vertexShader = Fwog::Shader(Fwog::PipelineStage::VERTEX_SHADER, util::read_file("shaders/shading_vs.glsl"), "Shading VS");
    auto fragmentShader = Fwog::Shader(Fwog::PipelineStage::FRAGMENT_SHADER, util::read_file("shaders/shading_fs.glsl"), "Shading FS");

    return Fwog::GraphicsPipeline{{
                                      .name = "Shading Pipeline",
                                      .vertexShader = &vertexShader,
                                      .fragmentShader = &fragmentShader,
                                      .inputAssemblyState = {.topology = Fwog::PrimitiveTopology::TRIANGLE_LIST},
                                      .vertexInputState = {},
                                  }};```

[golden schooner]

that looks fine too

weird that the planetbuffer.length() > 0 thing behaves so weirdly

there are clearly items in it

hmm, it must be something super stupid 😄

[robust bough]

right?

[golden schooner]

played with the fragment shader a bit, and it makes no sense to me

mf clearly draws stuff

float rand(vec2 co){
    return fract(sin(dot(co, vec2(12.9898, 78.233))) * 43758.5453);
}

o_colour = vec4(rand(gl_FragCoord.xy), 0.0, 0.0, 1.0f);

[robust bough]

right?

it's literally the .length() thing

[golden schooner]

is it perhaps optimized out for some reason?

and just returns 0 when you are not using the buffer in anything

[wind jasper]

what if you have the color as .length() / 4 or sth

[golden schooner]

all 0.0

i tried that too

[robust bough]

yeah @golden schooner im just completely lost

[golden schooner]

can you add some code which uses content from le buffer?

other than .length()

[long robin]

I get a white screen

it's clearly taking the first path

[robust bough]

odd

[robust bough]

@long robin how do you reckon i could debug this?

[long robin]

what os are you on

and gpu

and driver

[robust bough]

win11, 3080, latest