I was wondering if any of you are still having the problem that Bambu Studio is only using the slower integrated graphics card?
On my three laptops, each with a powerful dedicated graphics card (two GeForce and one ADA), Bambu Studio only uses the slower internal Intel graphics card in the preview window, and it’s really lagging.
I don’t want to disable it completely because the dedicated graphics cards would use so much more power when i am not connected with the power supply.
So, does anyone else have this problem or a solution?
is the issue that the 3d view is slow? or glitches? because you can force one of the cards per app, like if you want the geforce to be the one for bambustudio.exe in Windows settings
I really do not notice a difference, but my graphics card was never exceptionally fast. Some systems need to use internal graphics to prevent crashes from incompatible drivers.
Preview shows the sliced file; slicing is done with the CPU, not the GPU. View changes (pan, rotate, tilt, zoom) use the GPU.
You can see this by watching Task Manager-Performance while slicing.
Power options on a laptop may slow the CPU while operating on battery.
I explored this issue some time back when I noticed that, in my single-GPU system, the slicer did not appear to use the GPU for the actual slicing workload. I even went as far as taking the source code and loading it into AI tools to see what would be involved in modifying it to use NVIDIA CUDA cores. The answers I got from three different AI programs ranged from “not practical” to “research-level modifications.” That was about a year ago, and AI coding tools have improved since then, so the answer may be somewhat different today.
The issue is that most mainstream FDM slicers still perform the actual slicing and G-code generation on the CPU. PrusaSlicer traces back to Slic3r, and OrcaSlicer traces back through Bambu Studio and PrusaSlicer. Cura is different; it uses CuraEngine rather than being a Slic3r derivative.
On the surface, slicing looks like a problem that should be well suited to GPUs because it involves a lot of repeated geometric operations. In practice, though, a slicer is doing more than just intersecting triangles with layer planes. It also has to build valid loops, handle broken or imperfect meshes, generate offsets, supports, infill, perimeters, travel moves, and extrusion logic while preserving numerical reliability. That makes GPU acceleration much harder than simply sending the existing code to CUDA.
It is still a pity, because there are parts of the workload that seem like they should benefit from GPU acceleration. But based on the current state of the major slicers, GPU-based slicing is not something that has become standard, and implementing it would likely require a substantial redesign rather than a simple performance patch.
