On Llu, 2003-07-07 at 06:41, Rusty Trivial Russell wrote:
[ CONFIG_DRM_SIS needs CONFIG_FB_SIS to compile, of course. --RR ]
(OK from maintainer Rik Faith [EMAIL PROTECTED])
From: Geoffrey Lee [EMAIL PROTECTED]
And the 2.4 config tools cant handle this because of the order problems.
Marcelo
On Gwe, 2003-06-27 at 17:07, Maximo wrote:
Hi,
I got the Savage-1_0_0-branch from CVS e tried to compile it and i got no
error but when I copied the drm modules do its place at /lib/modules/.
e tried to load the module into memory i got this unresolved symbol error:
On Gwe, 2003-06-27 at 18:05, Maximo wrote:
I've done some cleanup of the drm modules in the -ac tree, the ones they
included plain wont work
When your modifications will be available on Savage-1_0_0-branch?
I've no idea what people want to do about that. My cleaned up stuff wont work with
to test this out now, and
the kernel driver works on kernel 2.4.9, but I've not tried on anything
later.
It'll kind of work providing certain things dont happen and your box is
uniprocessor.
If Alan Cox has some patches for the kernel module, send 'em along and
I'll get them into this branch
On Maw, 2003-06-24 at 10:19, Alan Hourihane wrote:
I'm still looking at the large differences in the 2D driver code, so I
thought I'd ask if someone wanted to step up and fix the 3D driver which
will also need some fairly large changes to get it to compile.
Ditto the CLE266 via driver. So far
On Llu, 2003-06-23 at 10:41, Keith Whitwell wrote:
BTW, do we have a owner of such card among the subscribers which can do
some testing when the time comes?
I think Alan Cox. Alan Hourihane had one, but I think it died -- I find it
very hard to keep gamma details in my head for some
On Llu, 2003-06-23 at 13:01, Jos Fonseca wrote:
I see. Well it really doesn't trouble me to rewrite the gamma driver
since I'll be changing all other drivers. Also the work I'm doing will
move a big chunk of each driver into common code (all the buffer
management), so there will be little to
On Llu, 2003-06-23 at 13:03, Alan Hourihane wrote:
The Delta was never supported for 3D. What make of board is it Alan, that
your Delta is broken for 2D ? And can you send me the XFree86 log file.
Email me an address off list and I'll send you the delta card. Its just
gathering dust in a
On Llu, 2003-06-23 at 13:33, Alan Hourihane wrote:
No secrets/non disclosures. The VIA/S3G guys just want to get them into
XFree86 proper and the code appears to already have all the right X
Licenses attached.
Great. I can test the Savage MX/IX support with my IBM T20 laptop :)
If you
On Llu, 2003-06-23 at 14:43, Alex Deucher wrote:
Alan,
I don't suppose they released any code or docs for duoview support
for the old savage chips? I tried to add support for that a while
back, but never was able to get it to work.
I don't.
On Llu, 2003-06-23 at 15:20, Jos Fonseca wrote:
Another thing I noticed is that the Savage DRM is just a stub doesn't
touch the hardware - the DMA is fired directly by the userspace 3D
driver. I may be wrong but this can compromise the system security.
This is stuff that needs to be looked at
On Sul, 2003-06-22 at 14:59, Jos Fonseca wrote:
In file included from /usr/src/dripkg/drm/mach64_drv.c:41:
/usr/src/dripkg/drm/drm_dma.h: In function `mach64_irq_install':
/usr/src/dripkg/drm/drm_dma.h:247: warning: passing arg 2 of `request_irq' from
incompatible pointer type
Is
On Mer, 2003-04-09 at 15:19, PlasmaJohn wrote:
S3 sold off their video technology to Via. Notice that the chipsets that the
EPIA motherboards use integrate a AGP Savage.
VIA only own part of S3, and EPIA boards don't use Savage either.
EPIA uses the trident video
EPIA-M uses castle rock,
On Mon, 2003-03-31 at 22:25, Alan Hourihane wrote:
#ident $Id:$
But now that I've worked with CVS branches, I'm convinced that it and
$Header:$ are quite evil.
I always strip out the $Id$ tags from the Mesa sources when bringing them
in to DRI. Alan just missed that.
I
On Wed, 2003-03-26 at 01:15, Ian Romanick wrote:
From a security perspective, people may want to disable direct
rendering. There is a shared memory segment that an evil program
could muck with and cause DoS problems. I probably haven't thought
about it enough, but I can't see how would
http://www.realitydiluted.com/mirrors/reality.sgi.com/
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
On Wed, 2003-03-26 at 17:59, Chris Rankin wrote:
--- Brian Paul [EMAIL PROTECTED] wrote:
Any application which depends upon the root window
having particular GLX attributes is in error.
It's a screensaver. Using the root window would seem
to be a requirement here. So what you're really
On Tue, 2003-03-25 at 21:48, Keith Whitwell wrote:
The final point that I would like to make is that we're going to NEED to
load the DRI driver on the server-side at some point in order to support
accelerated server-side rendering. We could then implemented a
server-side software-only
On Tue, 2003-03-25 at 23:15, Philip Brown wrote:
There are already AGP (and memory alloc) related calls in the X server
framework; xf86BindGARTMemory(), xf86EnableAGP(), etc.
The core X server should not be making calls into extension modules.
Extension modules should be making calls to
On Fri, 2003-03-21 at 15:47, Jos Fonseca wrote:
On Mon, Feb 24, 2003 at 09:03:31PM +, Alan Cox wrote:
On Mon, 2003-02-24 at 19:35, Jos Fonseca wrote:
but reading the specs again they all mention either Via Apollo PLE133
(Trident CyberBlade/i1 core) or a Via Apollo CLE266 (no idea
On Thu, 2003-03-20 at 09:31, Philip Brown wrote:
On Thu, Mar 20, 2003 at 08:14:33AM +, Keith Whitwell wrote:
Or, someone could just leave it as is, disable it and forget
about it because sourceforge's bug tracking system sucks. [1]
I don't think we ever found out how to disable
On Mon, 2003-03-17 at 21:41, Martin Spott wrote:
Michel D?nzer [EMAIL PROTECTED] wrote:
BTW, are you actually using 4x transfer rate? If so, have you tried
lowering it?
I't like to note that the lockups I saw with FlightGear and Solace were
completely independent from the AGP transfer
On Thu, 2003-03-13 at 00:20, Philip Brown wrote:
On Wed, Mar 12, 2003 at 11:56:42PM +, Keith Whitwell wrote:
Well, I didn't have much to do with this code when it was written, but I'm
happy for it to stay where it is and as it is named for now.
If someone wanted to take on a bigger
On Thu, 2003-03-06 at 15:49, Suzy Deffeyes wrote:
I sure hope the new rules from the Bylaws Working Group make life easier for
someone. ;-).
Maybe it will be easier now MS have resigned, although that puts them in a nice
position to avoid declaring patent interests and destroy OpenGL by
In short, I don't see why everyone is so keen to accept C++ but only if it is
somehow hobbled from the onset? C++ is a tool. Tools work best when the
right one is chosen for the job, the tip is sharp, and the handle is not
splintered or cut off. If the problem does not map into something
On Tue, 2003-03-04 at 08:22, Philip Brown wrote:
unsigned long is semi-unspecified, but is reasonably assumed to be
a 32-bit quantity.
On all 64bit bit platforms I have met unsigned long is a 64bit quantity.
In fact I can't think of a single exception
mmap() takes an arg of type off_t.
off_t
On Tue, 2003-03-04 at 05:00, David Bronaugh wrote:
I searched Google.
Here's the result I got:
ftp://download.intel.com/support/graphics/intel740/29061902.pdf
Looks like a pretty full spec to me. Hopefully it is.
Doesn't document any of the drawing commands/setup/mode change. Hardly
On Tue, 2003-03-04 at 18:12, Philip Brown wrote:
All numeric fields passed through the ioctls, should have fixed,
identifiable sizes.
I guess you do need a typedef then so you can support solaris without
trashing the other 99.999% of the userbase. In the Linux world the
ioctl32 handlers munge
On Tue, 2003-03-04 at 22:15, Philip Brown wrote:
I believe DaveM's DRM for the sparc64 linux is quite happy with
mixed 32/64 user space.
Probably it has the same size for unsigned long in both 32 and 64 bit
modes.
I don't think so. I think the DRM ioctls get munged properly
It works is
On Mon, 2003-03-03 at 20:38, Mike A. Harris wrote:
On Mon, 3 Mar 2003, Ian Molton wrote:
You can get
back now to your dri-has-no-docs-and-developers/ihvs-are-elitists
speech for all I care.
No thanks. I'll just continue reverse engineering my e740.
e740, or i740? AFAIK, i740 has
On Sun, 2003-03-02 at 07:39, Philip Brown wrote:
There are still TWO SEPARATE APIs for doing 2d drivers.
There's the stock-standard
Xserver/hw/{standard-driver-here}
(eg: Xserver/hw/sun)
Thats the top level do it the hard way interface. Thats X11R6 vanilla
not Xfree86.
and then there's
On Sun, 2003-03-02 at 01:55, Jon Smirl wrote:
--- Alan Cox [EMAIL PROTECTED] wrote:
People were saying that ten years ago. They were
wrong then, and I suspect they are wrong now.
Looking out five years wouldn't OpenGL 2.0+ make a
better core graphics API for Linux than XLIB? Hardware
On Sun, 2003-03-02 at 19:15, Allen Akin wrote:
| Once you get rid of the legacy stuff in OpenGL, drivers are pretty much
| the same level of complexity for OpenGL as for D3D. Which is one reason
| why several groups are able to use OpenGL subsets for embedded apps.
|
| I'll take your
On Sun, 2003-03-02 at 21:57, Sven Luther wrote:
1. fbdev will be secure. Without access to the MMIO regions, crashing
the chipset is unlikely or at least difficult. Even malicious blit
commands (blits to/from system memory) will not work.
For some cases. The truth is a bit more horrible,
On Mon, 2003-03-03 at 00:01, Antonino Daplas wrote:
For some cases. The truth is a bit more horrible, and current fbdev has
the same problem here. Any early Athlon, and almost any PII/PIII derived
chip allows the user to bring the box down if they have access to
a mix of cached and
On Sat, 2003-03-01 at 18:19, Bachman Kharazmi wrote:
Hi,
I've upgraded my system today and since xf 4.2.x got installed X
hasn't been working. I get a error about radeon.o is version 1.1.1 and
1.5 is needed
How do I patch my kernel or are there any other ways to solve this
issue ?
On Sat, 2003-03-01 at 23:11, Linus Torvalds wrote:
Quite frankly, DRI is the project from hell when it comes to getting
into it, and I think that's largely because you have to have all the
pieces in place to get something working, and you have to understand a
wide range of different issues
On Sat, 2003-03-01 at 20:28, Philip Brown wrote:
got some specs on how the V3 performs, with glxgears?
google only pulled up results from someone who said their setup seemd to
not be configured properly.
(68 FPS)
On the voodoo gears is a fine way to measure your monitor refresh rate. The
On Sun, 2003-03-02 at 00:56, Jon Smirl wrote:
X has served us well for a long time but I just don't
think it is sufficient to be the standard video
platform for desktop Linux over the next ten years.
People were saying that ten years ago. They were wrong
then, and I suspect they are wrong now.
On Fri, 2003-02-28 at 08:25, Sven Luther wrote:
Also, before you speak about unifying the 2D and 3D drivers
you need to look at how a 3D desktop would work.
I would assume roughly like the Apple renders seem to work now, or how
the opengl accelerated canvas works in E. That bit is hardly rocket
On Fri, 2003-02-28 at 12:19, Sven Luther wrote:
So, No 2D windows on the face of rotating cubes ?
Once your 2D windows are textures the rest is very much free, including
scaling, rotation occlusion and alpha blending. You can use it to build
the base X interfaces then worry about exposing the
On Fri, 2003-02-28 at 00:04, Paul J.Y. Lahaie wrote:
There are areas where X11 doesn't fit in well. (Feel free to correct
me) but R300 and GFX level cards support 128bpp (32bpp floating point).
The X protocol has no way to display to this kind of device. Which
means that fpu color
temp;
-907,6 +908,9
queue_task(dev-tq, tq_immediate);
mark_bh(IMMEDIATE_BH);
+ } else {
+ printk(KERN_CRIT __FUNCTION__ : NULL pointer\n);
+ }
}
void i810_dma_immediate_bh(void *device)
--
Alan Cox [EMAIL PROTECTED
On Mon, 2003-02-24 at 17:24, Alan Cox wrote:
On Mon, 2003-02-24 at 13:43, Martin Spott wrote:
Absolutely the same effect as over here. Unfortunately it gets stuck on
startup with the B747, immediately after writing some message like
Reading electrical system model from [...],
With a 747
On Mon, 2003-02-24 at 16:33, Jos Fonseca wrote:
That would be great, Felix! It doesn't really matter when. The Savage4
is more a pet project than a real need for me, as my laptop [my main
working machine] has a Mach64 [and I don't plane to replace it in the
next couple years]. What drives me
On Mon, 2003-02-24 at 19:24, Ian Romanick wrote:
uint_fast32_tactual_flags; /** Memory property flags of the memory
* holding the buffer.
*/
uintptr_toffset; /** Offset of the buffer within the memory
On Mon, 2003-02-24 at 22:14, Jaakko Niemi wrote:
Just a data point, things seem stable with my 9100 with XFree86 4.3-pre
and drm from cvs head. Bots were whacking each other in one q3 mod for
18 hours..
What chipset. My problems are AGP 1x on AMD 75x series
On Sun, 2003-02-23 at 11:24, Dieter Ntzel wrote:
I have a meeting with the vice president of VIA scheduled on Jan 2nd or
3rd. Thats not public info and S3TC isnt the primary item but I will
mention it.
Sorry, second try. I had forgotten to CC DRI-Devel.
Alan,
what came out of this?
The cursor still moves therefore either
1. The cursor doesnt go via the FIFO
2. The FIFO is not full
..
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being called only once
verify_area performs any checks needed for it to be safe to use the _copy forms of
copy_*_user.
What that does varies. The normal Linux approach is
verify_area does access_ok which checks the address is a kernel view of a user space
address. _copy* functions use the MMU to fault any illegal
On Wed, 2003-02-19 at 01:48, José Fonseca wrote:
I think our case is one of the exceptions: we are copying from the user
and verifying the data at the same time (to avoid the user sending
malicious commands to the card's DMA engine which could potentialy
compromise the system integrity and
in reading it.
We'll keep the Subject line the same for your benefit.
Really, it doesnt seem to be your list. I'd love to see the contract
with sourceforge guaranteeing that.
--
Alan Cox [EMAIL PROTECTED]
---
This sf.net email is sponsored
On Fri, 2003-02-14 at 10:38, Pedro Vasconcelos wrote:
Hello,
I've sucessfully installed radeon DRI binary snapshot from dri.sourceforge.net on my
system. 3D acceleration works well, with the exception of an irritating problem:
sometimes the system locks with some GL applications if I move or
On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote:
That DRM is pretty old, is the 3D driver from the same date? Someone
said on an XFree86 list that the flightgear lockups went away for him
with XFree86 4.3.0rc1.
My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent
DRM
On Fri, 2003-02-14 at 14:52, Martin Spott wrote:
My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent
DRM module.
Where did you take the DRM sources from ? I usually take the source for the
DRM module from the same DRI CVS tree I use to build the whole DRI thing,
On Fri, 2003-02-14 at 23:56, Philip Brown wrote:
On Fri, Feb 14, 2003 at 03:23:07PM -0700, John Bartoszewski wrote:
On Fri, Feb 14, 2003 at 10:14:21PM +0100, Michel D?nzer wrote:
Also keep in mind that access to the DRI can be controlled via ownership
and permissions of the /dev/dri/cardX
On Tue, 2003-02-11 at 11:26, Alexander Stohr wrote:
9500 is a r300 based design and is nicely supported.
9100 is a r200 based design and is nicely supported.
(or at least it should be quite nicely supported -
just assumed because i dont have such a board to my hands.)
Do you know what the
On Wed, 2003-02-05 at 22:58, Adam K Kirchhoff wrote:
Hello all,
So there's this really great game from Garagegames called
MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher
or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the
ATI FireGL
On Mon, 2003-02-03 at 12:45, Stefan Lange wrote:
VIA/S3 has been contacted several times already, whether they'll allow
the integration of S3TC-support in the DRI. Unfortunately they never
answered. So it's not very likely that you'll S3TC in DRI in the near
future. Things might change some
On Mon, 2003-02-03 at 15:02, Keith Whitwell wrote:
-#define COMMIT_RING() do { \
- RADEON_WRITE( RADEON_CP_RB_WPTR, dev_priv-ring.tail ); \
+#define COMMIT_RING() do { \
+ /* read from PCI bus
On Tue, 2003-01-28 at 12:00, Sven Luther wrote:
Just my experience for when file-roller (part of gnome) upgrades its
configuration, it takes minutes on a Atlhon 1700+, but i admit, the
configuration file-roller manages are, if not big, at least there are
many of them.
Thats something else.
On Mon, 2003-01-13 at 15:42, Brian Paul wrote:
If direct rendering is not available, we use indirect rendering (send GL
drawing commands over the wire to the Xserver). The Xserver in turn executes
the GL commands.
So am I correct in thinking server side acceleration for old hardware that
is
On Sun, 2003-01-12 at 19:54, Erling A. Jacobsen wrote:
Perhaps the dri-devel list isn't the right place to be, because
what I have in mind is indeed not a DRI driver, rather a modification
of the version of Mesa which DRI uses if there's no hardware-accelerated
DRI-driver available. But still,
On Wed, 2003-01-08 at 10:09, Raffaele Candeliere wrote:
Hallo everybody!
I have installed a 3DFX Voodoo1 accel in my PC with a Cirrus Logic
5446 AGP card and i could manage to get it up and working under
Windows NT, but not under Linux (RedHat).
Does anybody know if is Voodoo1 supported under
On Fri, 2003-01-03 at 15:39, Ian Romanick wrote:
There's actually probably more general interest in the stereo support
than in the Direct3D support. It would take very little to modify the
Radeon, R200, Rage128, and G400 drivers to support switching between
left and right display buffers
On Thu, 2003-01-02 at 22:34, Jon Smirl wrote:
Would anyone happen to have code for warm booting a
secondary video card in kernel context from a device
driver? I'd also like to find a small stand-alone app
for doing this.
If not I can always start hacking on the Int10 code in
X.
Its very
On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
Alan,
What would you like to see be implemented to help get the job done. In
other words, what do you need from the DRI team?
It takes two to tango so its not just what I need its also what do they
need.
What I would like to see would be:
On Thu, 2002-12-12 at 12:40, Alan Hourihane wrote:
The ability to track changes to that with reasons so that we can keep a
stable DRM and also the 'DRM of the day' visible to the kernel people -
perhaps the devel kernel tree having an option for Development DRM
(XFree86 4.4) (Y/M/N).
On Thu, 2002-12-12 at 12:49, Keith Whitwell wrote:
A single definitive source for the DRM code, one where contributions go
back from Linux, from *BSD, from core XFree86 as well as from the DRI
project.
My feeling is that the dri cvs should be that place. What workable
alternatives
On Tue, 2002-12-10 at 12:45, Dieter Nützel wrote:
No disk stuttering but some latency here and there and some Mesa demos aren't
running smooth anymore.
The new DRI modules appear to be really bad from the bug reports I've
received so far. Thats a bit worrying since XFree 4.3 seems to need
On Tue, 2002-12-03 at 14:29, Dieter Nützel wrote:
Am Dienstag, 3. Dezember 2002 06:03 schrieb Cédric S.:
I think that I will resell my nforce 415d if I do not find the pilot for
the agp it is not in the kernel 2.4.20...
Didn't Alan have something in his tree?
2.4.20-ac2 or higher.
On Tue, 2002-12-03 at 19:21, Dieter Nützel wrote:
I think we should have something in the tree for 2.5.xx, soon.
XFree 4.3.0 freeze happend on 30. November and should come early 2003.
All distros catch up. So I think it should be handled like 2.4 two years ago.
Having seen the original diff,
On Tue, 2002-12-03 at 21:01, D. Hageman wrote:
easy ... enough said on that. *If* a system is going to be more user
friendly, then configuration files (text based) are the way to go. My
Not really
options based on that. A GUI tool that could easily edit this file should
be the ultimate
On Wed, 2002-11-27 at 11:25, José Fonseca wrote:
But if I undertsood correctly, you refering to the modules included in
the kernel source (linux-2.4.19-gentoo-r9 in this case). I don't know
about these, but as long as you're using = XFree86 4.2.0 you should
compile the ones in
On Wed, 2002-11-27 at 12:46, José Fonseca wrote:
I confess that I'm never sure how the modules in the linux kernel tree and
xfree/dri cvs compare. For a long time 4.2 modules weren't found in the
linux tree. Since which version were they included?
2.4.1something-ac and 2.4.20-rc now has them
On Tue, 2002-11-26 at 16:59, Ian Molton wrote:
the /only/ way I have gotten things to work at all without crashing
(solid!) is to run two completely seperate X servers. this works, but
only one display will work at a time - switching between them turns the
other one off (even if it just left
On Sun, 2002-11-24 at 23:09, Felix Kühling wrote:
I'm having problems burning CDs at speeds higher than 16x too. But
disabling DRI (no radeon.o module loaded) didn't change that. I'm using
a stock 2.4.19 kernel + preemptible patch. On the console I see an IDE
2.4 IDE wont work reliably with
On Sun, 2002-11-24 at 22:20, [EMAIL PROTECTED] wrote:
I was currently using 2.4.20-rc2-ac3 + ALSA + CVS DRI. I went back to
the old installation of 2.4.19-pre5-ac3 and everything works fine (this
also had ALSA and CVS DRI from about May). I then updated ALSA DRI
to current, and it was back to
On Wed, 2002-11-20 at 07:06, Linus Torvalds wrote:
On Wed, 20 Nov 2002, Dieter Nützel wrote:
Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
some testing.
No go so far.
Modules are somewhat
On Wed, 2002-11-20 at 17:30, Dieter Nützel wrote:
System lookup immediately when I try to start ipers, isosurf or switch the
screen. Sadly even when I try the Mesa-4-1-branch with 2.5.47-mm1 or
2.4.19-ck5 (radeon.o 1.6.0).
Are you using scsi - any measuable amount of scsi I/O also hangs
On Thu, 2002-11-07 at 09:34, Ian Molton wrote:
If anyone can do this before christmas, I can put it on my server here
in the UK, where it is (until about christmas) still legal to reverse
engineer for the purposes of fair use (ie. using the hardware you
purchased).
It is after christmas as
On Mon, 2002-11-04 at 20:21, Frank Earl wrote:
On Sunday 03 November 2002 07:05 am, you wrote:
It does although sadly no 3d docs appear to be around
Actually, there is some limited info in the form of a programmer's guide for
the MVP4 that I happen to have that VIA gave out (don't know
On Sun, 2002-11-03 at 01:16, Frank Earl wrote:
On Saturday 02 November 2002 05:18 pm, you wrote:
Wasn't VIAGRA a PC Chips relabeling of the VIA MVP4? What would a DRI
developer do with that? ;)
Write a driver for it??
(If memory serves, the MVP4 had an integrated 3D accelerator,
On Sun, 2002-11-03 at 22:46, Elladan wrote:
could be wrong about that, but I think you'd need rtlinux style
extensions to the kernel to achieve direct interrupt deliveries to
user-space (and you'd need to be root, and such).
You cannot deliver interrupts directly to user space without
On Thu, 2002-10-31 at 21:59, Alan Hourihane wrote:
That's debateable.
In current kernels, if it's not defined you've more than likely
built your kernel with i386 rather than i486 or later, because
building for i486 or later automatically turns on CONFIG_X86_CMPXCHG.
I understand that i386's
On Thu, 2002-10-31 at 02:16, José Fonseca wrote:
project. Also the proprietary nVidia Linux drivers come with some source
code (which was also the basis for the Utah-GLX drivers).
I have the last release they did that was merely all obfuscated, and
some tools for partially deobfuscating it.
On Thu, 2002-10-31 at 11:26, Keith Whitwell wrote:
At one point there was a shadowfb based 2d driver for the voodoo cards -- it
would be interesting an interesting approach to add a dri layer to that
driver, if it still exists.
I use it on several boxes. It has some endian limitations (from
On Wed, 2002-10-30 at 22:05, José Fonseca wrote:
http://kernelnewbies.org/documents/copy_user/ . But although I do
understand the assembly implementation and I actually plan to do an
assembly optimized version myself, I would like to start with a plain C
implementation that would be platform
On Mon, 2002-10-28 at 17:16, Nicholas Leippe wrote:
Memory can only ever increase for processes which do memory allocation
using brk() - there is no way to return such memory to the OS.
-d
no way to return such memory to the OS
IMO that constitutes a leak. It is in effect a lost
On Wed, 2002-10-23 at 02:34, Keith Packard wrote:
The problem with cached writes is that each cacheline will be brought into
cache when the first write is issued. If the memory is across the PCI
Even the K6 has stuff to work on a partial cache line while filling it.
On Wed, 2002-10-23 at 07:53, Philip Brown wrote:
From my driver coding in non-linux areas, I was always taught that
the onus is on the OS to flush the various related areas of
processor cache, before DMA takes place.
The PC it is hardware handled. On sparc hardware its at least partially
On Tue, 2002-10-22 at 21:13, Frank C. Earl wrote:
On Tuesday 22 October 2002 03:00 pm, you wrote:
But wouldnt it be nice to allow the graphics card to directly access
the data from user space ?
It seems to defeat the whole point of DMA, if you have to do multiple
copies of the data.
On Tue, 2002-10-22 at 21:51, Keith Packard wrote:
How expensive is it on a uniprocessor system? Copying data prior to DMA
is not free, especially if the buffers span a significant fraction of
the cache size.
Its actually very hard to measure, because the impact is felt down the
line not
On Wed, 2002-10-23 at 00:19, José Fonseca wrote:
Is it neccessary to copy all the data then DMA it or can you pipeline it
so that the DMA is writing out some of the cache while you copy data in
and verify it ?
I'm not sure what you mean with cache above, but the Mach64 has a ring
buffer
On Mon, 2002-10-07 at 20:48, Joaquim Carvalho wrote:
To continue the job I desperately need some info on the insides of the
SIS300 3D accelerator chip. I read the sis630 and sis300 datasheets and
they don't have a word about 3D acceleration.
For the 6326 I have datasheets (publically posted
On Wed, 2002-10-02 at 12:35, Michael Thaler wrote:
I am not using these binary snapshots, but I appreciate this work. But
please do not compile it against RedHat's glibc2.3 version. RedHat is
the only distribution using it right now. The only reason I can see
for this is, that RedHat _wants_
On Wed, 2002-10-02 at 18:56, Jens Owen wrote:
2) The kernel AGP GART module is one monolithic driver. IHV's need some
way of releasing AGP GART updates without stepping on one another.
I think I speak for the most of the kernel community in saying that we
don't give a hoot about idiots
release version, and using that. CVS versions of software often contain
new bugs and even security vulnerabilities, it is far more prudent to
work with a release version of such a major system component. Because of
this, most distros will probably wait until it becomes a release until
they
On Mon, 2002-09-30 at 13:10, Michel Dänzer wrote:
Option AGPMode 4
Can cause instabilities or even failures, and doesn't provide too much
benefit in my experience.
AGPMode has to match the chipset setting (see lspci -v). There is no
other correct setting or 'tuning'.
Alan
301 - 400 of 406 matches
Mail list logo
