felix,
i have been watching the dri development forum
for a while. as you seem to be the person spearheading the savage 3d driver
effort, i have directed this message to you.
I am interested in this driver because the company
i work for uses it on an embedded target. we do not use a powe
felix,
the clipping problem i am seeing is one that you
eluded to previuosly. it seems that when a textured object is drawn, the
glSiccor rect is ignored. this is the clipping that i was referring to. sorry
for being vague. i have run my test program on other hardware/driver
combinations a
dri-devel,
i am using the dri tree build (Mesa/xc - no
branch) of all drivers (2d and 3d) on xfree86 version 4.3.0. my video card
is a 32MB savage 4 pro. X is configured to use the savage drivers.
the problems i am noticing concern the
mouse/cursor. at all times the cursor seems to be sh
downloaded the latest code yesterday and built it. i am
now noticing that the agp mode is only 1X. it used to be 4X. could you or
somebody else point me in the right direction?
thanks,
mark
- Original Message -
From: "Alex Deucher" <[EMAIL PROTECTED]>
To: "Mark Ca
thanks alex. agp mode now 4x again.
mark
- Original Message -
From: "Alex Deucher" <[EMAIL PROTECTED]>
To: "Mark Cass" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, March 26, 2004 2:11 PM
Subject: Re: [Dri-devel] savage : strange cursor
dri-devel,
i have been looking at the clipping issues with the
savage driver. this centers around the use of the scissor box. currently the
savage driver does not use the scissor box.
next are my observations. i am new to this so
please feel free to comment.
i noticed that in the savgeD
dri-devel,
i am having a rebuild problem. not sure what the
trigger is but here is the problem. i do a make World in /xc/xc and get an error
related to HPkeysyms.h. make says it can't find the file. i copied all the
header files into /xc/xc/include and that problem goes away, but then i get
guys,
I am currently working on putting texture
compression support into the savage driver. I am approaching this in two
stages. Stage one is to get the loading of pre-compressed textures working.
Stage two, would be the driver level compression of textures. I no there are
possible legal l
degger" <[EMAIL PROTECTED]>
To: "Mark Cass" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, May 04, 2004 3:08 PM
Subject: Re: [Dri-devel] debugging dri
> Mark Cass wrote:
> >
> > guys,
> >
> > I am currently working on putting texture c
developers,
I am having experiancing a sementation fault when
calling glCompressedTexImage2DARB. I have checked the pointer returned from
GetProcAddress and it seems to be valid (not NULL). i placed a breakpoint in
teximage.c (a mesa source file) on the function _mesa_CompressedTexImage2DAR
guys,
as i have mentioned before i am working on
adding s3tc texture compression support to the savage driver. i have added
code to the savage driver based upon the radeon driver (and patches). the code i
have added only supports uploading pre-compressed textures. as also previously
mentio
byte value. but now the image looks warped!
mark
- Original Message -
From: "Felix Kühling" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Mark Cass" <[EMAIL PROTECTED]>
Sent: Saturday, May 15, 2004 5:25 AM
Subject: Re: savage texture compr
technical documents for the savage
chips could answer this question?
thanks for listening. it's nice sometimes to organize my thoughts on paper,
even if it only serves to define the problem.
mark
- Original Message -
From: "Felix Kühling" <[EMAIL PROTECTED]>
To: <
guys,
finally have some good news. uploading DXT1, DXT3,
and DXT5 compressed textures is working. i still need to implement compressed
sub textures and test very small textures.
the issue was the tile size. i wrote an iterator
into the driver to test all possible tile sizes and found the
guys,
after reading documentation and looking in the code
i noticed that the savage chip has two texture units. when does the second
texture unit do its thing? i placed printfs in both sections of code (tex0 and
tex1) and i only see the first unit doing anything. my test apps do not use
mu
felix,
is there a noticable performance difference with
DMA versus the non-dma version of the savage driver? i have concluded that the
DMA driver work can only be compiled and used with the linux 2.6 kernel, is this
true? I ask becuase i am stuck back on the 2.4 kernel. I also believe you
savage driver team,
when i run glxgears a window appears but nothing is
displayed. the shell from which glxgears was run displays the usual frames per
second and no other information. i checked glxinfo and dri is enabled. also
found nothing unusual in the X log file. i have two options set
felix,
thanks for the advice about the missing glxgears.
had to do a full shutdown and powerup but everything is working fine
now.
i have attached a tarball of my savage driver code.
as i mentioned before, this is from old code (works on 2.4 kernel). the changes
are well documented just
18 matches
Mail list logo
