Brian Paul wrote:
[snip]
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.
Depends... if |alloca()| can safely be used on all platforms
Roland Mainz wrote:
Depends... if |alloca()| can safely be used on all platforms supported
by Mesa then this should be no problem to implement.
I don't think the Solaris implementation of alloca counts as safe
unfortunately, due to this warning in the man page:
If the allocated block is beyond
On Apr 7, 2005 1:30 AM, Brian Paul [EMAIL PROTECTED] wrote:
Feel free to increase MAX_WIDTH/HEIGHT in your copy of Mesa and try
running various apps.
We have increased MAX_WIDTH/HEIGHT in our internal builds but this
limit will still hit the average Linux user using both the Postscript
or
On Apr 7, 2005 2:23 AM, Roland Mainz [EMAIL PROTECTED] wrote:
Brian Paul wrote:
[snip]
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
On Wednesday 06 April 2005 19:35, Roland Mainz wrote:
Brian Paul wrote:
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.
Which leads to some unfortunate problems for printing, think
This comes from some unimplemented functions - tnl tries to call them, but
the pointer is NULL. See r200_swtcl.c::r200InitSwtcl() which does not have
an analog in R300 driver yet.
best
Vladimir Dergachev
On Wed, 6 Apr 2005, Adam K Kirchhoff wrote:
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2919
Summary: glest segfaults on r200
Product: Mesa
On Thu, Apr 07, 2005 at 10:40:55AM -0400, Adam Jackson wrote:
| This would suggest to me one or more of the following:
|
| - xprint should be investigating tiled rendering solutions, possibly based on
| the glxproxy code from Xdmx
| - GL is an architecturally poor match for printing
In OpenGL
On Thursday 07 April 2005 12:53, Allen Akin wrote:
Tiling involves some subtle tradeoffs. The OpenGL spec requires that
the pixel fragments generated by rasterization be unaffected if
primitives are translated by an integral amount in screen coordinates,
or if scissoring is enabled. Those
I haven't got any feedback on this yet. I have made a few improvements
and as far as I'm concerned it's ready for CVS. If no one objects I'll
commit this over the weekend. I'll also update the documentation in the
Wiki about adding new options and translations.
Regards,
Felix
Am Dienstag, den
On Thu, Apr 07, 2005 at 01:29:21PM -0400, Adam Jackson wrote:
| I would think it possible to decompose the scene along notional view volumes
| in the tiler...
In general that doesn't work, because (a) primitives that are clipped
based on the raster position clip in their entirety, rather than
11 matches
Mail list logo
