Keith Whitwell wrote:
I suspect that will fix the texture problems. Somebody (that actually
has
Rage128 hardware!) should go through and eliminate the new_state field
from
r128_context altogether. I will make similar changes to the MGA
driver. It
would be nice to have fundamental things,
Philip Brown wrote:
How about moving
os-support/{linux,bsd}/drm/kernel/drm.h
into
os-support/shared/drm/kernel/drm.h
After all, it defines the core drm IOCTLS and data structures. It should be
common, not in OS-specific directories.
There are trivial differences between the two versions
Ian Romanick wrote:
On Tue, Dec 03, 2002 at 05:05:26PM -0800, Ian Romanick wrote:
Unless there are any objections, I'm going to commit a merge from the trunk
to the texmem-0-0-1 branch tomorrow (Wednesday). I've tested the merge on
the R100, and I'll test it on an M6 and a G400 before I commit
On Thu, Dec 05, 2002 at 11:48:10AM -0800, Ian Romanick wrote:
On Thu, Dec 05, 2002 at 11:10:56AM -0800, magenta wrote:
On Thu, Dec 05, 2002 at 10:22:39AM -0800, Ian Romanick wrote:
I completely understand how the wrapper idea works. I'm just saying that
there is a large number of
On Thu, Dec 05, 2002 at 12:58:49PM -0800, magenta wrote:
On Thu, Dec 05, 2002 at 11:48:10AM -0800, Ian Romanick wrote:
On Thu, Dec 05, 2002 at 11:10:56AM -0800, magenta wrote:
On Thu, Dec 05, 2002 at 10:22:39AM -0800, Ian Romanick wrote:
...and this is one of them. There is NO OpenGL
On Wed, Dec 04, 2002 at 06:28:55PM -0800, Allen Akin wrote:
On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote:
| Remote indirect rendering is a problem no matter how you slice it.
Well, maybe not if you handle preference-setting at the application
level, rather than trying to do
On Thu, Dec 05, 2002 at 01:23:42PM -0800, Ian Romanick wrote:
Yes, I did reread it, which is why I then suggested glXChooseVisual as the
point of change (since it's in visual selection that it's enabled), which
is exactly the reason why it SHOULDN'T be in the driver - a wrapper library
On Thu, 5 Dec 2002, magenta wrote:
Well that sucks. I guess I'd never be able to enable super-sampled FSAA
with your wrapper on my R100. Even though I CAN do it with a driver-based
tweak utility on some other operating system.
But it's not even supported in the DRI driver on the
On Thu, Dec 05, 2002 at 02:13:26PM -0800, magenta wrote:
On Thu, Dec 05, 2002 at 01:23:42PM -0800, Ian Romanick wrote:
Yes, I did reread it, which is why I then suggested glXChooseVisual as the
point of change (since it's in visual selection that it's enabled), which
is exactly the
On Thu, Dec 05, 2002 at 03:28:49PM -0800, Linus Torvalds wrote:
On Thu, 5 Dec 2002, magenta wrote:
Well that sucks. I guess I'd never be able to enable super-sampled FSAA
with your wrapper on my R100. Even though I CAN do it with a driver-based
tweak utility on some other
On Thu, Dec 05, 2002 at 03:28:49PM -0800, Linus Torvalds wrote:
| Let's put out some facts, instead of just arguing:
|
| - FSAA is a good idea...
Definitely.
| - FSAA _cannot_ be done by a wrapper. End of discussion.
Well, that depends on the hardware. Supersampled FSAA can be done
without
On Thu, Dec 05, 2002 at 03:56:09PM -0800, Ian Romanick wrote:
But it's not even supported in the DRI driver on the R100... It's not like
the wrapper can magically make functionality which isn't there to begin
with appear, but in order to do the tweak in teh driver itself, the driver
On Thu, 5 Dec 2002, magenta wrote:
- FSAA _cannot_ be done by a wrapper. End of discussion. It needs driver
explicit support for it. It's not a select one default value when
presented a choice kind of passthrough thing.
Why not?
Have you seen what the different FSAA cards can
On Thu, Dec 05, 2002 at 04:57:06PM -0800, Linus Torvalds wrote:
I doubt the second one. Apparently my understanding of how FSAA is enabled
in an OpenGL application is flawed
Yes. For one, you seem to think thatit's just a matterof selecting how
many pixels to sample. That's not the
On Thu, Dec 05, 2002 at 05:38:41PM -0800, Linus Torvalds wrote:
On Thu, 5 Dec 2002, Allen Akin wrote:
Putting it in kernel guy terms, it's like sideband mechanisms for
talking to device-dependent code in the kernel that bypass the syscall
interface. A few such things exist for
On Thu, 5 Dec 2002, magenta wrote:
There's enough cases that the wrapper couldn't cover that we'd have to
implement something in the driver anyway. For example, one of the current
env vars tells the Radeon driver to not use HW TCL. How could the wrapper
do that?
That's not what the
Actually 1 and 2 are correct for unit 0 and 1, since they are bitflags.
However, this switch/case isn't needed at all here since the flags are
updated elsewhere. The default was hit with a value of zero because
t-base.bound isn't actually set until after this (in update_tex_common in
Apologies for re-ordering your comments, but I thought it might make my
reply more clear.
On Thu, Dec 05, 2002 at 05:38:41PM -0800, Linus Torvalds wrote:
|
| On Thu, 5 Dec 2002, Allen Akin wrote:
|
| Putting it in kernel guy terms, it's like sideband mechanisms for
| talking to
On Thu, Dec 05, 2002 at 07:25:08PM -0800, Allen Akin wrote:
But to make this constructive, I think the best thing we can do is to
generate a list of the state that people want to tweak. There's a lot
of low-level state, so it could be a *very* long list. Once it exists,
we'll have a better
On Thu, Dec 05, 2002 at 03:21:46PM -0600, D. Hageman wrote:
Careful, let us stick to the technical discussion rather then personal
attacks on how I choose to express myself. Don't attack the analogies
themselves, but rather the content that preceeded them and the point
that they were very
20 matches
Mail list logo
