#Phobos - Vulkan abstraction library in Rust
1 messages · Page 4 of 1
Saving it into a free list or something
I mean when you release a resource, you can mark the index of that descriptor as "free"
Like a free list allocator
If you return an object to the pool that slot will be overwirttene eventually yes
Yeah that's what I wanted to do
Versioning the induces would be cool but
Dunno if it is actually needed
Since the object you get from the pool owns the index
I think free list makes more sense
That was an additional thing
That said I will take a look at how daxa allocates indices
Maybe there is something cool there
Also when you bind a graphics pipeline (with a common pipeline layout) and then bind a common descriptor set (set = 0), would it need to dispatch a new vkCmdDescriptorSets?
Iirc bindless allows you to just reutilize the same pipeline layout multiple times which can save from submitting that call
if they are at the same set index the layouts are called compatible and the set binding is not changed at that index
iirc
Oh so the pipeline layouts don't need to be the same, just compatible?
the layout changes
but if the sets at 0..n are the same, those dont get unbound when changing to a new pipeline
You do not know how I angry I was yesterday after playing valorant
i only play occasionally nowadays
I rlly want to switch because wgpu is giving me a headache but I also don't want to fall into my canon event of having to rewrite my graphics engine for the nth time
you gotta do it. write the graphics engine for the nth time. I mean phobos should help out a lot
Yea it should
If I do I'll have to figure out what's stopping me from using renderdoc
check the log file
So what does it mean
when the image view's image u64 is negative
does it mean it's invalid?
u64?
Yeah and if it is negative, would that imply it has been deleted?
so try dereferencing it in the debugger
no
an unsigned integer can't be negative
Also this lol
can you input a regular buffer as a storage buffer? Phobos removed all flags so I'm not sure
Tbh I don't know if removing those flags was a good idea I mean yea it does simplify the interface but I do feel like they have some significance
eh not really in terms of performance
however it makes it really annoying
if you wanted to add some specific features
like allow buffers to become storage buffers
which I cannot in the current state
I think optional flags would be a nice compromise
Yes
Every buffer is a storage buffer if you want to use it as such
🗿 Oh no crashes 
Same
But I like my prof
He would usually make statements like:
The death day of someone is a totally available attribute, but it is unfortunately unknown
Does phobos have a way to do mock tests?
Mock vk calls? Not really no
gitlab is so much better than github honeslty
im using it for work and its 10x better lmfao
oo work? anything nice?
my uni is developing an online platform to teach highschool kids python and im working on it for a few weeks
its not too bad
Teach vulkan to the kids 😈
sneaking in easter eggs to draw them to the graphics side 

get them hooked on drugs instead, less harm
Oh yeah absolutely
"Looks at those nice triangles"
loads of maths, low level stuff and gpu hangs around the corner
Who isn't
time to work on automated tests
#[test]
pub fn use_entire_scratch_allocator() -> Result<()> {
// Try allocating the entire scratch allocator's memory for a single buffer
let mut context = framework::make_context()?;
let mut scratch_allocator =
ScratchAllocator::new(context.device.clone(), &mut context.allocator, 1024 as u64)?;
let _buffer = scratch_allocator.allocate(1024 as u64)?;
Ok(())
}
first bug squashed because of tests
framework::make_context creates a headless phobos context
it doesnt work on github actions, fails to load vk
i cannot be bothered to figure out if this is a gh actions limitation or just me not installing the sdk in the runner

