José Fonseca wrote:
I've just updated the FAQ. Besides of including the new section
about binary compatibility from Jens Owen I also added a new top
section focusing on the implementation details, including new
material covering topics such as texture management, Mesa's graphics
Every time I refer to Utah-GLX code I can't avoid to think about the
enormous amount of duplication that would be to maintain a completely
different set of OpenGL drivers. Regardless of the OS the code in libGL
(meaning the Mesa driver) should be about 99% the same.
I know that main reason for
On Mon, 2002-04-15 at 11:33, Nicolas Aspert wrote:
...
Hello
I just noticed that the link in section 5.1.3 to the ATI AGP faq points
to a 'page not found' :-( Maybe it have moved but maybe it has been
simply removed.
It seems that ATI has redesigned its developer relation contents. I'll
José Fonseca wrote:
On 2002.04.13 04:36 Leif Delgass wrote:
On Thu, 11 Apr 2002, José Fonseca wrote:
Do we know for sure that pci gart is supported on mach64? The rage 128
and radeon drivers both write to PCI GART registers, but I don't see
anything analogous in the Rage PRO docs.
On Mon, 2002-04-15 at 14:19, Tony Rogvall wrote:
José Fonseca wrote:
On 2002.04.13 04:36 Leif Delgass wrote:
On Thu, 11 Apr 2002, José Fonseca wrote:
Do we know for sure that pci gart is supported on mach64? The rage 128
and radeon drivers both write to PCI GART registers, but I
Martin Spott wrote:
If you can ssh in, can you run the program from gdb from a ssh session?
Just to prevent you from thinking I overlooked this posting
I did a few tries with gdb yesterday but I didn't see the expected result.
This is to say, 'gdb' was pretty quiet at all, so I
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
On Mon, 2002-04-15 at 17:46, Philip Brown wrote:
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
I have been looking into the DRM's DMA/CCE/CP initialization subroutines
(those named *_do_init{dma,cce,cp} ) of the current DRI drivers, and I
still don't know how they protect themselves from making faults due to
bad initialization parameters. Since I this is a little complicated to
put over
On Mon, 2002-04-15 at 00:15, Allen H. Ibara wrote:
Hmm. Can you try without AGP? You'll have to rebuild the DRM kernel
module and the 2D driver with the #define PCIGART_ENABLED active for
that to work, and apparently there are other instabilities without AGP
on i386, so it might be hard
When I found what I believe to be a bug in gamma DRM which could lead to a
kernel oops on PCI cards.
The line is gamma_dma.c:669:
DRM_IOREMAPFREE( dev_priv-buffers );
but dev_priv-buffers has a non-NULL value only if it's not a PCI card, as
seen in gamma_dma.c:625:
Thanks for finding that. You can apply the patch.
Although the cleanup_dma function isn't used at all in the gamma
driver yet (it should be - I know), but the AGP code hasn't been
tested a whole lot either.
Alan.
On Sun, Apr 14, 2002 at 11:00:02 +0100, Jos Fonseca wrote:
When I found what I
I reported a problem to the gatos list a long while back that
I think may be related. (I thought it was strictly a gatos
thing, but have no idea, so I'll share it now).
I'm running X from cvs (old, but post 4.2.0) on my radeon 64mb.
Once I've run _any_ gl app, if I attempt to run
Too tired after riding, must sleep... If I'm still up I'll look in briefly...
Keith
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Mon, 2002-04-15 at 07:14, Nicholas Leippe wrote:
We have massive reports of VT switching hangs in XFree86 4.2.0
with almost all Radeon hardware, but with other hardware as well.
This problem has occured aparently since the prereleases 4.1.99.*
and up through to the final release of
The chat is on now. Looks like my earlier message hasn't gone through
yet. Trying again...
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
#dri-devel on irc.openprojects.net
4:00pm EST (2100 UTC)
-Brian
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On 2002.04.15 23:32 Felix Kühling wrote:
I just cvs updated my mach64-0-0-3-branch. make ran without problems
without problems. But make install gave me the following errors:
...
Then I also tried a clean make World; make install, with the same
result. I checked the logfile of make
Those affected by the lockups please test this patch against the DRI
trunk. It puts the DRI block in RADEONEnterVT() back first, where it was
in XFree86 4.1, which I understand didn't exhibit this problem (right?).
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
Sorry, I forgot to redirect standard error to my world.log :(. In fact
the build of mach64_screen.o failed here, too with the same error
messages.
These kind of problems happen when there some deep changes in headers
(such as the branch as suffered lately) and you're building on a
On 16 Apr 2002, Michel [ISO-8859-1] Dänzer wrote:
Those affected by the lockups please test this patch against the DRI
trunk. It puts the DRI block in RADEONEnterVT() back first, where it was
in XFree86 4.1, which I understand didn't exhibit this problem (right?).
--
Earthling Michel
Jose Fonseca wrote:
I still don't understand how it's not worth to work on this but have
separate equivalent code is. Well, it was just my two cents...
Jose,
I think you're asking the right questions. Personally, if I were
supporting an entire OS, I would prefer to maintain only a varient
Jose,
Was your concern addressed in today's chat?
Jose Fonseca wrote:
I have been looking into the DRM's DMA/CCE/CP initialization subroutines
(those named *_do_init{dma,cce,cp} ) of the current DRI drivers, and I
still don't know how they protect themselves from making faults due to
bad
Philip Brown wrote:
On Mon, Apr 15, 2002 at 09:19:35PM -0600, Jens Owen wrote:
However, I have to point out--that whomever is doing
the work get's their way; and since I don't have the bandwidth to
support the solaris DRM drivers--that's all I'm going to say, except:
If the current
[Setting Cc to just the dri-devel list; this doesnt seem appropriate
to the utah-glx list.
(particularly since I'm the only solaris developer on it ;-)]
[Note also that I'm not subscribed to dri-devel, though]
On Mon, Apr 15, 2002 at 09:44:39PM -0600, Jens Owen wrote:
Philip Brown wrote:
25 matches
Mail list logo
