On Mon, Oct 27, 2003 at 06:13:32PM -0800, Linus Torvalds wrote:
..
So the thing should really just have
- discovery and attach/detach
- interrupt event notification (and it can't just be an interrupt
happened - the interrupt driver actually has to know enough to ACK the
interrupt,
On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote:
Another possible solution to the boot time problem would be to write a
disposable device driver. The disposable driver would set the mode/EDID and run
the console until user mode started; then self destruct.
that doesnt sound very
I saw a few references to dri-solo on the mesa list, but didnt get to
read much on what it actually is.
What is it supposed to be?
I grepped through some of the recent dri-devel IRC logs, but didnt see
anything there either.
---
This SF.net
On Thu, Aug 14, 2003 at 07:47:11AM -0700, Larry McVoy wrote:
...
Indeed I have. And there is a reason that we have a policy at BitMover
where formatting changes are prohibited and we make people redo their
changesets until they get them right.
In other words, you are welcome to write a
On Mon, Aug 11, 2003 at 10:59:41AM -0700, Larry McVoy wrote:
...
It is inconsistent, on purpose. It's essentially like perl's
return unless pointer;
which is a oneliner, almost like an assert().
perl is EEevil
Maybe this will help: I insist on braces on anything with
On Tue, Jul 29, 2003 at 09:44:48PM +0200, Michel Dänzer wrote:
The DDX driver needs to know to decide whether to enable the DRI with
PCI GART or disable it, but the kernel might be in a better position to
find out (though some XFree86 hackers might disagree :)...
well, seeing as how using AGP
On Tue, Jun 24, 2003 at 10:01:47PM +1000, Damien Miller wrote:
Felix Kühling wrote:
Hi,
I have some questions about OS specific ways to find out the name of a
running programme outside function main.
extern chat *__progname;
works on OpenBSD, NetBSD and Linux.
it definately does
On Thu, May 29, 2003 at 10:52:15PM -0700, Linus Torvalds wrote:
On Thu, 29 May 2003, Ian Romanick wrote:
You're right. We do _really_ want to use futex'es. However, I don't
think they're available on *BSD or Solaris.
...
And once you have a nice wrapper and they look like
On Tue, May 27, 2003 at 09:38:31PM -0700, Russ Dill wrote:
I was being sarcastic, his message was encoded with koi8-r, which, along
with being html, is one of the indescriminate reasons people block email
(and get a good number of false positives)
however, foreign language encoding is separate
On Fri, Apr 04, 2003 at 08:43:31AM -0700, Jens Owen wrote:
Possible
Future: Mesa Tree -+-- XFree86 Tree
- API Focus|- X/3D Integration
- 3D HW Focus |- Complete Window System Focus
|
+-- Alternate X Tree
On Fri, Apr 04, 2003 at 10:09:00PM +0100, Keith Whitwell wrote:
Philip Brown wrote:
Are you perhaps envisioning pushing Mesa to evolve into something
like the nvidia UDA API? Where there is suddenly a single, unified
cross-hardware/OS platform for all 3d-accel hardware access to program
On Fri, Apr 04, 2003 at 10:34:05PM +0100, Keith Whitwell wrote:
[Philip Brown writes]
So to truely create something akin to nvidia's UDA libs/interface, would
involve porting support for 3d hardware currently handled by DRI, over to
Mesa, and making mesa capable of using it directly
Sorry about the lag of this, but I never like to give out false
information. So this is a correction to some things I said about utah-glx
in the weekly dri-devel irc conference two weeks ago:
utah-glx can handle multiple GLX contexts just fine. There is no extra
code needed to be written for
On Sun, Mar 30, 2003 at 02:27:46PM +0100, Ian Molton wrote:
Theres *TONS* of other hardware [than video cards] that has open source
drivers that *totally* rock.
and the other hardware is a lot simpler to interface to.
Kinda like the difference between writing a image display program, and
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
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
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
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
On Tue, Mar 25, 2003 at 09:48:21PM +, Keith Whitwell wrote:
Utah did have some stuff going for it. It was designed as a server-side-only
accelerated indirect renderer. My innovation was to figure out that the
client could pretty easily play a few linker tricks load that server
On Tue, Mar 25, 2003 at 12:37:17PM -0800, Ian Romanick wrote:
This could also pave the way for the X server to use the new memory
manager that is being developed. We could make some sort of a conduit
for the X server to call into the DRI driver to allocate graphics / AGP
memory. There
On Wed, Mar 26, 2003 at 12:37:08AM +, Alan Cox wrote:
On Tue, 2003-03-25 at 23:15, Philip Brown wrote:
There are already AGP (and memory alloc) related calls in the X server
framework; xf86BindGARTMemory(), xf86EnableAGP(), etc.
The core X server should not be making calls
On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote:
Philip Brown wrote:
The core X server should not be making calls into extension modules.
Extension modules should be making calls to xfree-exported functions.
If there arent sufficient xfree-exported functions, extend or add new
On Fri, Mar 21, 2003 at 09:45:40PM +0100, Michel Dänzer wrote:
Jose Fonseca writes
Also, what's the general mailing list one can subscribe to receive
notifications everytime a bug is open?
Currently [EMAIL PROTECTED] gets them all.
[EMAIL PROTECTED] gets notification when a bug is filed
On Fri, Mar 21, 2003 at 10:28:03PM +0100, Michel Dänzer wrote:
On Fre, 2003-03-21 at 22:24, Philip Brown wrote:
On Fri, Mar 21, 2003 at 09:45:40PM +0100, Michel Dänzer wrote:
Jose Fonseca writes
Also, what's the general mailing list one can subscribe to receive
notifications
On Thu, Mar 20, 2003 at 08:14:33AM +, Keith Whitwell wrote:
Or, someone could just leave it as is, disable it and forget
about it because sourceforge's bug tracking system sucks. [1]
I don't think we ever found out how to disable it. Just another aspect of its
suckage - you can't
On Thu, Mar 20, 2003 at 02:49:37PM +, Alan Cox wrote:
...
I guess they've been busy writing 3D drivers instead. If you know the
SF system well then this kind of info could be a real help
I dont know it well. I just poked around with it at admin-level for 10
minutes.
It would be a good
On Thu, Mar 20, 2003 at 10:34:11AM +, José Fonseca wrote:
On Wed, Mar 19, 2003 at 03:56:04PM -0800, Philip Brown wrote:
I'd rather hear first what it is supposed to mean in the current
implementations. The current docs say locked in kernel memory.
As written, that statement does
On Thu, Mar 20, 2003 at 04:08:06PM +, Keith Whitwell wrote:
From my selfish point of view, an XFree fork will put the DRI tree in a bit
of a difficult position - especially if the new fork gets significant distro
support and we have to somehow track both trees or go through yet another
On Wed, Mar 19, 2003 at 11:46:13PM +, José Fonseca wrote:
On Thu, Mar 13, 2003 at 11:47:13PM -0800, Philip Brown wrote:
The docs at
http://dri.sourceforge.net/doc/drm_low_level.html
say about drmAddMap(), for type DRM_SHM,
A shared memory area of the requested size
On Wed, Mar 19, 2003 at 09:31:41PM -0500, Mike A. Harris wrote:
On Wed, 19 Mar 2003, Philip Brown wrote:
Even if the decision stands to no longer field new bugs there, it would
still be nice if someone cleaned out the bugs there that are no longer
relevant.
Feel free.
that requires both
On Wed, Mar 19, 2003 at 09:26:21PM -0500, Mike A. Harris wrote:
...
Bugzilla requires a valid authenticated login. Not possible to
do that with email-bugzilla at least currently.
btw: I heard that some of the previously hashed out opposition to using
the sourceforge bugtracker, was because
On Tue, Mar 18, 2003 at 05:46:55PM +0100, otherside wrote:
is there a way to do that ?
just open a screen (monitor) and then write to it.
i try to write a little library which opens the screen so you can draw
some polygons to it.
will DRI help me to do it ?
Without a framebuffer, you are
The docs at
http://dri.sourceforge.net/doc/drm_low_level.html
say about drmAddMap(), for type DRM_SHM,
A shared memory area of the requested size will be created and locked in
kernel memory.
Is that supposed to be the same thing as locked in physical memory?
Because without specifying more
On Wed, Mar 12, 2003 at 08:39:31AM +, Keith Whitwell wrote:
Philip Brown wrote:
http://dri.sourceforge.net/doc/drm_low_level.html
should be updated with a functional description of
drmScatterGatherAlloc()
Patches welcome... :-)
love to.. if I understood it... which would
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()
Here's a patch to fix that, and R128PreInitDRI()
I had to make the patch by hand this time, since cvs seems down or
something.
---
On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote:
On Mit, 2003-03-12 at 19:15, Philip Brown wrote:
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()
Here's a patch to fix
On Wed, Mar 12, 2003 at 06:26:44PM -0500, Mike A. Harris wrote:
[]
IMHO, the names of functions and the file they are located in
should be based on the functionality that they are providing, and
should be grouped based on similar functionality and not based on
similarities in portions
On Wed, Mar 12, 2003 at 11:56:42PM +, Keith Whitwell wrote:
Well, I didn't have much to do with this code when it was written, but I'm
happy for it to stay where it is and as it is named for now.
If someone wanted to take on a bigger task of comprehensively spring-cleaning
the radeon
http://dri.sourceforge.net/doc/drm_low_level.html
should be updated with a functional description of
drmScatterGatherAlloc()
[and probably a few other drmXXXYYY() routines that have appeared
since 1999 ;-) ]
---
This SF.net email is
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #3: Readability by the active contributors. I'm not the only
old fuddy duddy in this group of developers. How much readability
time do you figure the young C++ whipper snappers will save by
On Wed, Mar 05, 2003 at 10:04:40AM -0800, Ian Romanick wrote:
Philip Brown wrote:
Are you saying that C++ somehow allows for more code sharing between
drivers than straight ANSI C?
It's not so much that it allows it as it makes it less painful. Look at
the texmem-0-0-1 branch. In lib
On Wed, Mar 05, 2003 at 01:08:52PM -0800, Ian Romanick wrote:
Philip Brown wrote:
Also, rather than containing the struct, you could do what is done already
in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
server code), and just extend the struct, rather than
On Wed, Mar 05, 2003 at 02:36:21PM -0800, Ian Romanick wrote:
I suppose that it is doable, but it just seems wrong. Doesn't this just
boil down to inheritance by conincidence? Expecting each driver to
duplicate the same data structures and add their unique data onto the
end, without any
As promised from the irc session... here's details on the little
32/64-bit issue I ran into.
Its not quite a direct 32/64 bit thing in the drm itself exactly, but
ambiguity can be a problem...
drm_map_t.offset is unsigned long.
unsigned long is semi-unspecified, but is reasonably assumed to
On Tue, Mar 04, 2003 at 11:59:50AM -0600, Andy Isaacson wrote:
On Tue, Mar 04, 2003 at 09:41:54AM -0800, Philip Brown wrote:
On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote:
On all 64bit bit platforms I have met unsigned long is a 64bit quantity.
In fact I can't think of a single
On Tue, Mar 04, 2003 at 11:02:10PM +, Alan Cox wrote:
On Tue, 2003-03-04 at 18:12, Philip Brown wrote:
All numeric fields passed through the ioctls, should have fixed,
identifiable sizes.
I guess you do need a typedef then so you can support solaris without
trashing the other 99.999
On Tue, Mar 04, 2003 at 09:18:40PM +0100, Benjamin Herrenschmidt wrote:
The purpose of this barrier isn not to ensure sequential access on
either the MMIO mapping (card registers) nor the actual ring buffer
memory mapping (could be IOs, or just real memory with PCI GART).
It's here to
On Mon, Mar 03, 2003 at 02:48:32PM +0100, Michel Dänzer wrote:
...
Besides which, DRM(ioremap) seems to do the *actual* mapping to kernel
space which still leaves the question of, what does
DRM_READMEMORYBARRIER() do?
As the name says, it issues a memory barrier. :)
I beg to
On Mon, Mar 03, 2003 at 02:58:01PM +, José Fonseca wrote:
...
An existing DRI driver has much more relevant information for a
developer than the hardware specs.
except for the fact that the dri cvs tree, seems to have some sort of
auto-applied strip for source code on commit.
As strip
On Mon, Mar 03, 2003 at 05:42:24PM -0800, Alan Young wrote:
On Mon, 3 Mar 2003 10:48:54 -0800 Philip Brown [EMAIL PROTECTED] wrote:
But anyway, sounds like I can NOP it out, I guess.
You may be able to NOP it if your platform does not require
it. I know the Alpha uses
On Sun, Mar 02, 2003 at 11:46:52AM +, Keith Whitwell wrote:
Philip Brown wrote:
For example, I'd like to submit a patch set to fix the issue where
there is _DRM_LOCK_IS_HELD() calls all over the place, but there really is
only one syntax for it:
_DRM_LOCK_IS_HELD(dev-lock.hw_lock
On Sun, Mar 02, 2003 at 08:20:52PM +, Keith Whitwell wrote:
Philip Brown wrote:
The one nasty that I do see coming up, and I dont see an easy patch for,
is DRM_MALLOC()/DRM_FREE()
Solaris requires knowing the size of the kernel mem you are freeing :-/
You could always add an arg
On Sun, Mar 02, 2003 at 10:33:15PM +, Martin Spott wrote:
Hello, did you know that remote display of OpenGL apps is partially
functional with DRI ? At least the client side works ! I'm currently running
FlightGear on a Linux PC against an SGI Octane functioning as X terminal.
Performance
Okay Keith,
here's a patch set for adding the extra size arg to DRM_FREE.
(attached)
It applies from the top of the 'os-support' directory.
I generated it with cvs diff -u. I believe GNU patch will ignore the
extra cvs type stuff, but if not, lemme know.
? bsd/Makefile
? bsd/drm/Makefile
?
Could someone explain what exactly DRM_READMEMORYBARRIER is supposed to do,
in the kernel driver level, please?
I was initially thinking that it did some kind of
enable bus memory mapping OS call.
However, it is used inconsistently.
mga_drv.h and radeon_drv.h use it , each at only one place in
This the appropriate place to send suggestions about the bsd drm driver?
There's an interesting amount of effort in the BSD side, to attempt to make
a more portable framework. But it's missing a few things here and there.
The first thing I've run into:
there is
#define DRM_OS_SPININIT(l,name)
On Sat, Mar 01, 2003 at 03:05:37PM -0500, Mike A. Harris wrote:
On Sat, 1 Mar 2003, Smitty wrote:
a V3 gets smacked around by a TNT2,
Not with open source drivers it doesn't.
got some specs on how the V3 performs, with glxgears?
google only pulled up results from someone who said their
If I were to spend the time to put together some portability patches
[for the kernel layer], would someone with cvs access volunteer interest to
review and put them in? I can potentially see a bunch of little ones
coming up, so rather than post every single one individually to the list, I
thought
On Sun, Mar 02, 2003 at 12:57:42AM -0500, Daniel Vogel wrote:
I guess you also had to take away mandatory software fallbacks and the
imaging subset. In reality though, every IHV I've talked to stated their
OpenGL drivers being far more complex to maintain.
The question is does that really
On Sun, Mar 02, 2003 at 02:26:04AM +, Alan Cox wrote:
People were saying that ten years ago. They were wrong
then, and I suspect they are wrong now. Too many people
think X11 == XFree86. XFree86 is an *implementation*
(arguably two with kdrive) of X11.
Even ignoring kdrive, I'd call it
On Fri, Feb 28, 2003 at 09:45:26PM +, José Fonseca wrote:
Even if DRI stops being the main source of 3D drivers for Linux/BSD, it
will remain to be the main source of _open_source_ 3D drivers. That,
alone, gives DRI a competitive advantage over any other solution. Just
in the same way
On Fri, Feb 28, 2003 at 05:06:15PM +0100, Michel Dänzer wrote:
I haven't look at this but if the DRM modules know
about setting up the hardware and changing resolutions
then there may be no need for framebuffer any more.
You could write a generic framebuffer driver that was
implemented
On Fri, Feb 28, 2003 at 05:15:58PM -0500, Daniel Vogel wrote:
So, are there technical reasons for NVIDIA not to use the DRI if ATI does?
yes.
NVIDIA already has their own cross-platform low level driver, with a
cross-platform 3d API. It's their UDI, Unified Driver Interface,
or something
On Fri, Feb 28, 2003 at 10:29:04PM -0800, Ian Romanick wrote:
Daniel Vogel wrote:
Does DRI have a future with neither NVIDIA nor ATI participating?
Are people actually talking to them about why they don't use it and
what has to be done to remedy this fact? Shouldn't this be a top priority?
On Thu, Feb 27, 2003 at 06:41:50PM -0800, Jon Smirl wrote:
If 3D isn't important to a desktop, then why are my
windows stacked on top of each other? Why do my
buttons depress and my windows look like they have
raised borders? Edit boxes have shadows and menus look
like they raise when the
I'm wading through DRM context switches at the kernel level now.
I've gotten lost a bit -- I'm missing a chunk o stuff at the
(*) point.
User wants a context switch to happen.
Calls ioctl(DRM_IOCTL_SWITCH_CTX)
Kernel goes into DRM(context_switch)
Sets an internal current context Variable
On Thu, Feb 20, 2003 at 09:12:04PM +, Philip Armstrong wrote:
Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on
Debian unstable and the latest demo release of UT2003 (v2206 -- which
is purported to not need S3TC extensions), I get the following
traceback reported by
Just a suggestion that comes to mind as I'm crawling through the
kernel-level code...
[the xfree 4.2.0 version]
but it looks to me like if userland passes in an incorrect context number
in a call to DRM_IOCTL_LOCK, it could cause a kernel panic, due to
no array bounds checking in
drm_drv.h,
Sorry, sorry.. missed seeing the bounds check, even though its right there.
It's late where I am, and it's been a long day.
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the lightweight
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
the lightweight lock will not
On Sun, Feb 16, 2003 at 10:52:34PM -0800, Ian Romanick wrote:
Philip Brown wrote:
So, why not do it by PCI vendor/devid ? That sort of information is visible
from the DRI level, I believe. I think its just another Xserver internal
call, isnt it?
So, what happens if I have four
On Mon, Feb 17, 2003 at 11:24:10AM -0800, Ian Romanick wrote:
So, what happens if I have four identical video cards in my system?
why would you want different configs for them?
There are probably as many different reasons as there are different
people that have such configurations. One
On Sun, Feb 16, 2003 at 02:00:01PM -0600, D. Hageman wrote:
On Sat, 15 Feb 2003, Philip Brown wrote:
I think this is a much cleaner overall design.
After all, you dont open /dev/fbX and tell it,
I want you to be associated with this video card now...
The stuff that I talk about above
On Sun, Feb 16, 2003 at 05:55:55PM -0600, D. Hageman wrote:
So, why not do it by PCI vendor/devid ? That sort of information is visible
from the DRI level, I believe. I think its just another Xserver internal
call, isnt it?
I thought about PCI vendors/devid ... problem with that is that
On Sat, Feb 15, 2003 at 01:24:26PM -0600, D. Hageman wrote:
... We played around with using Screens and driver
names, but in the end we were looking at keying off the device identifier.
At this time I still believe that is the best thing to use, but we have
no way at this time of grabbing
Could someone please explain the difference between
DRM_IOCTL_ADD_CTX
vs
DRM_IOCTL_NEW_CTX
Then again, maybe DRM_IOCTL_NEW_CTX is more like DRM_IOCTL_SWITCH_CTX,
reguardless of whether the name itself sounds more like ADD_CTX?
---
This
On Fri, Feb 14, 2003 at 03:23:07PM -0700, John Bartoszewski wrote:
On Fri, Feb 14, 2003 at 10:14:21PM +0100, Michel D?nzer wrote:
Also keep in mind that access to the DRI can be controlled via ownership
and permissions of the /dev/dri/cardX devices.
On a private machine this is method is
On Sat, Feb 15, 2003 at 01:51:57AM +, Alan Cox wrote:
On Fri, 2003-02-14 at 23:56, Philip Brown wrote:
how is only user joebrown can read and write /dev/dri/card0 any less
effective when there are multiple users on the box ??
As well as the unix permissions DRI is also playing games
I would like to request a fundamental change, to a minor part of the DRM
API.
I believe that the current semantics of
ioctl(DRM_IOCTL_SET_UNIQUE) and ioctl(DRM_IOCTL_GET_UNIQUE), violate POSIX/SUS
understanding of the ioctl command.
To quote from the single unix specification version 2 (1997)
On Tue, Jan 28, 2003 at 03:51:26PM -0500, Jamie Guinan wrote:
If the XML can be kept relativly simple to read and edit then fine but
the end user should never have to use a config tool if they don't want
to. So please keep it as simple as possle. In my opinion the
readability of the
On Tue, Jan 28, 2003 at 09:56:09PM +, Sergey V. Oudaltsov wrote:
Hi
Just one little XFree-related pro-XML story. Not from DRI, from XKB
life. You know, XKB configuration is generally held in
/usr/X11R6/lib/xkb directory and several subdirectories. All this would
be fine if the format of
On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
If anyone has serious objections to XML, please let us know (mail to
dri-devel will suffice ;-).
I object. Using xml inevitably leads to files that are completely
human-unreadable, except perhaps to the original developers.
Please
On Mon, Jan 27, 2003 at 06:04:19PM -0600, D. Hageman wrote:
I think you misunderstand. We aren't replacing the XF86Config file here.
This is for DRI specific driver settings with capabilities extending to
having special options for individual programs if need be.
Now if I am mistaken
On Tue, Jan 28, 2003 at 07:22:33AM +0100, Sven Luther wrote:
Another disadvantage is that parsing is so damn slow.
Yeah, tell me about it.
The place where I work had to buy some auxiliary processing boxes to
augment the webservers. Black box appliance like things.
SSL processing engines?
On Mon, Jan 27, 2003 at 10:37:06PM -0600, D. Hageman wrote:
On Mon, 27 Jan 2003, Philip Brown wrote:
If you want to get experience/resume padding doing XML coding, please do it
elsewhere.
Please don't make this a personal attack. Public forums are not an
appropriate place
On Tue, Jan 28, 2003 at 01:22:55AM -0600, D. Hageman wrote:
...
2) The XF86Config file format does what it does very well. It isn't
necessarily what we are looking for. It also isn't exactly a library that
one can just use. It is a very custom built parser for a very specific
purpose.
Would someone possibly do me the favour of either pointing me
to a [very] small program that tests basic drm
(Allocate DMA mem), (Read/Write DMA mem), (Free DMA mem)
functionality, or, if you are feeling particularly generous,writing one?
I'm not talking about excercising any specific video card
Attached is a patch for host.def, so that things will compile on
solaris at a basic level.
[course, nothing will WORK yet. but, one thing at a time]
Note that I originally posted this to the Bugs database on sourceforge,
but got an email that I shouldnt do that. If folks shouldnt do that, then
On Wed, Dec 18, 2002 at 12:17:29AM +, Alan Hourihane wrote:
And which host.def is this a patch against ? It does not match the trunk's
versions at all. For a start there is no definition of LinuxDistribution
in the trunks host.def file.
You shouldn't need OS level patches like this at
On Wed, Dec 18, 2002 at 12:57:45AM +, Alan Hourihane wrote:
HasGlide3 is set to NO by default and only enabled on Linux with an i386
or Alpha architecture.
Good to know that it is fixed in later versions. I was using Solaris i386,
so I was probably running afoul of old bad assumptions
On Fri, Dec 13, 2002 at 10:18:44AM +, Keith Whitwell wrote:
...
It's clear that both the drm and the 3d clientside drivers have a life outside
XFree86, but what isn't clear is how to express this in a reasonable
development environment or set of CVS trees.
Well, lets work on making
On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
...
It takes two to tango so its not just what I need its also what do they
need.
What I would like to see would be:
A single definitive source for the DRM code, one where contributions go
back from Linux, from *BSD, from core
I've been doing a little grepping here and there.
Correct me if I'm wrong, but in dri_dma_t, there are fields
send_count, and related send_XXX values;
these fields never seem to be used from the user level. They seem to
only be used internally to the kernel driver.
In which case, sounds like
On Mon, Nov 18, 2002 at 09:46:35PM -0500, David Dawes wrote:
...
If the goal is to make the DRI CVS as small as possible, why not go all
the way and turn it into an environment for building only the DRI-related
modules? That would change the nature of XFree86 merges quite a bit,
but that
On Wed, Nov 20, 2002 at 04:11:10PM -0700, Brian Paul wrote:
Philip Brown wrote:
That definately sounds like the Right Thing To Do.
Easier said than done.
I'm willing to bet that there's around 100 header files in the XFree86
tree that get pulled into the compilation of the various DRI
On Fri, Oct 25, 2002 at 10:34:35AM -0700, Ian Romanick wrote:
Time step 1:
- Buffer 0 is being displayed (front buffer / display buffer).
- Buffer 1 is the render buffer (back buffer).
...
Time step 3:
- Finish rendering to buffer 2, and queue it to be displayed on the next
frame (front
On Wed, Oct 23, 2002 at 01:01:39AM +0100, Alan Cox wrote:
...
Prefetching tends to be a win. What to prefetch is a harder question
normally solved by benchmarking. When the card does DMA access to a
buffer it will suck it from the processor L2 caches.
Pleaes define suck in this scenario.
If I'm reading the drm source right, there seems to be either
32,000 or 64,000 contexts provided for, with the ctxbitmap routines.
Isnt that overkill for typical use? Wont the average user tend to have
MAYBE 5 or 10 active contexts at a time, and no more than that?
I note that the apparent sole purpose for drm_write_string() is to
record context switches in a buffer, which can be read by processes
doing userland read() calls on the drm dev.
Is this for debug purposes only?
---
This sf.net email is
On Mon, Apr 15, 2002 at 12:35:41PM +0100, Jose Fonseca wrote:
I know that main reason for resuming the development of Utah-GLX was the
difficulties involved in porting the DRM to others OS, such as Solaris.
But why not reuse the DRI's Mesa and DXX drivers code and port and/or
remake a
1 - 100 of 124 matches
Mail list logo