Thanks for letting me know. I'll probably integrate that into my engine
most of the code is untested
because I couldn't figure out a way to get testing to work without having 900 windows pop open
mhm
I guess you coil try with lavapipe if the runner doesn't have a gpu
oh yeah that is true
For tests, do you actually create a vulkan context or is it "emulated"?
not efficient but i dont want to set up mocking of vk calls
Nah nah fair plus it lets you catch validation errors as well
Just install mesa
I think it will work ootb
Oh and the lavapipe driver
Which distro is it running?
ubuntu
sudo apt-get install -y mesa-vulkan-drivers libvulkan1 vulkan-tools vulkan-validationlayers found this in an issue
might give that a try
Nice
Next commit will be the 500th
Penguin last time I came across the descriptorcache thing
But couldn't figure out what holds an instance to it
Because for the bibdless stuff I need to keep a ds around
But in order to allocate it I need a pool which is stored inside that struct
Its stored by the ResourcePool nowadays
making some kind of BindlessPool that manages the bindless set might work, we can keep that inside the ResourcePool as well
Ah makes sense, so I guess I can just take it as an argument in the constructor (I already have a BindlessPool) and when ResourcePool is constructed it can be passed
I was working on it the other day and just remembered this us something I stumbled upon
I'm not pouring many hours into this unfortunately
yeah you can do that for now
thats fine lol
me neither
coding at works leaves me little motivation to do more afterwards
the soulless webdev work
it drains energy
if you have something feel free to open a draft PR, it doesnt need to be completed at all but its easier to give thoughts that way
Riip
It's not much rn
thats fine
I've done webdev in an internship and I know what it is like 😔
Now I do cool stuff
The thing is that in the Sumner I don't spend all day in from of my pc
Best of luck! I trust you'll find something gp related
Thats the plan
But in the winter I do spend all day in front of my PC
Im just taking a summer job at uni to earn some money now
Better than all year like me 
I guess I'll be able to do more stuff in the winter
But yeah it is definetly possible to bring hobby projects forward while having a fulltime job
div div div div div
Ptsd
During my internship they asked me to make a scraper
And I made a temporary HTML ui to demo it
Expecting they'd make somebody else do the frontend
But no they asked me to do it like their other internal apps
And I, someone who knows nothing about webstufd, did something that looked close to it (from scratch)
Then they weren't happy
lmao
at least i have an existing frontend to improve on but its not very nice
and bootstrap I think?
ye this uses angular
im working on a platform to teach highschool kids python programming
But at least someone did the graphical stuff for me
some implementation details are very questionable though lmao
it sends the solutions to the exercises with the problems to the frontend 
They felt like computery things
Lol
yeah same, i just copy what is already there and adapt it a bit
I find 90s to be pretty their own way
yeah so if youre somewhat adept you can just look at incoming traffic and copy over the solutions lmao
i think at least for test questions it doesnt but thats very incomplete atm
They'd blame the kids if they did it anyway I guess
It's a feature
Your testing their honesty
i mean
if they can figure that out they can probably solve it too
the questions are really basic
yeah
I see
i was first in a programming contest for some class, and at the end the professor offered some summer jobs to the first 3
Nice
Kek
I'm sure I've done many things in a non phobos-way so please do point out such things
It's still untested and incomplete
But I'm sure there are things that need to change
so I'd rather get them right first
Yep that makes sense
I added some comments
Some are really quick fixes
In general, looks pretty good
Glad to hear! Yeah my naming is totally fucked up I'm addressing that rn

