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 ju
José Fonseca wrote:
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
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 r
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 impact
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 efficie
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÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
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: 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
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 g
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 ker
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 u
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 struct
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
drivers)
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
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
in
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
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 benchm
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. A
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 dir
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,
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
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 acces
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 pro
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 as
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, a
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
|
+--> Alter
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
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 swit
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 p
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 as
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. Plea
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
>
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 ou
You can now get
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 license
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 hand
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 work
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 dis
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
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 a
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 CV
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.
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
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, and
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 X
> 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
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
reach
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 and
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 i
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!
49 matches
Mail list logo
