Mesa/tests> ./projtex
r200CreateScreen
loading ../images/girl.rgb
loading ../images/girl.rgb
fallback Q_BIT
fallback Q_BIT
fallback Q_BIT
[-]
demos/ray
Got some acceleration lately.
Now at ~45 fps (expected more) but was at only 5~6 fps before.
tdfx (V5 5500) was much faster.
-Dieter
--
Mesa/tests> ./multipal
r200CreateScreen
2 texture units supported
../images/tile.rgb 256 x 256
Mesa implementation error: unexpected texture format in r200ChoosTexFormat
Please report to the DRI bug database at dri.sourceforge.net
multipal: texstore.c:729: _mesa_store_teximage2d: Assertion
`texIma
On Fri, Oct 18, 2002 at 12:12:03AM +0200, Charl P. Botha wrote:
>On Thu, Oct 17, 2002 at 02:51:57PM -0600, Marc Aurele La France wrote:
>> The question on my, and David's, mind is whether or not bus mastering was
>> enabled on server entry.
>
>According to lspci, it was definitely enabled.
I'm rel
On Son, 2002-10-13 at 17:54, Michel Dänzer wrote:
>
> I've done some more clueless digging into the problem visible in
> http://penguinppc.org/~daenzer/DRI/evas_test.jpeg and
> http://penguinppc.org/~daenzer/DRI/celestia.jpeg . My first suspicion
> was an off-by-one error in the scissor code, but
On Thu, Oct 17, 2002 at 01:16:13PM -0600, Brian Paul wrote:
| ...
| If we only return a true/false result from the slow/fast query it may not
| be obvious to the application writer what caused the slow path to be taken,
| or what to do about it.
Yep, it turns into a combinatorial search problem.
On Thu, Oct 17, 2002 at 02:51:57PM -0600, Marc Aurele La France wrote:
> The question on my, and David's, mind is whether or not bus mastering was
> enabled on server entry.
According to lspci, it was definitely enabled.
> > Thanks and my apologies for the upset.
>
> Indeed. In the future, plea
On Thu, 17 Oct 2002, Charl P. Botha wrote:
> On Thu, Oct 17, 2002 at 11:17:39AM -0600, Marc Aurele La France wrote:
> > On 17 Oct 2002, Michel Dänzer wrote:
> > > Sounds good, unfortunately it doesn't seem to work for the original
> > > poster - any idea why?
> > Charl P. Botha did not actually
On Thu, Oct 17, 2002 at 11:17:39AM -0600, Marc Aurele La France wrote:
> On 17 Oct 2002, Michel Dänzer wrote:
>
> > On Don, 2002-10-17 at 04:50, David Dawes wrote:
> > > On Tue, Oct 15, 2002 at 12:28:27AM +0200, Charl P. Botha wrote:
> > > >On Mon, Oct 14, 2002 at 04:14:22PM -0600, Marc Aurele La
James Fung wrote:
Thanks.
The PCI radeon seems to work fairly well actually:
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/3DNow! TCL
OpenGL version string: 1.2 Mesa 4.0.4
glxgears gives 1000 frames in 5.0 seconds = 200.000 FPS
I
Allen Akin wrote:
On Thu, Oct 17, 2002 at 10:35:17AM -0700, Ian Romanick wrote:
| On Thu, Oct 17, 2002 at 10:09:28AM -0700, Allen Akin wrote:
| > Also, I wouldn't want to encourage app developers to use the absence of
| > an extension string to determine whether a core function is hardware
| > acc
Thanks.
The PCI radeon seems to work fairly well actually:
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/3DNow! TCL
OpenGL version string: 1.2 Mesa 4.0.4
glxgears gives 1000 frames in 5.0 seconds = 200.000 FPS
I've tried going thr
On Thu, Oct 17, 2002 at 10:35:17AM -0700, Ian Romanick wrote:
| On Thu, Oct 17, 2002 at 10:09:28AM -0700, Allen Akin wrote:
| > Also, I wouldn't want to encourage app developers to use the absence of
| > an extension string to determine whether a core function is hardware
| > accelerated. ...
|
|
On Thu, Oct 17, 2002 at 10:09:28AM -0700, Allen Akin wrote:
> On Thu, Oct 17, 2002 at 09:22:37AM -0700, Ian Romanick wrote:
> | ...
> | So, I asked a couple people around IBM what the accepted practice was. I
> | was told that an implementation is not required to export extension strings
> | for e
> > This has been sitting around for a long time, since I got pulled into
> > the website side of things.
> > I wish to put this up as high level design documentation.
> > Any comments?
> The two documents look great! Up they go.
> They match many of my personal notes about architecture :)
OK the
On Thu, Oct 17, 2002 at 09:22:37AM -0700, Ian Romanick wrote:
| ...
| So, I asked a couple people around IBM what the accepted practice was. I
| was told that an implementation is not required to export extension strings
| for extensions that are required for its adverteised OpenGL version. I was
On Thu, Oct 17, 2002 at 04:39:19PM +0100, Keith Whitwell wrote:
> Ian Romanick wrote:
>
> >>From what I have been told, this is how it works on the Nvidia drivers. I
> > have not verified this first hand.
> >
> > if ( extension string contains "GL_EXT_texture3D" )
> > 3D textures are
Title: RE: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
> > Nice sheme - this will even allow to check the software paths
> > by just tuning the GL version (e.g. via environment variable).
> >
> > But what will you do if your software path is not yet covered
> > by a specific OpenG
Alexander Stohr wrote:
> From what I have been told, this is how it works on the
> Nvidia drivers. I
> have not verified this first hand.
>
> if ( extension string contains "GL_EXT_texture3D" )
> 3D textures are hardware accelerated
> else if ( advertised OpenGL version >=
Title: RE: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
> From what I have been told, this is how it works on the
> Nvidia drivers. I
> have not verified this first hand.
>
> if ( extension string contains "GL_EXT_texture3D" )
> 3D textures are hardware accelerated
>
Ian Romanick wrote:
From what I have been told, this is how it works on the Nvidia drivers. I
have not verified this first hand.
if ( extension string contains "GL_EXT_texture3D" )
3D textures are hardware accelerated
else if ( advertised OpenGL version >= 1.2 )
3D text
On Thu, Oct 17, 2002 at 04:08:25PM +0100, Keith Whitwell wrote:
> Ian Romanick wrote:
> > Over the past year an issue of OpenGL versioning has come up a few times.
> > Basically, we have conflicting goals of wanting to advertise OpenGL 1.3 or
> > 1.4 but not wanting to advertise extensions that are
Keith Whitwell wrote:
Ian Romanick wrote:
Over the past year an issue of OpenGL versioning has come up a few times.
Basically, we have conflicting goals of wanting to advertise OpenGL
1.3 or
1.4 but not wanting to advertise extensions that aren't hardware
accelerated
(cube textures and shadow
Ian Romanick wrote:
Over the past year an issue of OpenGL versioning has come up a few times.
Basically, we have conflicting goals of wanting to advertise OpenGL 1.3 or
1.4 but not wanting to advertise extensions that aren't hardware accelerated
(cube textures and shadow maps come to mind).
I bel
Over the past year an issue of OpenGL versioning has come up a few times.
Basically, we have conflicting goals of wanting to advertise OpenGL 1.3 or
1.4 but not wanting to advertise extensions that aren't hardware accelerated
(cube textures and shadow maps come to mind).
I believe that a solution
This comes up so often (once a week?) that I think we should change the name
of the function to
gl_test_os_katmai_exception_support_SIGFPE_is_expected_just_ignore_it().
And we should rename radeon_cp_get_buffer while we're at it.
Keith
--
On Thu, Oct 17, 2002 at 02:06:49PM +0200, Michel Dänzer wrote:
> On Mon, 2002-10-14 at 04:48, David Hampton wrote:
> > I looked through the last three months of the archives for this mailing
> > list and didn't see anything that quite matched my problem. I get a
> > crash in the DRI code any time
Title: drm_bufs.h and ia64
In xc / programs / Xserver / hw / xfree86 / os-support / linux / drm / kernel / drm_bufs.h this piece of code can be found:
int DRM(addmap)( struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg ) {
// snipped
switch ( map->type ) {
27 matches
Mail list logo
