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 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
> would have to support it anyway!
Ok. Please listen to yourself for a moment, and then _think_ about this.
Let's put out some facts, instead of just arguing:
- FSAA is a good idea, especially for games and eyecandy. Maybe the CAD
people don't care, but jaggies are horribly visible to the human eye,
and this is one reason why computer-generated graphics at high
resolution still often looks _more_ fake than a regular old NTSC
picture at some ridiculously low resolution.
- 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.
I doubt anybody disputes these two basic premises. FSAA is a good thing
(assuming the hardware is potent enough ;), and at the same time FSAA is
another example of something that needs support from the low-level driver
some way anyway (possibly only setting a register, I don't know).
But at the same time it is _not_ something that the actual client program
itself needs to care about. It's a very hw-dependent thing (ie different
cards have very different approaches for things like sample selection),
and yet it's largely invisible from a programmatic standpoint at a higher
level.
And I would claim that these two issues are important:
- intimate hw-dependency (ie it's literally _hard_ to have a generic
interface for it - do you really want to engineer some kind of OpenGL
system for letting apps be told what kinds of supersampling patterns
are available to be chosen?)
- invisible to the client (ie the client doesn't need to care about the
feature). And don't get me wrong: the client _can_ see the result of it
(hey, it could just read back the picture it wrote), I just mean that
the client doesn't really need to care or do anything special about it.
Together they say to me "not wrapper, and not OpenGL extensions". In
short, they say "sideband information directly to the low-level driver".
I'm not even going to argue what the implementation for the side-band
information is - I don't think that is the most important part. But I
_will_ argue that it is clearly a good idea, and every _single_ argument
against it has been pure and utter cow-manure.
All the "preloading" etc ideas may be clever, but they are still nothing
but the end product of bovine four-phase food processing. Because they
simply _cannot_ do all the things the driver can much more easily do on
its own ("easily" being relative, of course. There's undoubtedly a lot of
work in the hw-specific stuff, but it's at least an order of magnitude
easier to integrate into the code that already does all the hw accesses
anyway).
And I don't think that FSAA is in any way special. There are tons of
examples of things like this, and once you accept that hw-specific
side-band data is useful and a good idea, there's a number of other
features that are similar.
We've already mentioned anisotropic filtering (which may be more than just
a single value: it looks like all the vendors have somewhat tunable cutoff
parameters etc to avoid doing the full job when not needing to) as being
another of these hw-dependent yet largely client-invisible things. Or it
can be decisions about internal texture formats, and also less direct
things like card texture-memory allocation policies ("compress textures at
upload to conserve memory" or something). Or it could be simple things
like default gamma correction values.
Are these things that can _also_ be done using regular GL interfaces?
Sure. You can do even things like supersampling pattern setup that way.
I'm not saying it is impossible for clients to set all these things by
hand. It's just that it's not necessarily _sensible_ to have the logic to
know about all these things in every program. And it's not a sin to have
two different ways to get to the same end result.
And doing it in the low-level driver is potentially much easier than doing
it anywhere else. I assume that some of the smarter cards you can enable
anisotropic filtering with just a single register - and thus the code
needed to do this might be as simple as just having an initial value that
is dependent on whatever sideband signal you choose, ie you'd end up with
some simply initialization logic like
ctx->anisovalue = sideband ? sidebandvalue : defaultvalue;
(Yeah, and maybe I'm full of shit, and all the cards require tons of setup
for anisotropic filtering. Whatever. I'm a kernel guy, I just want
tuxracer to give me FSAA some day, because I still see jaggies at
1600x1200 on my nice TFT display).
Linus
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
