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 Ope
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 anyt
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.
>
> Probabl
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 buff
>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 indepen
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; y
Hi,
[...]
> > > In fact a perhaps better alternative would be document only the headers
> > > files instead of the implementation so that the code remains lean. (The
> > > downside would be bigger include fields and more C preprocessing time
> > > but the includes files are just used inside XFre
On Fri, Jan 25, 2002 at 12:16:06PM -0800, Allen Akin wrote:
> 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
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 al
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/rea
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
x
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 d
> 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 i
> > > > 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
> > > Monday. Work is being done to get Radeon 8500 ca
When I start X on a kernel where agpgart is included but no gart
device is found, X oopses on a null pointer dereference in radeon_ioremap.
The attached patch avoids the oops, but should be reviewed by
someone more knowledgeable about DRM than I.
--
Bjorn Helgaas - [EMAIL PROTECTED]
Linux Systems
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
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
>
to whom it may concern,
Please remove my name from this mailing list.
Thanx
Don Bailor
[EMAIL PROTECTED]
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
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 invo
Hello,
(recently i had some mail server problems and got kicked from the list,
but now i am back and watching the list again for whaever it needs.)
Maybe XAA is more X11 related, but i suppose that most of you
had some sort of contact with that layer in their coding projects.
I am aware and fam
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
"Sottek, Matthew J" wrote:
>
> I posted a RFC about a new type of "Shared" agp memory a while back
> but didn't get any input. I thought I would try again since there has
> been better communication as of late, and the idea has progressed
> somewhat.
>
> The problem:
> The agpgart usage model is
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 simple
> paragraphs
23 matches
Mail list logo
