As Seen on NBC, CBS,
CNN and even Oprah!
The Health Discovery that Actually
Reverses Aging while Burning Fat,
without Dieting or Exercise!
This Proven Discovery has even been reported
on by the New England Journal of Medicine.
Forget Aging and Dieting Forever!
And it's Guaranteed!
Hi All,
we are trying to setup up multi-screen in my system. as we knows, the DRI
module not support Xinerama yet.
it will be software rendering, but when i running glxgears. no matter we use
dual-adapter system or dual-head system.
The second screen always can't display glxgears image? How does
There are new driver snapshots from the trunk (for XFree86 4.3.0) on
http://dri.sourceforge.net/snapshots/ . They were built wihout a glitch
but are yet untested. Please report back success and/or failure.
FYI these snapshots were built by checking out the DRI CVS over the
XFree86 4.3.0 source
The work on the DRM PCI API has been really slow (working on the DRM API
is not the most exciting experiences to me...) but it has enough for
finishing Mach64.
If you recall, for Mach64 we need a set of DMA buffers which aren't
mapped to the clients to assure that they aren't tampered before
There are new driver snapshots from the trunk (for XFree86 4.3.0) on
http://dri.sourceforge.net/snapshots/ . They were built wihout a glitch
but are yet untested. Please report back success and/or failure.
Great!! Does this include mach64 (which is in bleeding-edge subdir)?
Also, Leif, what
Jos? Fonseca [EMAIL PROTECTED] wrote:
FYI these snapshots were built by checking out the DRI CVS over the
XFree86 4.3.0 source [...]
This is tough - I didn't think it would work :-)
This remembers me of a question that came up recently: Some of the changes
that recently were made to the
I think I have found a bug in de radeon dri drivers.
I've tested it with:
The dri/Xfree driver of Mandrake 9.1 and the dri-drivers on the dri-website of
the 4th of april 2003. Both have the same problem.
When redering something in 3D and moving another window on top of the
3D-output-window,
On Fre, 2003-04-04 at 14:56, Martin Spott wrote:
Jos? Fonseca [EMAIL PROTECTED] wrote:
FYI these snapshots were built by checking out the DRI CVS over the
XFree86 4.3.0 source [...]
This is tough - I didn't think it would work :-)
This remembers me of a question that came up
On Fri, Apr 04, 2003 at 03:59:16PM +0200, Michel Dänzer wrote:
On Fre, 2003-04-04 at 14:56, Martin Spott wrote:
This remembers me of a question that came up recently: Some of the changes
that recently were made to the XFree86 CVS repository touch files that are
part of the DRI tree. Does
On Fre, 2003-04-04 at 16:14, Martin Spott wrote:
On Fri, Apr 04, 2003 at 03:59:16PM +0200, Michel Dänzer wrote:
On Fre, 2003-04-04 at 14:56, Martin Spott wrote:
This remembers me of a question that came up recently: Some of the changes
that recently were made to the XFree86 CVS
On Fre, 2003-04-04 at 17:52, koen muylkens wrote:
I think I have found a bug in de radeon dri drivers.
I've tested it with:
The dri/Xfree driver of Mandrake 9.1 and the dri-drivers on the dri-website of
the 4th of april 2003. Both have the same problem.
When redering something in 3D and
On 4 Apr 2003, Sergey V. Oudaltsov wrote:
There are new driver snapshots from the trunk (for XFree86 4.3.0) on
http://dri.sourceforge.net/snapshots/ . They were built wihout a glitch
but are yet untested. Please report back success and/or failure.
Great!! Does this include mach64 (which
Vanson Wu wrote:
Hi All,
we are trying to setup up multi-screen in my system. as we knows, the DRI
module not support Xinerama yet.
it will be software rendering, but when i running glxgears. no matter we use
dual-adapter system or dual-head system.
The second screen always can't display
Michel,
You're bring in issues that effect more than just the X development
community here, so I'm copying the DRI and Mesa developers.
Michel Dänzer wrote:
On Don, 2003-04-03 at 22:03, Alan Cox wrote:
From the DRI people's point of view, it leads to more work as we'd want our
drivers to
José Fonseca wrote:
Now that, thanks to Brian, the textures are pretty much taken care of,
I'm moving into the TNL module for the C++ framework.
First, some definitions. TnL here is defined as the object [or module]
that handles all the geometric (vertex) data (as oppsed to the context
which
You can nowget
prescription
medications prescribed online
with
NO PRIOR PRESCRIPTION REQUIRED
NO PHYSICAL EXAM
NEEDED
Go here
to see all of our available online
drugs.
Valium ... Xanax ... Diethylpropion ... Ambien ... Phentermine ... V i a g r a ... And Many
More
One of our US licensed
Jens Owen wrote:
Michel,
You're bring in issues that effect more than just the X development
community here, so I'm copying the DRI and Mesa developers.
Michel Dänzer wrote:
On Don, 2003-04-03 at 22:03, Alan Cox wrote:
From the DRI people's point of view, it leads to more work as we'd
want
On Fri, Apr 04, 2003 at 08:48:35AM -0700, Brian Paul wrote:
In general, this sounds reasonable but you also have to consider
performance.
The glVertex, Color, TexCoord, etc commands have to be simple and fast. As
it is now, glColor4f (for example) (when implemented in X86 assembly) is
On Fri, Apr 04, 2003 at 10:13:40AM -0500, Leif Delgass wrote:
On 4 Apr 2003, Sergey V. Oudaltsov wrote:
There are new driver snapshots from the trunk (for XFree86 4.3.0) on
http://dri.sourceforge.net/snapshots/ . They were built wihout a glitch
but are yet untested. Please report
José Fonseca wrote:
On Fri, Apr 04, 2003 at 08:48:35AM -0700, Brian Paul wrote:
In general, this sounds reasonable but you also have to consider
performance.
The glVertex, Color, TexCoord, etc commands have to be simple and fast. As
it is now, glColor4f (for example) (when implemented in X86
For some months now I am experiencing lockups when I switched to the VTs,
or changed the video modes or if I tried to shutdown the Xserver.
So I applied the following patch, after looking the related radeon patch
and now I can switch to the VTs or change the videomode without lockups.
But when I
On Fri, 2003-04-04 at 11:12, Panagiotis Papadakos wrote:
For some months now I am experiencing lockups when I switched to the VTs,
or changed the video modes or if I tried to shutdown the Xserver.
So I applied the following patch, after looking the related radeon patch
and now I can switch
On Fri, Apr 04, 2003 at 08:43:31AM -0700, Jens Owen wrote:
Possible
Future: Mesa Tree -+-- XFree86 Tree
- API Focus|- X/3D Integration
- 3D HW Focus |- Complete Window System Focus
|
+-- Alternate X Tree
Philip Brown wrote:
On Fri, Apr 04, 2003 at 08:43:31AM -0700, Jens Owen wrote:
Possible
Future: Mesa Tree -+-- XFree86 Tree
- API Focus|- X/3D Integration
- 3D HW Focus |- Complete Window System Focus
|
+--
On Fre, 2003-04-04 at 22:38, Eric Anholt wrote:
On Fri, 2003-04-04 at 11:12, Panagiotis Papadakos wrote:
For some months now I am experiencing lockups when I switched to the VTs,
or changed the video modes or if I tried to shutdown the Xserver.
So I applied the following patch, after
José Fonseca wrote:
On Fri, Apr 04, 2003 at 08:48:35AM -0700, Brian Paul wrote:
In general, this sounds reasonable but you also have to consider
performance.
The glVertex, Color, TexCoord, etc commands have to be simple and fast. As
it is now, glColor4f (for example) (when implemented in X86
On Fri, Apr 04, 2003 at 10:09:00PM +0100, Keith Whitwell wrote:
Philip Brown wrote:
Are you perhaps envisioning pushing Mesa to evolve into something
like the nvidia UDA API? Where there is suddenly a single, unified
cross-hardware/OS platform for all 3d-accel hardware access to program
Philip Brown wrote:
On Fri, Apr 04, 2003 at 10:09:00PM +0100, Keith Whitwell wrote:
Philip Brown wrote:
Are you perhaps envisioning pushing Mesa to evolve into something
like the nvidia UDA API? Where there is suddenly a single, unified
cross-hardware/OS platform for all 3d-accel hardware
Brian Paul wrote:
I've updated the Mesa sources on the DRI trunk to 5.0.1 with some minor,
post-release bug fixes. I also removed the $Id$ stuff.
I just noticed a couple things in the trunk's Mesa code.
swrast/s_texture.c is missing support for ATI_texture_env_combine3. All
of the rest of the
On Fri, Apr 04, 2003 at 10:34:05PM +0100, Keith Whitwell wrote:
[Philip Brown writes]
So to truely create something akin to nvidia's UDA libs/interface, would
involve porting support for 3d hardware currently handled by DRI, over to
Mesa, and making mesa capable of using it directly,
Philip Brown wrote:
On Fri, Apr 04, 2003 at 10:34:05PM +0100, Keith Whitwell wrote:
[Philip Brown writes]
So to truely create something akin to nvidia's UDA libs/interface, would
involve porting support for 3d hardware currently handled by DRI, over to
Mesa, and making mesa capable of using it
Ian Romanick wrote:
Brian Paul wrote:
I've updated the Mesa sources on the DRI trunk to 5.0.1 with some
minor, post-release bug fixes. I also removed the $Id$ stuff.
I just noticed a couple things in the trunk's Mesa code.
swrast/s_texture.c is missing support for ATI_texture_env_combine3.
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
Right now people use things like Viewperf to make systems purchase
decisions. Unless the graphics hardware and the rest of the system are
very mismatched, the immediate API already has an impact on performance
in those
On Fri, Apr 04, 2003 at 10:23:21PM +0100, Keith Whitwell wrote:
The optimization of the vertex api has yeilded huge improvements. Even
with the runtime-codegenerated versions of these functions in the
radeon/r200 driver, they *still* dominate viewperf profile runs - meaning
that *all
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
Right now people use things like Viewperf to make systems purchase
decisions. Unless the graphics hardware and the rest of the system are
very mismatched, the immediate API already has an impact on performance
On Fri, Apr 04, 2003 at 05:14:54PM -0700, Brian Paul wrote:
José Fonseca wrote:
The things I found more interesting in the issue of applting the TCL
operations on all the vertices at once, or a vertice at each time. From
previous discussions on this list it seems that nowadays most
of CPU
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
In principle, I think the producer/consumer idea is good. Why not
implement known optimizations in it from the start? We already having
*working code* to build formated vertex data (see the radeon r200
On Fri, Apr 04, 2003 at 05:13:44PM -0800, Ian Romanick wrote:
Realistically, either hardware or software uses either
array-of-strctures or structure-of-arrays. Most hardware uses the
former. At that point it becomes a matter of, for a given state vector,
what's the offset in the structure
Could this be a kernel problem?
I have been using 2.4.21-preX and 2.5.6X and all show for me the same
behaviour, with IO-APIC enabled or not.
It reminds me the problem I have with my Promise controller
which after a while if I have dma enabled it completely locks my machine.
What kernel are you
Also I forgot to say that I got a lockup again when I tried to switch to a
VT with the previous patch and also that I believe that with 2.5.6X
kernels I get lockups sooner, than with 2.4.X.
Regards
Panagiotis Papadakos
On Sat, 5 Apr 2003, Panagiotis Papadakos wrote:
Could this be a
On Fri, Apr 04, 2003 at 05:13:44PM -0800, Ian Romanick wrote:
| IMHO, we'd be better to spend our time writing a highly optimized
| just-in-time compiler for ARB_vertex_program. Then we could just write
| vertex programs for the different important state vectors and let the
| compiler
Title: Mail id: nxnwrjkclbgosd
Türkiye'nin
En Büyük Seks ArþiviEn Kaliteli Porno
Siteye Ulaþýn!Porno Film cd'lerinin bulunduðu tek
site!Bu Sitede Neler
Var?Gencecik LolitalarJapon
kýzlarýnýn yüzlerine boþalanlarAzgýn
Title: Mail id: gpraxcicjtrqjdfauxshxaokcbawhgpnvhpvlaxutqndvsfrsxbqysdbv
Türkiye'nin
En Büyük Seks ArþiviEn Kaliteli Porno
Siteye Ulaþýn!Porno Film cd'lerinin bulunduðu tek
site!Bu Sitede Neler
Var?Gencecik LolitalarJapon
Title: Jfrmai
^
No mail!
HX8EsK53u08Tm7H05x8
6789Bocl5-459l12áÄ
ë^¨¥Ë)¢{(ç[ÉV¥¹ål7ÆyÑè²Ø§ú+ë-ïßæ£4 m©ÝÂ'mÚ(¶«r©j| ÷¬Þ²êi¢»h®0z·è¯*.×ÆyÛ ®÷«Ûiÿ÷%ɵÙr¿ Qìv|qi÷ôÓ}4Óm}ÿÝ··ý5ü:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸
The things I found more interesting in the issue of applting the TCL
operations on all the vertices at once, or a vertice at each time. From
previous discussions on this list it seems that nowadays most
of CPU performace is dictated by the cache, so it really seems the later
option is more
Brian Paul wrote:
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
Right now people use things like Viewperf to make systems purchase
decisions. Unless the graphics hardware and the rest of the system
are very mismatched, the immediate API already has an
Ian Romanick wrote:
José Fonseca wrote:
On Fri, Apr 04, 2003 at 10:08:36AM -0800, Ian Romanick wrote:
In principle, I think the producer/consumer idea is good. Why not
implement known optimizations in it from the start? We already
having *working code* to build formated vertex data (see the
Ian Romanick wrote:
Before going down that road we'd want to sit down with oprofile and a
bunch of applications to decide which sets of state we wanted to tune
for. IMHO, we'd be better to spend our time writing a highly optimized
just-in-time compiler for ARB_vertex_program. Then we could
48 matches
Mail list logo
