# Paraview 5.11.0 EGL vs Mesa - "Invalid Texture Dimensions"
**URL:** https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029
**Category:** ParaView Support
**Created:** [October 12, 2023, 2:40pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029 "2023-10-12T14:40:20Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@jgrime](https://discourse.paraview.org/u/jgrime)
#### Post date: [October 12, 2023, 2:40pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/1 "2023-10-12T14:40:20Z")
I’m trying to compare the GPU-accelerated Paraview 5.11.0 in client/server mode to the CPU version under various conditions (number of GPUs, number of cores, etc). The test server is a dual-GPU Linux machine (Ubuntu 20.0.4 LTS) with two Xeon processors and 256 GiB of RAM.
The 5.11.0 EGL version (downloaded from the ParaView website) seems to work fine on my ~15 GiB volumetric test data. However, I can’t seem to find a command line switch to disable GPU acceleration to test the “pure CPU” performance to compare to the GPU accelerated timings.
I therefore tried the 5.11.0 Mesa variant (again downloaded from the ParaView website) and when I try to load the test data I get the following message:
```auto
ERROR: OpenGL MAX_3D_TEXTURE_SIZE is 2048
( 107.550s) [pvserver] vtkVolumeTexture.cxx:943 ERR| vtkVolumeTexture (0x15847020): Invalid texture dimensions [6180, 4135, 623]
```
Given that I’m faking the graphics hardware via [Mesa](https://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D), is there a way to disable this limitation? I’ve got plenty of RAM to use, after all!
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [October 23, 2023, 11:33am UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/2 "2023-10-23T11:33:40Z")
> [@jgrime](#):
>
> Mesa
Do you mean the OSMesa version ?
---
### Author:  [@jgrime](https://discourse.paraview.org/u/jgrime)
#### Post date: [October 23, 2023, 1:24pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/3 "2023-10-23T13:24:16Z")
Sure do! `ParaView 5.11.0-osmesa-MPI-Linux-Python3.9-x86_64` in case the details are relevant.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [October 23, 2023, 1:26pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/4 "2023-10-23T13:26:48Z")
Can you try with the nightly instead of 5.11.0 ?
---
### Author:  [@jgrime](https://discourse.paraview.org/u/jgrime)
#### Post date: [October 23, 2023, 2:03pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/5 "2023-10-23T14:03:57Z")
```auto
jgrime:~/paraview_mesa/ParaView-master-5.11.1-1862-g99cf1048e5-osmesa-MPI-Linux-Python3.10-x86_64$ mpiexec -np 1 bin/pvserver
Waiting for client...
Connection URL: cs://xxx:11111
Accepting connection(s): xxx:11111
Client connected.
Failed to create /home/jgrime/.cache/mesa_shader_cache for shader cache (Permission denied)---disabling.
ERROR: OpenGL MAX_3D_TEXTURE_SIZE is 2048
(1560.538s) [pvserver] vtkVolumeTexture.cxx:944 ERR| vtkVolumeTexture (0x3d1e9d0): Invalid texture dimensions [6180, 4135, 623]
```
Nope. 😔
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [October 23, 2023, 2:22pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/6 "2023-10-23T14:22:12Z")
Looks like a limitation of the osmesa driver.
---
### Author:  [@jgrime](https://discourse.paraview.org/u/jgrime)
#### Post date: [October 23, 2023, 2:32pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/7 "2023-10-23T14:32:18Z")
Oh well, such is life.
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [October 25, 2023, 10:39pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/8 "2023-10-25T22:39:06Z")
If you wanted to, you could raise the limit either by submitting a change to the [mesa code base](https://gitlab.freedesktop.org/mesa/mesa) or making a local edit to mesa and compiling both it and ParaView yourself. That’s the only way to raise this limit.
---
### Author:  [@muratmaga](https://discourse.paraview.org/u/muratmaga)
#### Post date: [October 3, 2024, 1:54am UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/9 "2024-10-03T01:54:26Z")
@cory.quammen can you point out to the specific place this can be changed? I am trying the openSWR on a CPU only system and getting this error. I tried modifying this section, but no luck so far?
> **[src/gallium/drivers/llvmpipe/lp\_limits.h · main · Mesa / mesa · GitLab](https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/llvmpipe/lp_limits.h#L52)**
>
> Mesa 3D graphics library
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [October 3, 2024, 1:53pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/10 "2024-10-03T13:53:37Z")
A timely question, I was just looking into this recently. The limit is sadly not just an arbitrarily hard-coded limit, as I had hoped, but is rather set to account for the indexing limits supported by 32-bit integers used in the llvmpipe driver. Note the helpful comment above the code you linked to:
```plaintext
* 2GB is the actual max currently (we always use 32bit offsets, and both
* llvm GEP as well as avx2 gather use signed offsets).
```
So I’m afraid it would take far deeper changes in this driver to support image volumes larger than 2GB in size.
---
### Author:  [@muratmaga](https://discourse.paraview.org/u/muratmaga)
#### Post date: [October 3, 2024, 5:10pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/11 "2024-10-03T17:10:37Z")
Ok, thanks. I wasn’t sure how to interpret the comment. So that 2GB limit is quite limiting for anything to do. It seems the individual texture dimensions can be set higher with `#define LP_MAX_TEXTURE_3D_LEVELS 12 /* 2K x 2K x 2K for now */`
and I successully managed to render volumes 2560x2560x130 in dimension, but hard memory limitation is rather blocking.
---
### Author:  [@muratmaga](https://discourse.paraview.org/u/muratmaga)
#### Post date: [October 3, 2024, 5:46pm UTC](https://discourse.paraview.org/t/paraview-5-11-0-egl-vs-mesa-invalid-texture-dimensions/13029/12 "2024-10-03T17:46:05Z")
There is a parallel thread I created in Slicer forum for the types of the test I have done:
> **[3D rendering performance without GPU](https://discourse.slicer.org/t/3d-rendering-performance-without-gpu/37160/12?u=muratmaga)**
>
> Making some more progress: I think this is the place to change the limits on 3D texture dimensions SWR\_MAX\_TEXTURE\_3D\_LEVELS: I changed the value from 12 to 14, assuming it would provide 8K textures size. This worked up to a point. I can...