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 jus
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
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 t
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 printin
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,
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 sof
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 beyon
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 platfo
Roland Mainz 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 work.
Depends... if |alloca()| can safely be used on all pla
Brian Paul wrote:
> >>>Ian Romanick wrote:
> >>>When I look at xc/extras/Mesa/src/mesa/main/config.h I see more items on
> >>>my wishlist: Would it be possible to increase |MAX_WIDTH| and
> >>>|MAX_HEIGHT| (and the matching texture limits of the software
> >>>rasterizer) to 8192 to support larger d
Brian Paul wrote:
> >>>On Apr 5, 2005 10:11 PM, Brian Paul <[EMAIL PROTECTED]> 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 mor
Roland Mainz wrote:
Brian Paul wrote:
On Apr 5, 2005 10:11 PM, Brian Paul <[EMAIL PROTECTED]> 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
[I'm just posting this to dri-devel. We can summarize the results to
xorg-arch later.]
After much discussion in the original thread, it looks like people are
willing, even eager, to make very significant changes to the loader /
driver interface. Good stuff! If we're going to do this, we shou
Julien Lafon wrote:
On Apr 6, 2005 3:37 PM, Brian Paul <[EMAIL PROTECTED]> wrote:
Julien Lafon wrote:
On Apr 5, 2005 10:11 PM, Brian Paul <[EMAIL PROTECTED]> wrote:
Will increasing MAX_WIDTH/HEIGHT affect applications which run in
small windows or only those which use resolutions exceeding the 4Kx4
On Apr 6, 2005 3:37 PM, Brian Paul <[EMAIL PROTECTED]> wrote:
> Julien Lafon wrote:
> > On Apr 5, 2005 10:11 PM, Brian Paul <[EMAIL PROTECTED]> wrote:
> > Will increasing MAX_WIDTH/HEIGHT affect applications which run in
> > small windows or only those which use resolutions exceeding the 4Kx4K
> >
On Apr 5, 2005 10:11 PM, Brian Paul <[EMAIL PROTECTED]> wrote:
> Roland Mainz wrote:
> > Ian Romanick wrote:
> > When I look at xc/extras/Mesa/src/mesa/main/config.h I see more items on
> > my wishlist: Would it be possible to increase |MAX_WIDTH| and
> > |MAX_HEIGHT| (and the matching texture limi
Julien Lafon wrote:
On Apr 5, 2005 10:11 PM, Brian Paul <[EMAIL PROTECTED]> wrote:
Roland Mainz wrote:
Ian Romanick wrote:
When I look at xc/extras/Mesa/src/mesa/main/config.h I see more items on
my wishlist: Would it be possible to increase |MAX_WIDTH| and
|MAX_HEIGHT| (and the matching texture li
Ian Romanick wrote:
Brian Paul wrote:
Adam Jackson wrote:
Yeah, I just threw out glXGetProcAddress as a suggestion. It's
probably better to pass this table into the driver through the create
context method.
[snip]
Right. glXGetProcAddress() should not be used by libGL or the drivers
to get in
Brian Paul wrote:
Adam Jackson wrote:
Yeah, I just threw out glXGetProcAddress as a suggestion. It's
probably better to pass this table into the driver through the create
context method.
[snip]
Right. glXGetProcAddress() should not be used by libGL or the drivers
to get internal function point
Adam Jackson wrote:
On Tuesday 05 April 2005 16:11, Brian Paul wrote:
Roland Mainz wrote:
Another item would be to look into what's required to support visuals
beyond 24bit RGB (like 30bit TrueColor visuals) ... someone on IRC
(AFAIK ajax (if I don't mix-up the nicks again :)) said that this may
re
On Tuesday 05 April 2005 16:11, Brian Paul wrote:
> Roland Mainz wrote:
> > Another item would be to look into what's required to support visuals
> > beyond 24bit RGB (like 30bit TrueColor visuals) ... someone on IRC
> > (AFAIK ajax (if I don't mix-up the nicks again :)) said that this may
> > requ
Adam Jackson wrote:
On Tuesday 05 April 2005 19:03, Ian Romanick wrote:
Adam Jackson wrote:
I have another one: Hide all the functions that start with XF86DRI*, and
expose them to the driver through a function table or glXGetProcAddress
rather than by allowing the driver to call them directly. Th
On Tuesday 05 April 2005 19:03, Ian Romanick wrote:
> Adam Jackson wrote:
> > I have another one: Hide all the functions that start with XF86DRI*, and
> > expose them to the driver through a function table or glXGetProcAddress
> > rather than by allowing the driver to call them directly. This wil
Nicolai Haehnle wrote:
On Tuesday 05 April 2005 22:11, Brian Paul wrote:
If you increase MAX_WIDTH/HEIGHT too far, you'll start to see
interpolation errors in triangle rasterization (the software
routines). The full explanation is long, but basically there needs to
be enough fractional bits in
Ian Romanick wrote:
>
> For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
> driver interface. There is a *LOT* of crap hanging around in both libGL
> and in the DRI drivers that exists *only* to maintain backwards
> compatability with older versions of the interface. Since it's
On Tuesday 05 April 2005 22:11, Brian Paul wrote:
> If you increase MAX_WIDTH/HEIGHT too far, you'll start to see
> interpolation errors in triangle rasterization (the software
> routines). The full explanation is long, but basically there needs to
> be enough fractional bits in the GLfixed dat
Adam Jackson wrote:
I have another one: Hide all the functions that start with XF86DRI*, and
expose them to the driver through a function table or glXGetProcAddress
rather than by allowing the driver to call them directly. This will simplify
the case where the X server is itself linked against
On Tuesday 05 April 2005 14:06, Ian Romanick wrote:
> For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
> driver interface. There is a *LOT* of crap hanging around in both libGL
> and in the DRI drivers that exists *only* to maintain backwards
> compatability with older versions o
Keith Whitwell wrote:
Ian Romanick wrote:
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both
libGL and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface
Roland Mainz wrote:
Ian Romanick wrote:
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both libGL
and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface. Si
Ian Romanick wrote:
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both libGL
and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface. Since it's crap, I
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both libGL
and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface. Since it's crap, I
would very much lik
32 matches
Mail list logo