Penguin I wanted to discuss with you how you think the layout thing in CimbinedImageSampler should be handled. If it is entirely the responsibility of the user to make sure it is in the right layout is it reasonable to have a default?
(That's why I didn't write a constructor, my thought was that if the layout should always be provided to it then it makes no sense to have it as an Option)
Hmm so I can't exactly see a reason why it shouldnt be in ShaderReadOnlyOptimal
Its the only layout that makes sense besides General but that is discouraged
I think its probably reasonable to enforce ShaderReadOnlyOptimal unless you can think of a case where you really wouldnt want this
(And then not have the field at all and hardcode it in)
there is also read only optimal
Does that make sense for combined image samplers?
unless combined has a special meaning in phobos
no its just the same as a vk::DescriptorType::CombinedImageSampler
then it would make sense under sync2
Yeah I mean I agree but the transitions wouldn't be done automatically right? My thinking was that forcing the user to provide it explicitly makes sense since the transition would have to be done explicitly
Though if you think it is OK as it is I don't really have a problem with it, this is nit picking.
So just make sure we'd have a new co steuctor that only takes an ImageView and a Sampler, then maybe a with_layout method if the usrr wants to specify one
They wouldnt, this would just mean "the library expects the layout to be correct"
as it already does for regular bindings
That's a good idea
Great! I'll see when I have some more time to work on it (hopefully I can do this simple thing today). One thing that I need to address before I can begin to actually try using it is introducing a way of binding the bindless pool.
Yeah, I think it makes sense to have this on IncompleteCommandBuffer
pub fn with_layout(self, image_layout: Option<vk::ImageLayout>) -> Self {
Self { image_layout, .. self }
}
I have never seen this syntax but it looks awesome
Yeah really useful for things like that one
Rust syntax ❤️
true
Alr time for me to contribute to phobos again gotta rust myself again
@night charm what would be a good issue for me to tackle in your opinion?
let me see
https://github.com/NotAPenguin0/phobos-rs/issues/66 is something i havent gotten around to yet but would like in the next release
If you just want something quick to knock out first, https://github.com/NotAPenguin0/phobos-rs/issues/38 is very simple
Oh tbh even the scratch mem issue doesn't sound too bad
How is it actually implemented internally? Is it just a persistent VMA allocation?
(I just took a peek at the code and yep that's what it seems to do)
i will personally send you a thank you letter if you finish issue 66
order 66
Tbh it doesn't even seem that bad
Just make the allocator allocate in like "chunks" to remove the need to re-allocate
And each of those chunks could be 128kb or something like that
thats a much better solution than what i was trying to come up with
it does need a way to handle allocations larger than a single chunk
Right
My only question is what's the "max" size one could possibly allocate
Cause I wouldn't expect users to allocate like 1gb each frame lol
Inner Alloc 1: 0..1 (128kb)
Inner Alloc 2: 1..3 (256kb)
Inner Alloc 1: 3..6 (384kb)
We could store a u128 bitmask containing the ranges of "used" allocations. Whenever a user allocates memory, it would look for the first free bits within that mask that would be able to store the whole allocation of the user (so like, the bitmask acts like a range "searcher")
Tbh I don't even think that's needed
Considering the fact that you can only reset the whole scratch allocator as a whole and not each allocation separately
Just make a simple vec with the inner allocations then kek
The whole point of this is that allocations are supposed to be very fast
There should be no performance issue with allocating a small buffer for every drawcall
You could also do something like
- When the allocation exceeds the current available memory, allocate a new block for it
- When resetting, allocate another new block that would fit all allocations for this frame
- Next frame, when the same allocation happens, we no longer need a new block because the allocator is bigger now
So you'd be fine with having excess memory for the sake of the possibility that it will get reused next frame?
Ok I implemented it
I'm a bit confused by whatever this does
// Part of the buffer that is over the min alignment
let unaligned_part = size % self.alignment;
// Amount of padding bytes to insert. This is zero if there are no unaligned bytes
let padding = if unaligned_part == 0 {
0
} else {
self.alignment - unaligned_part
};
let padded_size = size + padding;
I understand it's for alignment but wot's padded_size?
yes, I think this is fairly likely for most cases
this makes sure the final allocated size is a multiple of alignment
padded_size should be called aligned_size maybe
I see
So doing something like
let padded_size = ((size as f32) / (self.alignment as f32)).ceil() as u64 * 256;
Would give the same result?
Testing time
Make sure it doesnt add extra bytes if the size is already a multiple of the alignment
But I think that should be fine here
A browser interface to the Rust compiler to experiment with the language
Seems okay
There's probably an even cleaner way to do this
// Aligns given value up to nearest multiply of align value. For example: VmaAlignUp(11, 8) = 16.
// Use types like uint32_t, uint64_t as T.
template<typename T>
static inline T VmaAlignUp(T val, T align) {
return (val + align - 1) / align * align;
}
here is something better
Yep kek
ceiled integer division * divisor
Yea unfortunately in rust it's behind the experimental int_roundings feature
Wat
lmao
cant you just write the expression above instead of using div_ceil
there is integer division though, of course
Oh no I'm not saying you can't
I'm saying that there's already a feature that does it for you but it's hidden away atm
i see
Holy moly
fn test_bitwise(size: u64) -> u64 {
(size + 255) & !255u64
}
Least cursed align_to calculation
(it actually works as well)
the above works for npot alignments
I'm bikeshedding too much lol back to allocator stuff
if you only have pot alignments, you could write something more brainwormed
Absolutely
that sufficient for all vulkan alignments, yes
Also, is there a reason to use 800 as u64 instead of 800u64 in the allocator tests?
not really
Understandable
Alright I think I'm done with the dynamically growing scratch alloc
I currently made the min chunk size 32kb internally, could very easily make it external if you wish as well
Oh also if you don't mind I added a conditional flag for compiling the 04_fsr2 example
I don't have fsr2 installed (nor the feature enabled) so the errors kept bugging me lol
Huh that's weird that it compiled it at all
Use cargo test --tests to run the tests if thats what you were doing
its fine though
I added some (mostly minor) comments
fixed my dumb mistakes on the doc comments lol
I should prob do the same when I get back too lol
There’s no hurry dw
@night charm So how exactly would you want the shrink method to work?
Should it just deallocate all extra buffers (other than the initial one)?
It doesnt really work with the way you implemented things so I think it's fine to leave it out
Though I think there's an argument for trying to "compress" the allocator by merging all buffers into a bigger one when it resets
This way you need less binding new buffers potentially
- it helps suballocating a single buffer more instead of allocating many buffers
Yeah the contents of the buffer dont matter at that point
Yea so I can just discard of them
So the shrink method would have to execute after the reset method, or is that not a requirement?
I think we dont have the shrink method and just compress on reset
It should stabilize after a few frames
Aight gotchu
Or, shrink() simply sets the size to compress to
Which then happens next time you reset
Might be a bit unclear though
Yea at that point just pass it as an arg
Yeah but make it an Option<> then
Yep alright
So now the fn def is reset(&mut self, compressed_size: Option<vk::DeviceSize>) -> Result<()>
Should be ok for the most part
looks good
i am a very competent web developer yes
Efficient utilization of space
That it is
I am quite conchfused at how this is supposed to be used https://github.com/NotAPenguin0/phobos-rs/pull/67/files#diff-eb0df13bd0e9d08fffc3198285006a5382cc8d7e0e4f4e9d9a30776577736970R116
Rust's syntax doesn't help in the understanding 
lol
the only function to use publicly is alloc and alloc_items
(and new ofc)
But as for this line fn update_descriptor_set<'a>(&'a mut self, r: impl Iterator<Item = (u32, &'a R)>
You pass it an iterator over (u32, R), but the last element in each pair is a reference that has the same lifetime as self
no
wip PR

let me see
// once
let pool = BindlessPool::new(...);
let images: Vec<ImageView> = get_all_textures();
let handles: Vec<_> = pool.alloc_items(images.iter()).collect();
// every frame
let cmd = create_command_buffer();
cmd.bind_bindless_pool(&pool);
// Send index of first image to shader
cmd.push_constant(0, 4, handles[0].index());
@limber rapids should be something like this
no it shouldnt
you only alloc when adding a new texture
Which updates the modified region
no erasing yet i think
When you alloc you get a BindlessHandle, when it Drops it calls back into the pool which adds the index to the free list. Next time you alloc that index will be recycled and the descriptor for that index gets overwritten
As for updating, the descriptor set is always updated every time you alloc. There is no need for anything explicit basically.
alright
I though of adding a generation counter but so long as you take the index from the handle it must be valid so I couldn't see the point
BTW if you think the docs could he more clear I'd appreciate some feedback
I'll see when I can get back to that PR and actually add a function to bind the pool so I can start using it in my project (for which I also need yo find the time) and validate that things work. Though being a simple api I don't see much that could go wrong
Does the dynamic scratch allocator work off the bat?
yes
Oh yeah penguin
is there a way to add support for multiple different types of samplers
in one descriptor array?
In new system yes
That makes me realise smth actually
@hybrid pilot I added another comment
Ah yes that actually crossed my mind and I forgot to ask you whether you where OK with forcing the user to provide an Arc. I'll address it soon.
I dont really see a way around it but it's fine imo
samplers are readonly objects anyway and sharing them makes a lot of sense
The way around it would be with traits I guess but it gets messy for no good reason
yeah
Yeah it only makes sense to hard code arc for this
Penguin is there a way for me to create a custom debug callback?
mainly for the shader printf
Not the end of the world as vkconfig always exists
@hybrid pilot i think we need to implement pipeline layout compatibility
i added a comment on github with a short explanation of my idea but it might not be entirely clear
Yeah that makes a ton of sense so if the user keeps the bindless pool near the top of their shader at a fixed index Phobos will automatically not bother binding it again which is also an optimization
Exactly
Good idea, I'll work on it
iirc the rendergraph does not do memory sychronization?
nvm i am stupid
The pass graph system is a powerful abstraction that allows you to automatically manage synchronization within a single queue, and automatically transition image layouts based on usage.
it does
Stupid question, but things that only affect rendering of the final image only belong on the render graph so image loading is a no go and should it’s commands should just be submitted to the exec manager.
What about updating stuff like BLAS + TLAS?
you can choose
updating tlas is typically done every frame so you can easily put that in a render graph pass
Why not just have everything always in a mega set you can bind at will
that is an old message lmao
because enforcing shader descriptor set layours for users seems a bit annoying
it is nice to go full bindless though
🧓

New bindless system is a step in that direction
Register resources into the bindless set, bind the set and forget about it
hmm
🤓 why have desceiptor set layouts and pipelinr layouts exposed
theyre not
those ugly objects belong in the gutter
but you'd still need to write your shaders to consume this "mega set"
yes. I am happy with supplying a header for the user for these things
Yeah thats fair
it can be get really quite simple with that. In daxa you never care about any binding or sets even in shaders. you can just do daxa_SOME_GLSL_IMAGE_TYPE(ID) for example daxa_texture2D(id) and it gives you the glsl type in place. You can do that for anything just by including the header with bo additional work. Makes bindles extreamly simple
thats quite neat yeah
Dear penguin,
Does phobos use renderpasses or use dynamic rendering
Sincerely
Danny "i hate renderpasses" Le
features_1_3.dynamic_rendering = vk::TRUE;
He's sane. We making out of the Vulkan specification with this one 🔥
Dynamic rendering all the way
i learnt why the hard way 
Renderpasses are for mobile nerds
Penguin
we have a problem
I need to enable the VK_KHR_shader_clock extension but the issue is that
I uh
kinda need to link the feature in a p_next
but that isn't possible
let shader_clock_feature = vk::PhysicalDeviceShaderClockFeaturesKHR {
s_type: vk::StructureType::PHYSICAL_DEVICE_SHADER_CLOCK_FEATURES_KHR,
p_next: ptr::null_mut(),
shader_subgroup_clock: vk::TRUE,
shader_device_clock: vk::TRUE,
};
let mut settings = phobos::AppBuilder::new()
.version((1, 0, 0))
.name(name)
.validation(true)
.present_mode(phobos::vk::PresentModeKHR::MAILBOX)
.scratch_chunk_size(1 * 1024u64)
.gpu(phobos::GPURequirements {
dedicated: false,
min_video_memory: 4 * 1024 * 1024 * 1024, // 1 GiB
min_dedicated_video_memory: 4 * 1024 * 1024 * 1024,
queues: vec![
phobos::QueueRequest {
dedicated: false,
queue_type: phobos::QueueType::Graphics,
},
phobos::QueueRequest {
dedicated: true,
queue_type: phobos::QueueType::Transfer,
},
phobos::QueueRequest {
dedicated: true,
queue_type: phobos::QueueType::Compute,
},
],
features: vk::PhysicalDeviceFeatures::builder()
.shader_int64(true)
.build(),
device_extensions: vec![
String::from("VK_EXT_scalar_block_layout"),
String::from("VK_KHR_shader_clock"),
],
..Default::default()
});
Nah p_next() doesn't exist on VkPhysicalDeviceFeatures for some reason
yeah it;s on 2
lmk when fixed
it isn't a catastrophic issue as somehow i'm still getting random results from my hemisphere generator somehow 

Hey penguin how did you handle deallocating your buffers with gpu-allocator
You can free() them
Yo penguin
on persistant mapping
do you do it?
Been finding it a pain to deal with rn
Everything that’s mappable is persistently mapped yes
@night charm so for pipeline layout compatibility, can you point me at where bindings are currently cleared when changing pipelines?
It happens somewhat implicitly when binding a descriptor set, you can look at command_buffer/incomplete.rs:163
.take().unwrap() just sets the old value to None
But this would probably need to be changed
Uh I see, so the actual bound sets are not changed they are cleared from that array
Yeah
yeah the ones after should be kept if layouts are compatible
well this happens on the vulkan side still
say you bind the first 10 sets
but we dont detect it so theres no way to make use of that in a convenient way really
yeah makes sense
so what I'd change here is adding logic to keep track of which sets are actually bound, then when going through the array only bind those that have changed + clear the ones that have become incompatible if a pipeline change has happened
Yes, that sounds good
I'll be back in 10 mins
I'm back
so
I was thinking that when pipelines are bound a bitset of dirty sets could be kept
I mean it would or the bits of the sets that have been invalidated
then when ensure descriptor set runs it would clear those from the bound sets it keeps track of
and then what I said from here
Oh one thing I need to ask
yeah that makes sense so far
current_descriptor_sets stores builders
right
yeah that's what I was thinking
sounds like the easiest solution
indeed, so if it is ok for you that's what I'd do
Yeah thats fine by me
👍 thx
Yep, 2nd chances for those I failed in June/January
Thank 
I hate real analysis
Real numbers aren't real
True
did it go badly?
yeah, not the first time either :/
Yeah, but this is course from the maths ba
Im required to pick one of 3 options with classes outside my degree
With one option being math, the other economics/business, and one just misc stuff
i picked math because I do like math but eh yeah, math ba is insane lol
yep
I did do well on the geometry exam I think
I still have algebra to do but I think I can pass that too
Then analysis 1 is the only class standing between me and a degree 
when i did math i dropped all hobbies to pass
only thing i still did was work out
without that i would have become a pile of dust
Seems like thats what it takes for some of these classes
I did quite enjoy geometry, it was cool
same
6 exams, 6 ultra intense, 8 hours a day sessions of solving random problems 
both my algebra and geometry exams have this nice structure of 8/20 points closed book theory, and 12/20 open book exercises
So if you know the theory well you already almost pass
wut is open book
Eh
you have so much timepressure that you cant look at them basically
at least it was for me
huh
You can look something up quickly to get the details right but yeah, you need to know whats in it
all "open book" things just tricket you int owriting these cheat sheets to learn more
genius
I had 8 problems 2 theory questions in 3 hours
no notes
for algebra and geometry
having my notes would've been so free
I think I had achieved something like, every permutation of possible problems
lmao
hmm fair enough that is useful
oh yeah same
uni gives so much for free
free github pro and intellij ultimate is also nice
They gave me that stuff in uni but never used it. The marketing idea there is to get you used to those tools. Now personally for the main stuff I use for my job and hobby I don't want to depend on non Foss stuff
@night charm I've been thinking that due to how Phobos works currently, since it doesn't clear descriptor sets on the vulkan side, descriptor set compatibility might "just work". I mean once a set is bound it never gets bound again if ensure_descriptor_set is called more times right?
The vulkan semantic is almost directly exposed isn't it?
My concern was that it would override valid sets by binding on top again, but it never does from what I understand now
That’s correct
I updated my MR
Old on garbage ended up in there lol
No nvm
It's just that I rebased and the compare button shows all of the commits diff
How does phobos handle desc sets actually anyways?
I want to know it handles that under the hood tbh
You tell it to bind stuff, it has an array of stuff you've bound, then when it matters it actually bindes stuff and removes it from the array
So it works like a queue/stack
Ahh I see I see
ill do some more work on tests
factorio addiction is on hiatus
possibly until the expansion comes out
Same thing for me but it's modded minecraft instead
Idea: Make satisfactory/factorio based game
That way you can be addicted to coding your own game!
(never goes well)
“Sir, the nuclear meltdown was simply a misinput“
Never works
Lol all good
Penguin I've uploaded stuff that I've done for bindless some days ago
There is some new code around binding the pool
I saw but it was mixed in with a rebase on master so I got confused on what's new
But I think overall it looks good
its the stuff we talked about with stuffing the bound set in an enum right
Yep
Hey @night charm are there any Phobos context resources that don't handle being arc-safe internally?
the instance iirc
Ah I see ok
if i forget any the compiler will yell at you anyway
oh the debug messenger too I think
Right yea lol
Talking about debug messenger is there a specific order when you destroy said resources?
and VkPhysicalDevice
the one that doesnt crash 
Lol yea
instance last
If I drop my wrapper around them it gives a bunch of errors, which happened to me before using ash
Instance last okok
Thanks
Right yea
you could but idk
Oh also, is there any motive to support phobos on mac / apple devices?
I know there's a way to make stuff work with vulkan-compatibility in ash / wgpu but I'm not too knowledgeable on the subject (I never have touched an apple device in my life lol)
You need moltenvk which is a non compliant implementation atop metal
Non compliant + lacks many features
Ahhh I see ok
if it works it works
if it doesnt im not going to fix it because i dont have an apple device 
if other people want to fix it im open to it though 🤷
Yea right
I just wanted to know if emulating VK on top of metal would be a reliable way to support cross-platform
But if not I couldn't care less lol
its possible but doesnt always work out of the box afaik
the best attitude towards apple devices 🙏
err, 2nd best, you could also actively despise
true
uh so does phobos
automatically query through each physical device
to find one with the proper extensions
I'm testing it on my laptop and it seems to be selecting my iGPU...
hm it shouldnt be doing that unless the igpu is "good enough" to satisfy your given requirements
You could just pass dedicated = true
Yea actually in my fork I implemented custom physical device selection
do you think you can separate it into a pr
I might have deleted the branch (in my fork) for that... shouldn't be too hard to reimplement though
Yea I could do that right now actually in my fork

all good
I'm gonna need to do that anyways for my custom engine since I do some noice selection based on laptop battery level anyways
Ooh I see
that is really weird
wait
maybe it doesnt check extensions lol
let me check its been so long
i mean
phobos should enable them
ah i see
theyre not added in the device extensions list when checking the physical device
nah it should take care of that behind the scenes, the idea behind the rt option is that it just enabled the extensions for you
ahh okay
ill fix it rn hold up
epic
try pulling latest @iron shadow
the small amount of tests I have still pass so hopefully nothing broke
i'll try
for now uh i have to upload gigabytes of random gltf files onto my usb stick
sounds fun
get these
or theres a newer model nowadays maybe
but these are great
rip
nice
Now my question is, how should custom device selection work? @night charm
Cause there are some things that should be up to phobos (like skipping over devices that don't have RT supported when RT is enabled)
In my old fork I just got completely rid of everything phobos did and just let the user control that through the callback fn but it's not such a good solution imo
Lol
Russian roulette physical device selector
Sounds like a fun idea
(your graphics drivers crash 80% of the time)
Hmm
Maybe the user could pass in a function that scores devices?
Like it can check properties and give a score based on that
Then Phobos takes all devices that will work and picks the one with the highest score
I see I see
What I used to do is let phobos do the filtering first (based on features and stuff) and let the user select the remaining devices (to fix ambiguity)
hm that might be reasonable too
Alright I'll implement that real quick and do a PR
And then we can see from there I guess
yeah thats good
Great to hear!
Yippee!
gtnh addiction strikes again
Is there nothing exposing vkCmdUpdateBuffer?
Alright I passed algebra and geometry and failed real analysis (again)
That went as expected i guess
Riiiip
Would it suffice to add it to incomplete command buffer?
Though what about dependencies 🤔
Like sync
Well I guess I'll see how you handle transfers and do the same since it is that basically
yeah could be similar to transfers
would need an additional call in the pass builder to set up sync if needed
Yeah thx when I have time I'll look into it

I thought you were talking about transferring out of your uni program
penguin it's not clear to me how transfers would be tracked
pub(crate) enum ResourceUsage {
#[default]
Nothing,
Present,
Attachment(AttachmentType),
ShaderRead,
ShaderWrite,
}
I mean this struct doesn't even have a TransferDst
Worth adding a MemoryWrite and MemoryRead
Mmm, isn't that a bit too generic as far as wording? I mean it sounds confusing why is a ShaderRead not a memory read?
With Vulkan's convention I'd call them TransferSrc and TransferDst
Yeah that would probably be better
Great
Does phobos force you to use bda?
Like can I use storage buffers and uniform buffers normally
Yes
BDA is enabled by default and all buffers query their address, but you don’t have to use it at all
O okok cool
Since renderdoc doesn't support it I want to disable it when not needed
Oh yeah might have to conditionally disable it then
Renderdoc not supporting BDA kinda surprises me though
Are you sure?
I mean I've heard stories where it just crashes and won't run
Maybe that was in an older version though
Cause if not then I wouldn't have to ask to check if I can disable it lol
renderdoc has really good bda support
never had problems
Ah I might be tripping then
Discard my question to even begin with then lol
lol
that's one way to describe it lol
Lol
BUT
in other news
i am starting my masters tomorrow
which will include a few computer graphics courses
Awesome!
I should probably get working on my uni applications lol
Great to hear! Good luck!
thanks
already wtf, weren't you a third year?
bachelors is 3 years yes
i finished my last year (minus one course that im doing again this year) in august
thats normal
yes, you can just not start your thesis
whej you transition you can dtart before the bachelor is done
huh interesting
OpenXR my beloved
I think OpenXR will be for the project class in the second semester
this will cover the theory part
I was actually looking into making a VR game engine lol (even though I don't have a VR headset)
should go into #1019740594861522984
On a side note idek how to get started with vulkan multi-view stuff anyways
so when do you write your thesis?
hmm so you continue your bach, take classes from your master, then get those credits transferred?
wait 25/26? No bachelor thesis at all?
That was last year
Yes, but nothing is transferred, I still need to complete the full 120 credits from my masters degree
I'm just taking it on top of the masters programme, simultaneously
It's something like as long as you have less than 30 credits of your bach left you're allowed to take masters classes
simultaneously
me struggling to do one thing: 
its just one course 
i heard of someone starting this year
whos doing cs, math and physics degrees
together
math and physics combined is not unheard of but difficult but this is just insane
at most 3
I dun understand how to do that honestly
I'm in class 9-18 and then have to work 4 more hours
this is every single day, excluding Sat and Sun
i dont really have a lot of classes throughout the day typically
I am in class right now in fact 
VR/AR for me
we use Unity 
i think we will too but i havent looked at it in detail
it says unity/unreal
not sure whats used in the project
hmm doesnt say
this is just pain
exactly
i c
do you have a deadline for your ba?
when i started my master i still waited on the review on my ba so they just said i could start but need to have the ba reviewed in like 3 months
Not really, but if I don't get it this year I'm going to have to shuffle some thing around and end up studying an additional year
Man whoever worked on phobos bless you
The API is so good to work with
And fsr2 out of the box as well
My only teensy tiny problem is the use of strings for resource ids (which might seem a bit foot-gunny) but a small fork could alleviate that
i wonder who that is
the thing is i kinda like string ids because theyre easy to work with
but maybe its time for something more sophisticated
maybe compile-time hashing of strings with a macro
Oh yea absolutely
But it's not really "safe" per-se imo
Honestly I personally don't mind using it as my material system already makes use of string IDs but it seems like it's discouraged to use them
hmm true, its easy to pass a wrong string and mess something up
I'd say you can use string IDs to make "reference" type ID which then you pass around
Something like TypeID basically
yea so
compile time hash the string
put it into a token-like object
that you can copy around as a reference to the attachment
Yep pretty much
that could work
that way you can also keep using the string id if you want by just hashing the string again
Now nothing would stop you from making multiple references but that's you wanting to shoot yourself in the foot lol
I mean if you're gonna hash it
Then it would have to
yeah
https://docs.rs/sha2-const/latest/sha2_const/ I found this
const fn implementation of the SHA-2 family of hash functions.
how convient!
yep 
I'm pretty sure it could kinda speed up lookups internally
for sure
NoHashHasher for the win in that case
its pretty easy to add this in without having to rework much
the biggest part of the work I already refactored earlier
which was separating the version number from the string id in the resource identifiers
Ooo I see I see
Yea I haven't really messed with resources yet so that's going to be fun
pub struct VirtualResource {
pub(crate) name: String,
pub(crate) version: usize,
ty: ResourceType,
}
the 'version' field used to be implicit with just a number of + characters appended to name
(it was bad
)
/// Syntax sugar to easily construct image virtual resources
#[macro_export]
macro_rules! image {
($id:literal) => {
::phobos::prelude::VirtualResource::image($id)
};
}
/// Syntax sugar to easily construct buffer virtual resources
#[macro_export]
macro_rules! buffer {
($id:literal) => {
::phobos::prelude::VirtualResource::buffer($id)
};
}
To add compile time hashing for the string ids I think this is the only part of the public api that needs to change
though it would remain compatible so thats nice
Oh yea
What about stuff for pipelines though? Would you be keeping those as strings?
hmm
for pipelines its only the name right
i think maybe using string names can get inconvenient with pipeline permutations
so its worth thinking about a change for sure
could also go almost fully dynamic with shader objects down the line
but im not too sure about that
Oh yea I forgot those existed lol
I'll check support for the extension rq I wanna see how widespread it is
damn that is a lot worse than I thought lol
most (gtx / rtx) nvidia gpus seem to be supported, none for AMD though
I mean tbf what kinda permutations do you handle in phobos?
none
Its all on the user side
So you would have to write the code for it and then feed your permutations to phobos
And find some way to assign string ids to those permutations
Okok sweet so it doesn't do permutation handling internally?
internal permutation handling of pipelines would be bad imo
Yea that's why I'm asking to make sure lol
yea its not really the responsibility of a lib like this
Yep fair fair
I'm currently working on improving interface / init context for phobos as I feel like it could be a lot simpler than it is rn
Also working on physical device selection
let settings = AppBuilder::new()
.name("cFlake engine")
.scratch_chunk_size(2048u64)
.raytracing(false)
.gpu(GPURequirements {
queues: vec![
QueueRequest { dedicated: false, queue_type: QueueType::Graphics },
QueueRequest { dedicated: true, queue_type: QueueType::Transfer },
QueueRequest { dedicated: true, queue_type: QueueType::Compute }
],
..Default::default()
})
.validation(true)
.surface(Some(SurfaceSettings {
surface_format: None,
present_mode: None,
window: &window,
}));
yea so what I did in my fork is completely get rid of the HeadlessWindowInterface and HeadlessContext, WindowedContext, and ContextInit
Idk if this would be a good thing for phobos but imo I feel like it makes a bit more sense because it doesn't need to take advantage of the type system to make it work, so I just simplified it to making it work without them
(and the window field in the SurfaceSettings stores a &dyn Window to remove the need for generics completely)
that looks fine yeah, I think thats a lot cleaner
Yep. Unfortunately it would a breaking change if we were to implement it
I could make a PR for it if you want me to, since it already worked and I tested it on my fork
Yep that would be nice
NOOOOO
(Please merge it)
I mean tbf it's super easy to fix
Alright, I tried out examples, and tests, they both work
Unfortunately I can't try the fsr2 flag since I don't have it installed yet or raytracing since I don't have an rt card
Also I noticed that you use gh actions; would it be possible to run the gfx tests through gh actions or are you not guaranteed to get a GPU to test with?
iirc penguin was malding about it a while ago trying to get a mock vulkan api or something set up
ooo I see
well I really like the fact that the tests just use the headless context without any necessary overhead GPU test runner shenanigans
but I'd understand if that needs to change for gh action testing
Looking at the pass builder code to add buffer trabsfers it seems like images are assumed? I don't see anything for buffers
Like for example PassResource assumes the resource has a Layout
oh yea i didnt get around to that yet lol
it does? 
i barely know that part of the codebase at this point lol
its not very well written
theres this ResourceType enum
pub enum ResourceType {
/// Image resource
#[default]
Image,
/// Buffer resource
Buffer,
}
It seems layout gets ignored by later passes.
In any case I didn't see anything to add a buffer dependency to a pass
Yeah the layout gets ignored when you chose buffer
it might be missng some methods to actually attach them
but yeah, layout is ignored in that case
However you can call the one for storage image but passing a buffer
And it will work as far as I can see
Haven't tried but later code does check for the resource type
So maybe just a matter of changing the naming (and havifn deprecated functions for comapat)
I dont like that too much because you cant sample a buffer for example
Maybe strongly typing VirtualResource is a way to get around it, not sure
Yeah lol
I'll look into vuk and see if I can come up with a design maybe
Though for now I'd like to actually start working on my renderer lol
understandable lol
So in execute_fn you get a pool which is the localpool. But if I want to use a resource across passes I guess I have to first allocate it then use VirtualResource like any resource?
the local pool lives for the entire frame
so you could also just allocate it from there
