Ian Romanick wrote:
Alan Hourihane wrote:
On Tue, Mar 25, 2003 at 11:27:17PM +, Keith Whitwell wrote:
Alan Hourihane wrote:
If there's any architectural reason why we can't use XFree86's module
loader for OS indepence here ?
The whole point of the drmCommand*() interface is that it's
On Wed, Mar 26, 2003 at 12:10:48AM -0800, Ian Romanick wrote:
Philip Brown wrote:
Well, okay, there needs to be a little extra handholding between server and
client. So, you add a GLX_dri_reserve_mem extension or something that
reserves video memory by proxy. Or do it in some more direct
Hi,
I have heard from the xscreensaver maintainer, after I
mentioned that I could run OpenGL xscreensaver hacks
by doing (e.g.)
$ flyingtoasters -root
but that they all failed when launched from
xscreensaver. His reply was:
The window that it's drawing on might have a
different visual ID, if
On Wed, 2003-03-26 at 01:15, Ian Romanick wrote:
From a security perspective, people may want to disable direct
rendering. There is a shared memory segment that an evil program
could muck with and cause DoS problems. I probably haven't thought
about it enough, but I can't see how would
Jens-
I agree with you, supporting HW accelerated indirect rending would be a good
thing.
Take a look at the DRI high level design doc:
http://dri.sourceforge.net/doc/design_high_level.html
In section 4.3, Indirect Rendering, there's a section on Multi-rendering
in a single address
Chris Rankin wrote:
Hi,
I have heard from the xscreensaver maintainer, after I
mentioned that I could run OpenGL xscreensaver hacks
by doing (e.g.)
$ flyingtoasters -root
but that they all failed when launched from
xscreensaver. His reply was:
The window that it's drawing on might have a
--- Brian Paul [EMAIL PROTECTED] wrote:
An issue perhaps, but not a bug.
There's no X or GLX policy that says the root window
must use a GLX visual
that features a depth buffers, stencil buffer, alpha
channel, double-buffering, etc.
Perhaps not, but:
a) XFree86 4.2.1, 4.2, 4.1, 4.0 etc
Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
An issue perhaps, but not a bug.
There's no X or GLX policy that says the root window
must use a GLX visual
that features a depth buffers, stencil buffer, alpha
channel, double-buffering, etc.
Perhaps not, but:
a) XFree86 4.2.1,
http://www.realitydiluted.com/mirrors/reality.sgi.com/
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
On Mit, 2003-03-26 at 08:45, Philip Brown wrote:
Video mem is a core X server resource, and should be reserved through the
core server, always.
Actually, I thought we're talking about a scheme where the server is
only a client of the DRM memory manager.
--
Earthling Michel Dänzer
Title: index_spam
Introducing VP-RX Pills
NO.1
Penis Enlargement Pill On The Market!
* Gain 3+ Full Inches In Length
* Expand Your Penis Up To 20% Thicker
* Stop Premature Ejaculation!
* Produce Stronger Erections
* 100% Safe To Take, With No Side Effects
* Fast Distribution Worldwide
* Sold
Michel Dänzer wrote:
On Mit, 2003-03-26 at 08:45, Philip Brown wrote:
Video mem is a core X server resource, and should be reserved through the
core server, always.
Actually, I thought we're talking about a scheme where the server is
only a client of the DRM memory manager.
Yes. It would be a
Philip Brown wrote:
On Wed, Mar 26, 2003 at 12:10:48AM -0800, Ian Romanick wrote:
Philip Brown wrote:
Well, okay, there needs to be a little extra handholding between server and
client. So, you add a GLX_dri_reserve_mem extension or something that
reserves video memory by proxy. Or do it in some
Jens Owen wrote:
Ian,
I think you're making a mountain out of a mole hill, but I like the
mountain that you're trying to build. Supporting HW accellerated
indirect rendering would be a good thing, but it's not necessary for the
change you're trying to make.
Right. It's not required for what
--- Brian Paul [EMAIL PROTECTED] wrote:
Any application which depends upon the root window
having particular GLX attributes is in error.
It's a screensaver. Using the root window would seem
to be a requirement here. So what you're really saying
is Who cares if you can't perform OpenGL / direct
--- Suzy Deffeyes [EMAIL PROTECTED] wrote: So
xscreensaver needs visual 0x25 but the default
visual is 0x23.
To work around it, could you fire up the server with
'-cc 0x25' to change the default visual?
No, because that's not what the -cc parameter does.
This parameter seems to control the
On Wed, 2003-03-26 at 17:59, Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
Any application which depends upon the root window
having particular GLX attributes is in error.
It's a screensaver. Using the root window would seem
to be a requirement here. So what you're really
--- Alan Cox [EMAIL PROTECTED] wrote: On
Wed, 2003-03-26 at 17:59, Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED]
wrote:
Any application which depends upon the root
window
having particular GLX attributes is in error.
It's a screensaver. Using the root window would
seem
On Tue, 25 Mar 2003, Michael Thaler wrote:
Hello,
I just compiled and installed the latest linux developer kernel. I
tried to install the Mach64 binary drivers from
www.retinalburn.com. With kernel 2.4.20 it works fine for me, but with
kernel 2.5.66 I get the following error message:
On Wed, Mar 26, 2003 at 09:14:37AM -0800, Ian Romanick wrote:
Philip Brown wrote:
Consider the GLX_dri_reserve_mem as equivalent to sbrk()
Then have a more local memory allocator for subdividing the large chunk.
That's going to be a lot more efficient that relying on the XFree routines
to
Philip Brown wrote:
On Wed, Mar 26, 2003 at 09:14:37AM -0800, Ian Romanick wrote:
Philip Brown wrote:
Consider the GLX_dri_reserve_mem as equivalent to sbrk()
Then have a more local memory allocator for subdividing the large chunk.
That's going to be a lot more efficient that relying on the
The current memory management system looks like this:
Core X routines
|
V
Coarse grained, block oriented cache / paged memory system
|
V
Keith's mmHeap_t code
Actually that's not my code at all, if you're talking about the stuff in
Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
Any application which depends upon the root window
having particular GLX attributes is in error.
It's a screensaver. Using the root window would seem
to be a requirement here. So what you're really saying
is Who cares if you can't
On Wed, Mar 26, 2003 at 11:18:18AM -0800, Ian Romanick wrote:
Philip Brown wrote:
New client comes in. Requests new corse chunk o' VRAM from GLX
Oops. we've used up the 16 megs pre-allocated.
Used to be 11 megs free, but X server has been busy, and there is
now only 8 megs
Andreas Ehliar wrote:
On Wed, Mar 26, 2003 at 07:23:09PM +, Keith Whitwell wrote:
Actually that's not my code at all, if you're talking about the stuff in
common/mm.[ch]. I know it's ended up with my name on it, but that's bogus.
I can't remember who's it is, but it's lifted from Utah so
Philip Brown wrote:
So since it is orthogonal, you should have no objections to lowest-level
allocation of video memory being done by GLX calling xf86Allocate routines,
yes?
(ie: leave the X core code alone)
That is what's currently done. The goal was two fold. One (very minor,
IMO) goal was
--- Brian Paul [EMAIL PROTECTED] wrote:
there's no guarantee that any of them will
give you a root window with particular GLX
attributes. Sometimes you might get lucky.
[I've lost count of how many times this has come up
over the years, BTW.]
Hmm, makes me wonder if they were
Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
there's no guarantee that any of them will
give you a root window with particular GLX
attributes. Sometimes you might get lucky.
[I've lost count of how many times this has come up
over the years, BTW.]
Hmm, makes me wonder if they
On Wed, Mar 26, 2003 at 12:22:48PM -0800, Ian Romanick wrote:
... The memory management code that is in the 3D driver (for doing
the allocations and communicating with the DRM) really has to be there.
Moving it into the X server would really hurt performance. There's
really only four
Brian Paul wrote:
Well, from my point of view I've been dealing with this issue on and off
for over three years. I've explained it more than enough times. I'm
tired of hearing of it.
I've (finally) added this to the DRI FAQ.
-Brian
---
Suzy Deffeyes wrote:
Jens-
I agree with you, supporting HW accelerated indirect rending would be a good
thing.
Take a look at the DRI high level design doc:
http://dri.sourceforge.net/doc/design_high_level.html
In section 4.3, Indirect Rendering, there's a section on Multi-rendering
in a
On Mit, 2003-03-26 at 21:22, Ian Romanick wrote:
If the paged memory system is only used when DRI is enabled, does it
really matter where the code the X server calls is located? Could we
make the memory manager some sort of API-registered callback? It would
be one that only DRI (and
Michel Dänzer wrote:
On Mit, 2003-03-26 at 21:22, Ian Romanick wrote:
If the paged memory system is only used when DRI is enabled, does it
really matter where the code the X server calls is located? Could we
make the memory manager some sort of API-registered callback? It would
be one that
I just ran into a problem with this change in host.def when building the
trunk:
#define UsrLibDir /usr/X11R6/lib
This caused the build to be installed in /usr/X11R6 even though I had
ProjectRoot defined as /usr/X11R6-DRI. According to xc/config/cf/README,
UsrLibDir is the directory in which
On Don, 2003-03-27 at 01:33, Leif Delgass wrote:
I just ran into a problem with this change in host.def when building the
trunk:
#define UsrLibDir /usr/X11R6/lib
This caused the build to be installed in /usr/X11R6 even though I had
ProjectRoot defined as /usr/X11R6-DRI. According to
On Don, 2003-03-27 at 00:37, Keith Whitwell wrote:
Ian Romanick wrote:
Michel Dänzer wrote:
On Mit, 2003-03-26 at 21:22, Ian Romanick wrote:
If the paged memory system is only used when DRI is enabled, does it
really matter where the code the X server calls is located? Could we
On Don, 2003-03-27 at 04:09, Leif Delgass wrote:
On 27 Mar 2003, Michel Dänzer wrote:
On Don, 2003-03-27 at 01:33, Leif Delgass wrote:
I just ran into a problem with this change in host.def when building the
trunk:
#define UsrLibDir /usr/X11R6/lib
This caused the build to
As Seen on NBC, CBS,
CNN and even Oprah!
The Health Discovery that Actually
Reverses Aging while Burning Fat,
without Dieting or Exercise!
This Proven Discovery has even been reported
on by the New England Journal of Medicine.
Forget Aging and Dieting Forever!
And it's Guaranteed!
Needed following patch to get GLcore to load
in current trunk.
The vsnprintf.c code looked dubious (mprotect,sigsetjump,...)
dropped it from Imakefile.inc, works fine without it.
--
marko
Index: lib/GL/mesa/src/Imakefile.inc
===
On Wed, Mar 26, 2003 at 09:20:22PM +, Alan Hourihane wrote:
Thanks Marko,
We're still testing after the 4.3.0 merge, so things are still unsettled
right now. But thanks for the patch.
I saw the merge settling down, thought to give it a go.
I can report now Radeon 7000 working with
Thanks Marko,
We're still testing after the 4.3.0 merge, so things are still unsettled
right now. But thanks for the patch.
Alan.
On Wed, Mar 26, 2003 at 10:32:17PM +0200, Marko Kreen wrote:
Needed following patch to get GLcore to load
in current trunk.
The vsnprintf.c code looked dubious
Marcelo E. Magallon wrote:
On Tue, Mar 25, 2003 at 12:17:44PM -0800, Gareth Hughes wrote:
Umm, can you elaborate here? We (NVIDIA) don't support or expose
SGIS_fragment_specular_color. It's not even in the extension
registry...
[snip]
OpenGL extensions:
GL_EXT_abgr,
42 matches
Mail list logo
