Bug 3130

Summary: unichrome MaxTextureSize
Product: Mesa Reporter: Dan Smolik <marvin>
Component: Drivers/X11Assignee: mesa-dev
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high CC: thomas
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Patch to enable 1024x1024 textures while having only 10 mipmap levels

Description Dan Smolik 2005-04-26 13:56:13 UTC
I need use texture bigger than 512x512 that now support unichrome_dri.so. I
search info if it is limitation of HW or SW and nothing found. I try modify
via_context.c and increase ctx->Const.MaxTextureLevels from 10 to 11. And all
works absolutly great. It is possible get thins change to CVS.
Thanks
Dan Smolik
Comment 1 Brian Paul 2005-04-26 14:30:58 UTC
Before making this change, we should verify that there's enough memory to
support all the texture units being bound to textures of the maximum size at the
same time.
Comment 2 Dan Smolik 2005-04-26 14:34:46 UTC
(In reply to comment #1)
> Before making this change, we should verify that there's enough memory to
> support all the texture units being bound to textures of the maximum size at the
> same time.
> 

Can I help you with testing ? I have Epia with 256Mb of ram and for graphic is
reserved 64MB.
Comment 3 Dan Smolik 2005-04-29 13:35:36 UTC
I got email about success with bigger texture size.

 Saw your post on the Unichrome list.  Thanks for the idea.  I going to try it
here and see if it clears up some problems I've been having with the Privateer
remake, I may even try to see if I can get 2048x2048 without a horrible crash. 
You may want to pass your patch on to Keith Whitwell over at the Mesa project

I tried 12 and it works as well. I looked at some of the other dri mesa drivers'
xxx_context.c files and 11 seems to be the most common setting, though most
other drivers seem to assign max texture size more dynamically, with 12 being
the upper limit.

Cheers
David 
Comment 4 Dan Smolik 2005-05-14 14:10:11 UTC
I still test my modification and all is OK.  
Comment 5 Thomas Hellström 2005-05-17 14:27:41 UTC
Forgive me if I'm wrong, but you would only need 11 levels if you really specify
11 mipmap levels? Isn't that an awful lot?

Anyway, the Unichrome hardware only supports 10 levels. 

What are you using the big textures for?
 
If you only supply one texture resolution can't you use only level 0? If not,
couldn't you limit yourself to 10 or less mipmap levels and set
GL_TEXTURE_MAX_LEVEL accordingly?

Comment 6 Dan Smolik 2005-05-17 14:54:13 UTC
(In reply to comment #5)
> Forgive me if I'm wrong, but you would only need 11 levels if you really specify
> 11 mipmap levels? Isn't that an awful lot?
Sorry I don't understand well what is mimpmap levels :-(

> 
> Anyway, the Unichrome hardware only supports 10 levels. 
> 
> What are you using the big textures for?
I develop next generation of our presentation system. We use EPIA to grab TV
picture (PAL) put over grabed picture some overlay or text  and display it on
TV. I do it before with SDL, but SDL has not support for double buffering and
VBLANK sync. I now switch to openGL and it partialy  works. I have only problem
with max_texture_size because TV picure is 720x576 and it is bigger then
512x512. When I modified MaxTextureSize all start working. I accordingly think
that it is not limitation in HW but SW.


>  
> If you only supply one texture resolution can't you use only level 0? If not,
> couldn't you limit yourself to 10 or less mipmap levels and set
> GL_TEXTURE_MAX_LEVEL accordingly?
> 
 
Sorry I don't understand. Can I export some enviroment variables to increase
size of texture without recompiling driver ? I need texture 1024x1024 it is all.


Comment 7 Thomas Hellström 2005-05-17 15:18:04 UTC
Mipmap levels are different resolutions of the texture, in your case they would be 
1024x1024, 512x512, .... 1x1, all in all 11 levels, that the texture unit can
choose from to get the best representation on the screen. "OpenGL programming
guide" is an excellent reference.

In your case I figure 1024x1024 would be sufficient; Only using level 0. This
should work unless Mesa uses the driver specified maximum texture level to
determine the maximum size of a base level texture.

The hardware still cannot handle more than 10 levels and your patch may work in
your particular case but fail in other when the user tries to specify 11 mipmap
levels.
 
Comment 8 Dan Smolik 2005-05-17 15:35:03 UTC
(In reply to comment #7)
> Mipmap levels are different resolutions of the texture, in your case they
would be 
> 1024x1024, 512x512, .... 1x1, all in all 11 levels, that the texture unit can
> choose from to get the best representation on the screen. "OpenGL programming
> guide" is an excellent reference.
> 
> In your case I figure 1024x1024 would be sufficient; Only using level 0. This
> should work unless Mesa uses the driver specified maximum texture level to
> determine the maximum size of a base level texture.
Thanks, may be I understand. Can I solve my problem 
setting  GL_TEXTURE_MAX_LEVEL to 0 ? If yes. Is  it right way ?




Comment 9 Thomas Hellström 2005-05-17 15:49:39 UTC
Hmm, it turns out that Mesa apparently uses the maximum number of mipmap levels
to determine the size of the largest texture, even if only a couple of mipmap
levels are used.

I guess one could modify the unichrome driver to skip the highest levels if more
than 10 levels are specified, but I don't know how well that would work.

Anyway, memory should not be an issue, since the Unichrome DDX always assigns at
least 30MB of AGP memory for textures, and only has 2 texture units.
Comment 10 Thomas Hellström 2005-05-17 15:53:36 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Mipmap levels are different resolutions of the texture, in your case they
> would be 
> > 1024x1024, 512x512, .... 1x1, all in all 11 levels, that the texture unit can
> > choose from to get the best representation on the screen. "OpenGL programming
> > guide" is an excellent reference.
> > 
> > In your case I figure 1024x1024 would be sufficient; Only using level 0. This
> > should work unless Mesa uses the driver specified maximum texture level to
> > determine the maximum size of a base level texture.
> Thanks, may be I understand. Can I solve my problem 
> setting  GL_TEXTURE_MAX_LEVEL to 0 ? If yes. Is  it right way ?
> 

I thought so, but i just tried and it didn't work. To be able to handle these
large images, one would need both your patch and additional logic to take care
of the case when the driver tries to upload more than 10 mipmap levels to the
hardware. 


Comment 11 Dan Smolik 2005-05-17 15:59:10 UTC
Yes, I understand. But it is for me too complicated I am not good programmer :-).
Comment 12 Ian Romanick 2005-05-17 16:00:42 UTC
(In reply to comment #9)
> Hmm, it turns out that Mesa apparently uses the maximum number of mipmap levels
> to determine the size of the largest texture, even if only a couple of mipmap
> levels are used.
> 
> I guess one could modify the unichrome driver to skip the highest levels if more
> than 10 levels are specified, but I don't know how well that would work.

This is they way it works on the G200.  The G200 can only have 5 mipmaps, but
can support a maximum texture size of 1024x1024.  In this case, the driver
advertises the full size, but "ignores" the smallest mipmaps if more than 5 are
needed for the complete mipmap stack.
Comment 13 Dan Smolik 2005-05-17 16:10:58 UTC
> This is they way it works on the G200.  The G200 can only have 5 mipmaps, but
> can support a maximum texture size of 1024x1024.  In this case, the driver
> advertises the full size, but "ignores" the smallest mipmaps if more than 5 are
> needed for the complete mipmap stack.
Great it is good idea. 
Comment 14 Thomas Hellström 2005-05-17 16:25:37 UTC
Created attachment 2695 [details] [review]
Patch to enable 1024x1024 textures while having only 10 mipmap levels

Attached a patch that should fix this.
Comment 15 Dan Smolik 2005-05-18 00:23:24 UTC
Thanks. I test it.
Comment 16 Dan Smolik 2005-07-25 20:54:05 UTC
Patch works great. Is any chance get it to main DRI tree ?

Dan
Comment 17 Brian Paul 2006-10-15 10:58:24 UTC
I checked in the patch.
Comment 18 Brian Paul 2006-10-15 15:31:12 UTC
Wrong patch was checked in.
Replaced by patch from Benno Schulenberg posted to mesa3d-dev on 10/10/2006.
Comment 19 Adam Jackson 2009-08-24 12:23:11 UTC
Mass version move, cvs -> git

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.