We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2345

Summary: Large images not loading on intel chipset
Product: SDL Reporter: mattreecebentley
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED INVALID QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: amaranth72, icculus
Version: 2.0.1   
Hardware: x86   
OS: Windows (XP)   

Description mattreecebentley 2014-01-11 07:07:38 UTC 
Running mingw32, codelite, C++, under xp sp3.

On Intel graphics 
(eeepc 1000ha, mobile intel 945 graphics chipset family, 
maximum shared video ram 224MB)

in a hardware-accel mode, SDL won't load/display a large-sized (4000x1440x24bit in this case - 16.5MB video memory) image (this works fine on systems with more grunty graphics cards). Smaller-sized images work fine.

I'd been told on the SDL forums that if SDL can't load an image into vid memory, it would load it into ram, essentially creating a surface. Is this true or false?
If false, how do I check the video memory size?
It should be loading into video shared memory at any rate.


At any rate, it could potentially be buggy drivers, but could also potentially be an SDL bug for all I know.
Comment 1 Alex Szpakowski 2014-01-12 14:58:59 UTC 
GPUs / drivers have a maximum texture size. For lower-end and very old GPUs, this tends to be 2048x2048 or 4096x4096.

I don't think it'd make sense for SDL to switch its entire pipeline to software rendering (which it'd need to do) if one asset's size is larger than the GPU's maximum.

http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_TEXTURE_SIZE has some data on the max texture size for various GPUs/drivers.
Comment 2 Alex Szpakowski 2014-01-12 15:09:48 UTC 
Also, SDL_GetRendererInfo[1][2] will give you the maximum supported texture width and height at runtime.

[1]: http://wiki.libsdl.org/SDL_GetRendererInfo
[2]: http://wiki.libsdl.org/SDL_RendererInfo
Comment 3 mattreecebentley 2014-01-12 21:10:00 UTC 
Thanks for that Alex, it more-or-less clears it up,
two questions: 
1. Is there anywhere in SDL to check available video texture memory? ie. not just max width/height

2. Would it be possible to - rather than shifting the entire pipeline into software - implement a texture as a surface "under the hood" if for some reason (either video ram limitations or max height/width) it won't fit into video memory? Or would that be taking the library away from the bare metal?
Comment 4 Ryan C. Gordon 2015-02-19 02:09:46 UTC 
> 2. Would it be possible to - rather than shifting the entire pipeline into
> software - implement a texture as a surface "under the hood" if for some
> reason (either video ram limitations or max height/width) it won't fit into
> video memory? Or would that be taking the library away from the bare metal?

One could build a system that splits a surface into multiple textures, but we're probably not going to do this in SDL, especially as even low-end hardware can take pretty big textures now, too.

--ryan.
Comment 5 mattreecebentley 2015-02-19 21:18:54 UTC 
Yes, this is how I've implemented it in my library.