On Mon, 10 Feb 2003 15:43:49 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> Keith Whitwell wrote:
> > Ian Romanick wrote:
> >> The document is not 100% complete. A few sections, such as the
> >> replacement policy, need more discussion before they can be completed.
> >> I have also included an "issues" section in the spirit of "issues"
> >> sections in OpenGL extension documents. I think the most significan
> >> issue is 3.13, but I don't think any of them are trivial. I fully
> >> expect this section to grow. :)
> >
> >
> > 3.13 - I think the only sane option is '2' -- fallback to software when
> > out of memory. I'm pretty sure GL doesn't allow you to silently throw
> > away mipmaps under memory pressure.
>
> That was the consensus that I got from several people around here that
> worked on OpenGL on AIX. I seem to recall that this strategy was used a
> long time, but it caused problems with Quake2. The problem was that the
> app would look at the value reported by GL_MAX_TEXTURE_SIZE and run with
> it. If that caused texture memory to be over-commited, then the app ran
> like a dog.
>
> The best answer might be to make it a configuration option. Let users
> decide to either fallback to sw rasterization, limit the maximum texture
> size, or use some other dirty trick to prevent the fallback (such as
> dropping mipmaps under memory pressure). It's a general problem that
> doesn't have a good solution in OpenGL.
It may be much easier to implement a configuration option that lets the
user choose the maximum texture size instead.
[snip]
> > A small nitpick: you talk about wrapping _tnl_run_pipeline(). I think
> > this isn't a good approach, particularly as not all rendering proceeds
> > through that function, in fact there is no guarentee that drivers even
> > include that function. The cutdown embedded radeon driver on the Mesa
> > embedded-1-branch is an example of such a driver. I would suggest that
> > the points at which we aquire hardware locks are better suited to
> > ensuring resources are present -- although this may be too late to
> > decide that a fallback is required... Hmm...
>
> I based this on what I saw in the radeon driver. It is possible that my
> analysis of that driver was not correct. My impression what that
> textures were brought back into memory in the wrapper function. I
> thought about doing it at lock acquisition time, but I saw a couple of
> problems with that. The biggest problem was that the state at the time
> the lock is acquired may not be the same as when rendering begins. I
> could see that leading to cases where textures or vertex buffers are
> brought into memory (and other data is displaced) that won't be used.
I don't understand this. The wrapper would have to decide what's needed
long before a lock is acquired. Or am I missunderstanding what "lock"
means?
> Basically, I wanted to find the point where we could say "this is the
> state that will be used for some actual rendering." At that point, we
> would make sure that state was available.
>
> In any case, there was some good discussion of the design on #dri-devel
> today. I'm going to make some updates to the document and send out a
> new version in the next day or so.
Enough tottering for today. I didn't follow all the discussions about
the new memory manager before. Now I think I'm catching up. Good work!
Bye,
Felix
__\|/__ ___ ___ ___
__Tsch��_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\�/\ \_____\ \_____\ \______U___just not everything____
[EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
