First let me say that if anyone would like to take over updating the
dri-trunk-sid packages on a semi-regular basis, I'd really appreciate
it. I don't track the Debian X or DRI mailing lists closely enough to
keep up with changes.
On Tue, 2004-12-28 at 15:00 -0800, Mike Mestnik wrote:
> The sourc
Hi all,
The immediate mode drawing is working now. This enabled me to
implement most (all ? - I am not sure which ones I missed) of rendering
primitives.
Thus the "shimmering_gears" snapshot. If you checkout r300_driver from
CVS with this tag (i.e. "cvs co r300_driver -r shimmering_gear
On Tuesday 28 December 2004 15:11, Adam Jackson wrote:
> On Tuesday 28 December 2004 14:22, Mike Mestnik wrote:
> > http://dri.freedesktop.org/wiki/Download
> >
> > Has links to http://www.freedesktop.org/~dri/snapshots/, that should be
> > fixed up. I would be gald to help, but the page is immuta
The source I'm using contains the old DRI xc. I can see where the old xc
source is needed to build the OLD Xserver and Mesa is needed there to
build it's dri, glx, and opengl Xdrivers. How ever I can't see why this
old xc code has not been diffed in to debian's Xfree86? Would submitting
a patch
> Thanks; I was indeed using the CVS linux-2.6
> directory. All I was really looking for was the 'most
> stable' DRM code to use with Xorg 6.8.1, and that code
> did not seem to be the code that shipped with the
> kernel sources. (One of the 'migration' threads in
> 2.6.9 was consuming a lot of CP
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> Use the linux-core directory in CVS to build not the
> linux-2.6,
>
> linux-core is the future of DRM, hopefully it will
> be merged into 2.6.11
> soon...
>
> other option is to move the pci_enable_device(pdev)
> line in drm_stub.h
> outside the i
On Tuesday 28 December 2004 14:22, Mike Mestnik wrote:
> http://dri.freedesktop.org/wiki/Download
>
> Has links to http://www.freedesktop.org/~dri/snapshots/, that should be
> fixed up. I would be gald to help, but the page is immutable.
This is probably a good time to mention that I've copied th
Philipp Klaus Krause wrote:
Jerome Glisse schrieb:
Yellow dog seems to have support for radeon 9600.
At least they claim so. I tried to find out the source
of their distribution but only manage to get iso for
binary.
On their site they state that they support only 2D,
no hardware-accelerated 3D.
2
Jerome Glisse schrieb:
Yellow dog seems to have support for radeon 9600.
At least they claim so. I tried to find out the source
of their distribution but only manage to get iso for
binary.
On their site they state that they support only 2D,
no hardware-accelerated 3D.
-
http://dri.freedesktop.org/wiki/Download
Has links to http://www.freedesktop.org/~dri/snapshots/, that should be
fixed up. I would be gald to help, but the page is immutable.
__
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://
>>
>> What the command verifier does is that it lets commands thrugh that is
>> knows:
>>
>> 1. Only accesses the 2D-engine or Mpeg engine through writes. (Other
>> areas
>> are blocked).
>> 2. Does not attempt to fetch memory contents from system memory.
>> 3. Does not attempt to fetch memory cont
What the command verifier does is that it lets commands thrugh that is
knows:
1. Only accesses the 2D-engine or Mpeg engine through writes. (Other areas
are blocked).
2. Does not attempt to fetch memory contents from system memory.
3. Does not attempt to fetch memory contents from AGP memory that
Hi!
Vladimir Dergachev wrote:
This has just been implemented in the Unichrome driver, and I'm not
sure wether it's the best or most appopriate way to do it but it
works as follows:
1. The Mesa driver fills a "malloced" system memory buffer with
vertex data.
2. The Mesa driver then calls the DR
Yellow dog seems to have support for radeon 9600.
At least they claim so. I tried to find out the source
of their distribution but only manage to get iso for
binary.
Anyone got source of yellow dog ? Maybe they added
the patch to xfree86, i will give look for that...
Still i am a bit disapointed th
This has just been implemented in the Unichrome driver, and I'm not sure
wether it's the best or most appopriate way to do it but it works as follows:
1. The Mesa driver fills a "malloced" system memory buffer with vertex data.
2. The Mesa driver then calls the DRM through a via-specific IOCTL.
Use the linux-core directory in CVS to build not the linux-2.6,
linux-core is the future of DRM, hopefully it will be merged into 2.6.11
soon...
other option is to move the pci_enable_device(pdev) line in drm_stub.h
outside the if statement it is in ..
Dave.
On Sun, 26 Dec 2004, Chris Rankin w
Looking everywhere i notice that framebuffer sets the following :
RADEON_DP_DATATYPE to RADEON_HOST_BIG_ENDIAN_EN but
the xfree86 drivers do not seems to worry about this register,
anyway i do not think that this correct the problem but i am
wondering what is the purpose of this register.
framebuff
> On Tue, Dec 28, 2004 at 09:10:12AM +0100, Thomas Hellström wrote:
>> Vladimir Dergachev wrote:
>> > Can someone more knowledgable explain to me how to properly access
>> AGP
>> >space from within Mesa driver ?
>
>> This has just been implemented in the Unichrome driver, and I'm not sure
>> weth
On Tue, Dec 28, 2004 at 09:10:12AM +0100, Thomas Hellström wrote:
> Vladimir Dergachev wrote:
> > Can someone more knowledgable explain to me how to properly access AGP
> >space from within Mesa driver ?
> This has just been implemented in the Unichrome driver, and I'm not sure
> wether it's th
Hi!
Vladimir Dergachev wrote:
Hi all,
Can someone more knowledgable explain to me how to properly access AGP
space from within Mesa driver ?
What I want to do is to copy vertex data (i.e. coordinates, colors,
etc) into an array in AGP space so that R300 engine can fetch it from
there. Ideal
20 matches
Mail list logo
