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
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
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
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
