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 s
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.
xpect things like downgrading to work with
the same configuration file - which XML can do.
> The parser is also non-trivial.
An XML syntax checking parser with SAX and all the other goodies isnt
trivial, but it already exists. Also XFree is alrea
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
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 sti
On Sun, 2003-01-12 at 16:45, Erling A. Jacobsen wrote:
> The good old Mesa-3.4.2 can be Voodoo Graphics enabled by having
> it include the FX subdirectory, so why shouldn't it still work ?
Its possible to write a DRI driver layer for the Voodoo1/Voodoo2
X server. Nobody has done so and I can't see
On Sun, 2003-01-12 at 01:12, Jeff Hartmann wrote:
> Now a question to the community, is there any simple wordprocessing tool
> that outputs docbook/sgml? Perhaps something that takes html to
> docbook/sgml? I'm not too familiar with whats available in respect that
> those sorts of tools, an
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 u
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 buffer
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
On Mon, 2002-12-16 at 20:09, Keith Whitwell wrote:
> > 1) Provide a set of DRM APIs for PCI DMA buffers allocation. No
> > assumption about the buffer management is made and that is entirely left
> > to the DRM driver (which is free to put some in a linked list, map them
> > or whatever). In Linux
On Thu, 2002-12-12 at 19:00, Keith Whitwell wrote:
> I've been looking at what's in 2.4 and it's quite divergent from what we've
> got on the trunk. It is pretty closely related to the xfree 4.2 code, though,
> and most of the changes seem to be in the 2.4 code.
>
> Are you proposing pulling th
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
> alternati
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 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 b
On Wed, 2002-12-11 at 20:12, D. Hageman wrote:
> I have noticed some feedback from Alan and Linus already on this list. Is
> anyone taking care of things yet?
No. There isnt currently a nice setup for this.
---
This sf.net email is sponsore
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
the
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 ultim
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 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 h
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 the
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 http://www.x
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 lef
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 bac
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 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 hang
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.
> >
> >
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 21:03, Andreas Stenglein wrote:
> This chip (82vt501) is on some micro ATX boards with onboard
> solderd VIA C3 700MHz CPU. And I think its in the Linux based
> premium thin client from www.igel.de
Technically the format is mini-itx, its a lot smaller than microatx and
some v
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
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 proces
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 "accel
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 i
On Thu, 2002-10-31 at 15:58, José Fonseca wrote:
> I don't know much about SIS 6326. I know that there is some deprecated
> (it hasn't been updated for the architectural changes) support for SIS
> 630 chips on the CVS.
6326 is much older than 630 and 315 etc. Its in the PIO with very small
fifo c
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 (fro
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. Th
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 platfor
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 ef
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
s
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 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
>
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 i
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
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 poste
> 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
> th
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 want
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 _want
On Mon, 2002-09-30 at 19:04, Jeff Hartmann wrote:
> I know we have talked about this issue before, but I want to rehash. The
> statement that only what the bios programs is not entirely correct, but this
> does hold true for some chipsets where we don't know all the details of agp
> mode sw
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'.
Ala
On Sun, 2002-09-29 at 17:04, Luciano Montanaro wrote:
> To summarize:
> - I bought a graphics card, with drivers from the vendor that I don't need.
> - Those drivers have support for the 'clever' texture compression format.
> - My vendor already paid for the implementation of the patented technolo
On Fri, 2002-09-27 at 13:51, Dieter Nützel wrote:
> > Is it true that the nForce is unsupported by agpgart
> Yes.
News to me that it is
> Have a close look at LKML and watch out for some posts from Alan Cox about
> nForce. I think I remember he had something going.
We have IDE
On Fri, 2002-09-27 at 17:01, Michel Dänzer wrote:
> > Yep, but I guess you have to worry about then going to sleep *after* the
> > interrupt has arrived, if there is a delay in getting the scratch write across
> > the bus, compared to the irq, which should be instantaneous.
>
> Is that really a
On Wed, 2002-09-18 at 14:14, Serge Gavrilov wrote:
> OS - Debian GNU/Linux (woody)
> Kernel is 2.4.19
> XFree 4.1
My 3D was never stable with 4.1. With 4.2 it was pretty good. With 4.2
and Jonny Strom's patch its not died yet.
---
This SF.NE
> Is there anything gained by checking the device class before looking
> for the AGP capability? The "agp_find_cap" patch attached implements
> this idea. I've compiled and booted kernels with both patches, but
> they're otherwise untested.
Just caution about not twiddling stuff we shouldnt tou
> we move the whole driver structure to kernel? Drivers for every other device
Not really.
> STRUCTURE. For a great UI, we need DMA, vsync and devices communicating with
> each other directly or with little overhead. Why insist on doing this in
A video driver has to have extremely good latency
401 - 455 of 455 matches
Mail list logo
