On Tue, 22 May 2001, Daryll Strauss wrote:
>> Right, but what I want is "Here are your options, and you cannot
>> choose DRI in a configuration that will make the machine lock up
>> due to memory constraints."
>
>We shouldn't lock up. That's a bug. We should fix it.
Ok, I wasn't completely sure what was correct, now I know, and
will report this stuff as bugs directly.
>The trickier one is "Why isn't 3D hardware accelerated." All we can do
>is report that we disabled for the user.
That I can handle easily: CLOSED->NOTABUG ;o)
>> Just a question: Does Windows suffer from similar problems?
>> I've never noticed myself, but I'm just wondering how this is
>> handled in Windows video drivers, or is it a problem there too?
>> Or is this something due to X not being able to change depth on
>> the fly?
>
>X gives you a ton of flexibility in configuring the device. Normally
>Windows gives you specific choices of what modes they accept. So, if X
>were Windows we would just enabled everything and say "Nothing larger
>than 1280x1024 is supported."
Ok, that makes sense. Windows trades flexibility for simplicity.
>There is a technical issue we should fix at some point, which is to
>improve offscreen memory management. Right now X and 3D don't cooperate
>as nicely as they should. That would let us use memory more efficiently.
4.2.0? ;o)
>> Also, is it the RandR extension that will provide depth switching
>> support? I remember Keith talking at the XFree86 BOF at LWE
>> about it. Does depth switching fit under "Resize"? Or is that
>> another extension?
>
>Yes, that supports depth switching. Although I think it does it by
>translating data to a native depth so the memory requirements are still
>there. Anyone else know for sure?
I recall a fair bit of what Keith talked about and it sounded
quite good IMHO, slowdowns would be minimal.
>Another thing games do in Windows is go into "full screen
>mode." That allows them resize on the fly and then grab all the
>rest of the resources because they know nothing else is
>running.
That would be very good to have, but not if it opens up the
possibility of what happens in windows where some game crashes
and foobs your display, desktop, etc.
>(For example, your desktop is at 1600x1200, but you start quake
>at 640x480 full screen. We now can pretend the desktop is
>640x480 and grab all those resources back) Fullscreen mode is a
>little tricky to do right. We have an architecture to support
>it, but most of our drivers don't do much with it yet.
Great. These are all questions I get asked all the time, and
wasn't sure of the proper answers. It will indeed be cool when
all of this stuff comes to be. Gives us something to sit and
pant over. ;o)
>Also, to do it right, applications would have to make a call to
>change to full screen mode.
Right. I'm sure with RandR and other new code, many growing
pains will show up, but I think the way Linux moves so quickly
there wont be too much overlap time.
Thanks Daryll, and everyone else for giving such detailed
answers. It helps me to plan things in my mind, and what to
expect in the future, etc.
Take care,
TTYL
----------------------------------------------------------------------
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc. Ontario, Canada, P6C 5B3
http://www.redhat.com Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS: ftp://people.redhat.com/mharris/testing
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
