I'm about to start a merge of the XFree86 CVS and bring that into
the DRI CVS trunk. No doubt with the trees diverging quite a bit, that
there will undoubtably be some build bustage along the way.
I'll be bringing it across in stages to try and minimize the disruption.
Jose - it may be worth
On Tue, Oct 22, 2002 at 10:34:58AM +0100, Alan Hourihane wrote:
I'm about to start a merge of the XFree86 CVS and bring that into
the DRI CVS trunk. No doubt with the trees diverging quite a bit, that
there will undoubtably be some build bustage along the way.
I'll be bringing it across in
On Son, 2002-10-20 at 08:15, Matthieu Bonetti wrote:
I am running the lastest dri drivers for my ati radeon 7500 on a X 4.2.1
When I want to play a video with Xv or to play a 3D games (2D games work
fine ?!) the part of the screen where the movie/game is is covered by
some color dots
On Mon, 2002-10-21 at 21:07, Kees Cook wrote:
On Mon, Oct 21, 2002 at 07:53:13PM +0200, Michel Dänzer wrote:
FWIW, I have an AGP 7000 running with PCI GART right now. It has locked
Which binaries need to be replaced?
radeon_drv.o (the 2D driver) and radeon.o (the DRM).
I built the dri
On Mon, 2002-10-21 at 16:17, Keith Whitwell wrote:
Michel Dänzer wrote:
On Sam, 2002-10-19 at 08:10, Allen Akin wrote:
On Fri, Oct 18, 2002 at 07:48:53PM -0700, Ian Romanick wrote:
|
| I had never run glean before, but all I can say is, Wow! Without this
| second patch, running in
On Die, 2002-10-22 at 02:43, Malte Cornils wrote:
On Mon, Oct 21, 2002 at 08:08:20PM +0200, Benjamin Herrenschmidt wrote:
[using /usr/include/linux etc symlinks]
Worked for ages.
Well, maybe, but it has always been the wrong thing to do,
at least according to Linus, and this have been
On Tue, Oct 22, 2002 at 11:31:00AM +0100, José Fonseca wrote:
On Tue, Oct 22, 2002 at 10:34:58AM +0100, Alan Hourihane wrote:
I'm about to start a merge of the XFree86 CVS and bring that into
the DRI CVS trunk. No doubt with the trees diverging quite a bit, that
there will undoubtably be some
On Mon, Oct 21, 2002 at 04:28:12PM -0700, Allen Akin wrote:
One open question is the usage model for such an extension. Keith
suggested that developers will write a small number of code paths, and
then the app will choose one of these at runtime. Typically it'll
choose the grooviest path
Current CVS will not build. It dies trying to link
../../../../extras/freetype2/src/base/ftbase.c to lib/font/FreeType/module/.
I know that some merging is under way from XFree86 CVS. Could that effort
finish to a point where DRI CVS will at least build? :)
--
Smile!
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.
DMA allows you to do other things while the display chip's
On Tue, Oct 22, 2002 at 03:13:09PM -0500, 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
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.
Around 13 o'clock on Oct 22, Ian Romanick wrote:
I would recommend an audit then a copy, with the DMA buffer being setup as
non-cached, write combining memory (like AGP mapped memory).
Non-cached write combining memory doesn't go through the regular cache
buffers and is significantly slower
Around 21 o'clock on Oct 22, Alan Cox wrote:
Unmapping something, especially with threaded apps on SMP boxes is
really really expensive. If you do the audit as you copy the data it may
well actually cost no more than a single copy
How expensive is it on a uniprocessor system? Copying 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 Tue, Oct 22, 2002 at 01:48:35PM -0700, Keith Packard wrote:
Around 13 o'clock on Oct 22, Ian Romanick wrote:
I would recommend an audit then a copy, with the DMA buffer being setup as
non-cached, write combining memory (like AGP mapped memory).
Non-cached write combining memory
On Tue, Oct 22, 2002 at 03:12:52PM -0700, Ian Romanick wrote:
On Tue, Oct 22, 2002 at 12:46:27AM +0200, Charl P. Botha wrote:
Run glthreads with something like: glthreads -n 5
Here's an additional data point. If you move the call to glXDestroyContext
to the end of draw_loop (and delete
Hi,
I'm having a visual problem with an application (NWN under Wine) - it works
fine with LIBGL_ALWAYS_INDIRECT=true but displays the problem (some textures
flicker and show wrong colours) with hardware-accelerated r200.
How can I selectively disable/enable hardware acceleration for certain
On Wed, Oct 23, 2002 at 12:27:57AM +0200, Charl P. Botha wrote:
On Tue, Oct 22, 2002 at 03:12:52PM -0700, Ian Romanick wrote:
On Tue, Oct 22, 2002 at 12:46:27AM +0200, Charl P. Botha wrote:
Run glthreads with something like: glthreads -n 5
Here's an additional data point. If you
On Tue, Oct 22, 2002 at 10:24:04PM +0100, Alan Cox wrote:
[...]
I can believe there are objects in 3D rendering big enough to be worth
mapping but I'd be guessing to name a size. Linus as a chip hacker might
actually have more detailed numbers.
At least with the Mach64 is very rare for this
On Wed, 23 Oct 2002 00:37:47 +0200
Malte Cornils [EMAIL PROTECTED] wrote:
Hi,
I'm having a visual problem with an application (NWN under Wine) - it works
fine with LIBGL_ALWAYS_INDIRECT=true but displays the problem (some textures
flicker and show wrong colours) with hardware-accelerated
at the radeon driver this weekend so that
he's happy with the merge. But if anyone does find problems - please
report them, or the other CVS committers can fix it up as they need.
I've tagged the trunk before I started with the tag 'trunk-20021022' and
after the merge with 'X_4_2_99_2-20021023
On Tue, Oct 22, 2002 at 12:21:00 -0700, Ian Romanick wrote:
Current CVS will not build. It dies trying to link
../../../../extras/freetype2/src/base/ftbase.c to lib/font/FreeType/module/.
I know that some merging is under way from XFree86 CVS. Could that effort
finish to a point where DRI
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 Tue, Oct 22, 2002 at 11:56:19AM -0700, Ian Romanick wrote:
|
| After the meeting, I thought of another possible usage. A number of
| companies, most notably id Software, are using home-grown shading languages.
| Depending on the set of available hardware features, they pick a different
|
On Wed, Oct 23, 2002 at 01:01:39AM +0100, Alan Cox wrote:
On Wed, 2002-10-23 at 00:19, José Fonseca wrote:
[...]
I'm not sure what you mean with cache above, but the Mach64 has a ring
buffer with all the pending DMA buffers, so there will be DMA transfer
simultaneously with the copy/verify, but
Allen Akin wrote:
On Tue, Oct 22, 2002 at 11:56:19AM -0700, Ian Romanick wrote:
|
| After the meeting, I thought of another possible usage. A number of
| companies, most notably id Software, are using home-grown shading languages.
| Depending on the set of available hardware features, they pick
Alan Hourihane wrote:
On Tue, Oct 22, 2002 at 12:21:00 -0700, Ian Romanick wrote:
Current CVS will not build. It dies trying to link
../../../../extras/freetype2/src/base/ftbase.c to lib/font/FreeType/module/.
I know that some merging is under way from XFree86 CVS. Could that effort
finish to
Hi,
My configuration file is just a basic config file with no fancy stuff
(i attached a copy of it).
I don't see any errors in the log. The most weird thing is that i talk with some
people on #xfree86 (opn) and they don't have any problems.
I still have those even on a complete freshly
Around 1 o'clock on Oct 23, Alan Cox wrote:
Uncached writes on PC hardware are almost always a complete loss. You
want the writeback caching so you are writing to the PCI bridge or sdram
in the largest chunk sizes possible.
The problem with cached writes is that each cacheline will be
30 matches
Mail list logo
