-
-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
passing null pointers to glBufferData/glBufferNamedData (orphaning) #254
Comments
i believe the functions would just look like this: unsafe fn buffer_data_null(&self, target: u32, length: isize, usage: u32) {
let gl = &self.raw;
gl.BufferData(
target,
length,
std::ptr::null() as *const std::ffi::c_void,
usage,
);
}
unsafe fn named_buffer_data_null(&mut self, buffer: glow::Buffer, length: isize, usage: u32) {
let gl = &self.raw;
gl.NamedBufferData(
buffer.0.get(),
length,
std::ptr::null() as *const std::ffi::c_void,
usage,
);
} |
twuky
changed the title
passing null values to glBufferData/glBufferNamedData (orphaning)
passing null pointers to glBufferData/glBufferNamedData (orphaning)
Aug 21, 2023
A small breaking change to the API to support |
This already exists as Lines 1368 to 1376 in 721b09e
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So it looks like, in theory,
glBufferData
andglNamedBufferData
support passing a null pointer to the data argument, which tells the driver to orphan the old data and allocate new space. Doing this seems to be a performance optimization in some cases (when you want to update a buffer the gpu is currently reading for a draw call)Right now in glow, these functions are replaced by type-explicit ones, ie.
named_buffer_data_u8_slice
, so it doesn't look like there's a way for me to try out this orphaning concept yet. Would this be something okay to add to glow?I imagine it would have to be some new function like
named_buffer_data_null
, or outright includingnamed_buffer_data
but making the data argumentOption<&[u8]>
- working similar to how glow handlesbuffer_storage
. I definitely wouldn't want to introduce a breaking change to the API though, I'm just curious if either of these would be a fine addition?The text was updated successfully, but these errors were encountered: