-
Notifications
You must be signed in to change notification settings - Fork 60
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
WIP: tr_image: downscale image against hardware limits using GL_PROXY feature #1131
base: master
Are you sure you want to change the base?
Conversation
Once you remember what this is for, it would be nice to explain it in the commit message 😄 |
/* From https://www.khronos.org/opengl/wiki/GLAPI/glTexImage3D
> If target is GL_PROXY_TEXTURE_3D, no data is read from data,
> but all of the texture image state is recalculated, checked
> for consistency, and checked against the implementation's
> capabilities. If the implementation cannot handle a texture
> of the requested texture size, it sets all of the image state
> to 0, but does not generate an error (see glGetError).
> To query for an entire mipmap array, use an image array level
> greater than or equal to 1.
From https://www.khronos.org/opengl/wiki/GLAPI/glTexImage3D
> To then query this state, call glGetTexLevelParameter. */ The idea is to attempt a fake upload of the image with the size expected to be uploaded, and get the exact answer from the driver itself if an image with such format and size is accepted or not, before doing the image upload for real. If the driver answers an image of this size for this format is not accepted, reduce the size and retry until the driver accepts. Once an acceptable size is found, upload the image with that smaller size. |
I haven't forgotten what is this for and did not forgot I had this patch for this exact purpose. 😃️ It's just I have to refresh my mind on how it works and to reacquire confidence or not about its status. I have some intention to implement new features about image resizing, but I know I had already had a dozen of commits sleeping for years with things I already implemented for other features I evaluated before. So I thought it was a good idea to start cherry-picking them from their old branch. After 4 years rebasing the branch is not an option anymore, all I can do is to cherry-pick specific commits and port them to the actual code. I'm afraid other ideas I have for other things may introduce more merge conflict with those sleeping commits. |
My recollection is that it turned out that vendors didn't bother to implement GL_PROXY correctly, so using it was a bad idea. |
The doubt about vendor implementation was about That patch was considered by me as ready to merge at the time but this just never happened and it just fall behind other priorities like doing some releases. I never forgot about it and it always had been on my TODO list. Some patches from that branch were already merged at the time, merging the next ones on the line always had ben planned. |
Cherry picked from that old branch:
I haven't touched this code in 4 years so I'm flagging at draft because I need to refresh my mind on this to begin with.