This E-Mail may be vary controversial and lame to no extent.
I.E. It's negitive.
[*] The write register/read register should be made to use
PCI register sets, instead of any hardcoded addresses.
So instead of write a byte to I/O address 0xc0f, you would make
a call to write a byte
Phil,
Thanks for your response. I think you bring up some good points related
to a UNIFIED DRIVER interface--so not to confuse our audience I've
renamed this thread.
Philip Brown wrote:
On Thu, Jan 24, 2002 at 08:07:18PM -0700, Jens Owen wrote:
I think the level of reorganization
Jose Fonseca wrote:
On Fri, 2002-01-25 at 03:11, Jens Owen wrote:
José Fonseca wrote:
Unless anyone has a better suggestion I think this is the way to go. What
do the elder developers think?
The one down side I see is the complexity (and clutter) created by the
TAGS. I like
On Fri, 2002-01-25 at 14:22, Jens Owen wrote:
Jose,
The example you give looks reasonable, but here is another example, for
drmAddMap, that I find much harder to read:
...
yep. This is too verbose. (Sorry I didn't notice that one.)
In fact a perhaps better alternative would be
The problem:
The agpgart usage model is not well suited for UMA architectures because
each gart user is expected to allocate memory and only bind it into
the gart while it is active. Therefore on systems where all graphics
memory is obtained from the gart a huge amount of system memory is
On Fri, Jan 25, 2002 at 09:41:17AM -0800, Ian Romanick wrote:
If not, what's the prognosis? Is it in the works and just
gonna take some time, or are there other issues such as
documentation availability?
There was some (brief) talk about this on the developer chat on
On Fri, Jan 25, 2002 at 02:53:18PM +0100, Alexander Stohr wrote:
1) The document XAA.HOWTO describes nicely the functionality
of the low-level hooks. Where can i find documentation on the
mid-level and GC-level hooks and flags?
I think the documentation you are looking for is available in
On Fri, Jan 25, 2002 at 07:02:47AM -0700, Jens Owen wrote:
...
For example, instead of a whole bunch of different odd hardware-specific
calls, limit the driver to the following classes of operations:
1. AGP (and make it SIMPLE!)
2. DMA (See above)
3. write register/read register
On Fri, Jan 25, 2002 at 11:42:51AM -0800, Philip Brown wrote:
|
| As a device driver writer, it feels intrinsically 'wrong' for user-space
| programs to say map the device registers into my address space, turn off
| all memory protection, and I'll take it from here.
Except for the turn off all
On Fri, Jan 25, 2002 at 01:17:43PM -0800, Philip Brown wrote:
| On Fri, Jan 25, 2002 at 12:16:06PM -0800, Allen Akin wrote:
|
| Except for the turn off all memory protection part, that's essentially
| the way most 3D drivers have to work. OpenGL *is* the hardware
| abstraction layer; you
This seems reasonable enough, but I'll have to think about it more
and learn a bit more about the AGP implementation to fully grok it.
On question I do have is what impact will this have (if any) on
chipsets that aren't UMA?
No impact whatsoever. I specifically didn't touch ANY device
Hi!
Sorry that I'm not sending a patch, but I don't know if my solution is
correct.
Problem description (both with dri from CVS dri and CVS gatos): on r128 when I
KDE is starting, display is corrupt and lots of:
Jan 26 04:38:38 ten kernel: [drm:r128_cce_indirect] *ERROR* process 15795 using
On Fri, Jan 25, 2002 at 02:40:42PM -0800, Allen Akin wrote:
On Fri, Jan 25, 2002 at 01:17:43PM -0800, Philip Brown wrote:
| Except that you already have a dual-layer driver/library model, so this
| isnt adding another layer. Just making the existing layers more
| formalized.
Probably I
Hi everyone,
I'm a C/C++ programmer who's been using Linux for quite a while now (3 or 4
years). I'm currently unemployed and bored off my a**. I'd like to start
working on fixing bugs and problems in the DRI stuff but I was wondering if
the sourceforge bug list is up to date. Is there
On Fri, Jan 25, 2002 at 09:41:52PM -0800, Philip Brown wrote:
|
| Probably I misunderstood your original comment. But just as a
| clarification, libGL doesn't provide an additional interface abstraction
| for OpenGL commands; it does some things for dispatch setup, and
| thereafter OpenGL
15 matches
Mail list logo
