search

ClearVolume / clearvolume

ClearVolume is a real-time live 3D visualization library designed for high-end volumetric microscopes such as SPIM and DLSM microscopes. With ClearVolume you can see live on your screen the stacks acquired by your microscope instead of waiting for offline post-processing to give you an intuitive and comprehensive view on your data.
http://clearvolume.github.io
GNU Lesser General Public License v3.0
44 stars 11 forks source link

handle case when CL_R channel order is not supported #41

Open maweigert opened 8 years ago

maweigert commented 8 years ago

On some older GPU CL_R is not in the supported image channel orders and an excpetion is raised when creating the volumetric texture - we should use RGBA then.

skalarproduktraum commented 8 years ago

Do you know what GPUs are affected by this? I remember only seeing this on Intel Integrated Graphics 3000, which only has 384MB of RAM and might therefore be not too useful anyway.

maweigert commented 8 years ago

Yes, I remember it to be an integrated Intel HD 3000 - which early 2011 MacBook Pros without dedicated GPU seem to be working on. As for the 384MB, afaik RAM size is not fixed anyway for integrated cards as they take it from the main memory and that share is adjustable. But you're right, only few users of CV with such a setup would enjoy the render speed even with a supported image format. Any case, I'd rate it low priority.

skalarproduktraum commented 8 years ago

I'd vote for closing the issue. If we have to use RGBA, this would increase the amount of memory needed by a factor of four. Considering these machines are very memory constrained anyway, it would mean the approximately useful volume size would be something ~256MiB. Alternatively, we could also use CL_LUMINANCE, which was supported on the old GPUs if I'm not mistaken. Merit unclear, nevertheless.

skalarproduktraum commented 8 years ago

On a related note, did you benchmark performance image buffers vs. regular buffers for volume rendering by chance? Using regular buffers would also solve this issue, but would probably introduce indexing overhead.

maweigert commented 8 years ago

1) As for closing: I still would rather see CV rendering slow than just throw an exception in this case. In the meantime I've downgraded the issue to "enhancement" rather than "bug" to not let anyone trying to fix the latter waste time on that non important one ;)
2) Buffers vs textures: I did some benchmarking in the past indicating that for the random orientation memory traversal we use for the max project rendering the texture cache is indeed better suited and faster than the possible uncoalesced traversal for buffers (e.g. when rendering along the z axis). Plus interpolation comes in for free what made the implementation looking cleaner.

skalarproduktraum commented 8 years ago

1) :+1: 2) thanks for the info, so let's keep it the way it is.