On Mon, 2004-03-08 at 06:58, Jon Smirl wrote:
I'm trying to merge some of the functions from the radeon DRM and FB device
drivers into a single driver. I've been working on the code for a week trying to
get AGP working but I can't seem to figure out what is wrong. In
drm/radeon_cp.c,
Hi Jon,
The problem could be in Radeon memory controller mapping, perhaps
XFree86 from DRI CVS changes it.
You see there is a memory controller on Radeon chip itself which merges
several different address spaces (video ram, AGP and PCI DMA) into one.
The default (when it boots) is such that
Leif Delgass [EMAIL PROTECTED] writes:
I forgot to bring in the drm_linux_list.h for bsd that was added on
the mach64-0-0-6-branch. I just added it and it is included from drmP.h.
With any luck that should fix the compile errors in the kernel module.
ok, thank you again, that does fix the
Alex Deucher wrote:
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
Was the DRI tree ever synced with the XFree86 tree prior to 4.4.0? I
downloaded and installed 4.4.0 on a NetBSD system, thinking that
MergedFB
would just work but, unfortunately, it doesn't.
Nope, no mergedfb in 4.4. Mergedfb is
Roberto Pariset wrote:
hello,
last (few days ago) xlibmesa-gl1-dri-trunk was really great on my box
(SiS + sid), but the one from yesterday makes dri program crash. here is an
output from glxgears:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1076844768 (LWP 3563)]
On 8 Mar 2004 [EMAIL PROTECTED] wrote:
Leif Delgass [EMAIL PROTECTED] writes:
I forgot to bring in the drm_linux_list.h for bsd that was added on
the mach64-0-0-6-branch. I just added it and it is included from drmP.h.
With any luck that should fix the compile errors in the kernel
--- Sérgio Monteiro Basto [EMAIL PROTECTED] wrote:
On Thu, 2004-03-04 at 20:15, Alex Deucher wrote:
For those of you messing with XvMC support on savage, I just
checked in
a fix for the missing extension problem. I had forgotten to port
over
the setup code from S3's driver. I tested it
--- Ian Romanick [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
Was the DRI tree ever synced with the XFree86 tree prior to 4.4.0?
I
downloaded and installed 4.4.0 on a NetBSD system, thinking that
MergedFB
would just work but,
Robert F Merrill wrote:
Robert F Merrill wrote:
Bug in mesa's glLightfv() (src/mesa/main/light.c):
When you send a 4-float array to glLightfv with GL_POSITION, the
fourth float indicates whether the light is
directional or positional. 1 is positional, 0 is directional.
However, mesa checks for
On Mon, Mar 08, 2004 at 01:25:28AM +, Dave Airlie wrote:
all the mach64 really does is triangle and texturing, not much else.. so
it depends on what you run on it to decide if it goes faster.. tuxracer
certainly does :-)
Oh, and you can have any one you want of hardware fog and alpha;
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
4:00PM EST or 1:00PM PST, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous
Mike A. Harris wrote:
On Mon, 1 Mar 2004, Alan Cox wrote:
On Llu, 2004-03-01 at 16:28, Michel Dnzer wrote:
For my part, I'd certainly prefer staying clear of the silly new
license. In the long run, I'd vote for moving the DRI X server code to a
freedesktop.org X server tree and the libGL code
On Mon, 08 Mar 2004 09:28:48 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
[snip]
Is there a list somewhere of what's in the current DRI tree that isn't
in XFree86 4.4.0? I think that would help answer some of the questions
like this and help the folks working on the x.org tree figure out
AGP is at physical EC00
GPU sees AGP at 400, GPU AGP base is set to EC00
user and kernel virtual can both see the memory at EC00
I also tried adding pci_set_master() with no effect. The DRM driver in the
kernel does not set pci_set_master(). In RADEON_AGP_COMMAND AGP_ENABLE is
Around 19 o'clock on Mar 8, Keith Whitwell wrote:
I don't have any in-principle objections to this, though I'd like to get
more of a feel for the new X.org before committing to anything.
That seems sensible. I don't think there's any particular urgency here,
nothing related to DRI will
i reinstalled the latest deb in sid, using deb
http://people.debian.org/~daenzer/dri-trunk-sid/ ./ as a repository.
the message is the same. is it a snapshot? if not, where can i find
those, exactly? thanks
rob
[EMAIL PROTECTED]:~$ gdb glxgears
GNU gdb 6.0
Copyright 2003 Free Software Foundation,
Roberto Pariset wrote:
mmm so can i fix it somehow or just wait for a new deb? isnt SSE a cpu
flag? if so i /proc/cpuinfo says i have it (amd xp 1600+). thanks
rob
Il lun, 2004-03-08 alle 22:57, David Bronaugh ha scritto:
SNIP
I think this has been covered about a million times.. the SIGFPU
Leif Delgass [EMAIL PROTECTED] writes:
[snip]
but glxgears only gets about 115.3 frames:
# glxgears -display :1
[1] 6381
577 frames in 5.0 seconds = 115.400 FPS
576 frames in 5.0 seconds = 115.200 FPS
576 frames in 5.0 seconds = 115.200 FPS
577 frames in
I think I have located the problem. AGP_BASE is getting stomped somehow. Now I
just need to track down where and how.
My user space app is clearly setting it:
/* Initialize Radeon's AGP registers */
/* Ring buffer is at AGP offset 0 */
OUTREG(RADEON_AGP_BASE,
Roberto Pariset wrote:
mmm so can i fix it somehow or just wait for a new deb? isnt SSE a cpu
flag? if so i /proc/cpuinfo says i have it (amd xp 1600+). thanks
rob
Il lun, 2004-03-08 alle 22:57, David Bronaugh ha scritto:
SNIP
I think this has been covered about a million times.. the SIGFPU is
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=512
--- Additional Comments From [EMAIL PROTECTED] 2004-03-08 19:59 ---
As I suspected,
I'd like to discuss / revisit what it will take to implement
asynchronous swapping. By this I mean glXSwapBuffers returns
immediately even if the driver needs to wait several frames (due to the
swap interval or whatever) to actually do the swap.
I've thought of a couple ways to do this, but they
On Mon, Mar 08, 2004 at 08:28:55PM -0800, Ian Romanick wrote:
| ...
| - Implement the wait in the kernel. The driver calls a new swap ioctl
| that takes the 'target' frame as a parameter. The kernel mainains a
| queue of pending swaps that is checked each time a vblank interrupt is
| handled.
23 matches
Mail list logo
