Proprosed break in libGL / DRI driver ABI

Brian Paul brian.paul at tungstengraphics.com
Wed Apr 6 16:30:29 PDT 2005


Roland Mainz wrote:
> Brian Paul wrote:
> 
>>>>>On Apr 5, 2005 10:11 PM, Brian Paul <brian.paul at tungstengraphics.com> wrote:
>>>>>Will increasing MAX_WIDTH/HEIGHT affect applications which run in
>>>>>small windows or only those which use resolutions exceeding the 4Kx4K
>>>>>limit?
>>>>
>>>>Increasing MAX_WIDTH/HEIGHT will result in more memory usage
>>>>regardless of window size.
>>>
>>>Do you know how much memory is additionally allocated? If it is less
>>>than 1MB then it may not be worth to worry about...
>>
>>If you do a grep in the sources for MAX_WIDTH you'll see that it's
>>used in lots of places.  Some are for stack allocations, others are
>>for heap allocations.  It would take some effort to determine exactly
>>how much more memory would be used.  I know of at least one structure
>>that contains arrays dimensioned according to MAX_WIDTH that's
>>currently just under 1MB.  That's probably the largest.
> 
> 
> What about making MAX_WIDTH and MAX_HEIGHT runtime-configurable - would
> that be possible (for stack allocations the Mesa code then has to depend
> on |alloca()|) ?

Probably do-able, but a lot of work.


>>>>As is, you can't exceed 4K x 4K resolution without increasing
>>>>MAX_WIDTH/HEIGHT.  Your glViewport call will be clamped to those
>>>>limits if you specify larger.
>>>
>>>Let me reformulate my question: Will increasing MAX_WIDTH/HEIGHT break
>>>any existing application at normal video screen sizes?
>>
>>Probably not, but I'm not 100% sure.
> 
> 
> What about making an experiment and bump the value to 8Kx8K and check if
> we see anything which breaks in the following months ?

Ordinary applications would probably be fine (I think), but I'm fairly 
confident that if someone created an 8Kx8K framebuffer and draw large 
triangles things would not work properly.

Feel free to increase MAX_WIDTH/HEIGHT in your copy of Mesa and try 
running various apps.

-Brian


More information about the xorg-arch mailing list