Michel Dnzer wrote:
On Mon, 2003-12-29 at 02:45, Jon Smirl wrote:
Would this also be a good time to move the DRM modules into the Mesa tree?
Has it even been decided that's a good idea? I'm not sure it is; their
being separate might help prevent compatibility problems with their
interface, or
On Mon, Dec 29, 2003 at 09:35:38AM +, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2003-12-29 at 02:45, Jon Smirl wrote:
Would this also be a good time to move the DRM modules into the Mesa tree?
Has it even been decided that's a good idea? I'm not sure it is; their
being
Jon Smirl wrote:
The rework of of the dri drivers that I am doing is also dependent on parallel
changes being made in the DRM drivers. I'd like to have them in the same cvs
system so that I can keep things in sync. What the point of keeping them in the
DRI tree if the only client of them now lives
On Llu, 2003-12-29 at 09:45, Alan Hourihane wrote:
Doing it this way, we'd need to have regular releases of the DRM kernel
modules and tag them with CVS keywords. But I'm all for this too.
This makes sense for development. Also in Linus proposed model the
kernel framebuffer drivers are
Adam K Kirchhoff wrote:
Now that there are patches available to support S3TC compressed textures
on Radeon cards, are there any plans to integrate those patches into the
DRI source tree?
Until an agreement can be reached between the open-source community and
the patent holder, IT WILL NEVER
On Mon, 29 Dec 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
Now that there are patches available to support S3TC compressed textures
on Radeon cards, are there any plans to integrate those patches into the
DRI source tree?
Until an agreement can be reached between the open-source
BTW, since I originally asked this question, the general tone of the
discussion has been positive and the general consensus seems to be that
simply uploading the compressed textures to the card, and allowing the
hardware to handle the decompression is not a violation of the patents in
question.
Even if a decision isn't reached, or a compromise with the patent holder
isn't possible, knowing who the patent holder is might be nice - we're
doing Radeon drivers right now for our own OS (unfortunately DRI is a
little too Linux-specific :) and we could license it for ourselves if so desired.
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
4:00PM EST or 1:00PM PST, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous
On Mon, 29 Dec 2003, Matt Sealey wrote:
Ian: wouldn't it be possible to have an official patch, for compressed
texture stuff, that tracks the trees releases?
I think that would be good, if somebody maintains it. It's pretty much
guaranteed that anybody who has a modern graphics card has
I am not a lawyer. None of what follows is legal advice. Furthermore,
I am speaking for myself alone, NOT my employer.
Adam K Kirchhoff wrote:
On Mon, 29 Dec 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
Now that there are patches available to support S3TC compressed textures
on Radeon
It's pretty much guaranteed that anybody who has a modern
graphics card has already been licensed for the patent,
since the hw manufacturers would have done so already.
FWIW, for the longest time SiS (now XGI) didn't have S3TC support for their
Xabre Windows OpenGL drivers though supported
On Mon, 29 Dec 2003, Daniel Vogel wrote:
FWIW, for the longest time SiS (now XGI) didn't have S3TC support for their
Xabre Windows OpenGL drivers though supported it via DirectX/Direct3D. I
guess they didn't feel like licensing the patent from a competitor.
Interesting.
I believe exposing
On Mon, 29 Dec 2003, Ian Romanick wrote:
I am not a lawyer. None of what follows is legal advice. Furthermore,
I am speaking for myself alone, NOT my employer.
Adam K Kirchhoff wrote:
On Mon, 29 Dec 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
Now that there are patches
Adam K Kirchhoff wrote:
BTW, since I originally asked this question, the general tone of the
discussion has been positive and the general consensus seems to be that
simply uploading the compressed textures to the card, and allowing the
hardware to handle the decompression is not a violation of
Daniel Vogel wrote:
I believe exposing the GL_EXT_texture_compression_s3tc and
GL_ARB_texture_compression extensions implies the driver to handle S3TC
compression as an application can pass in uncompressed data, ask the driver
to compress it and then retrieve the compressed data.
The spec allows
I believe exposing the GL_EXT_texture_compression_s3tc and
GL_ARB_texture_compression extensions implies the driver to
handle S3TC compression as an application can pass in
uncompressed data, ask the driver to compress it and then
retrieve the compressed data.
The spec allows that
On Llu, 2003-12-29 at 19:52, Linus Torvalds wrote:
Especially a patch that only passes the compressed textures down to the
hardware - it might make sense to not even have a software fallback.
After all, the only people who care about this patch are game users, and
those people likely do not
Am 2003.12.29 21:23:45 +0100 schrieb(en) Daniel Vogel:
[...]
I believe exposing the GL_EXT_texture_compression_s3tc and
GL_ARB_texture_compression extensions implies the driver to handle S3TC
compression as an application can pass in uncompressed data, ask the driver
to compress it and then
The only thing it seems you can't do is compress to S3TC in
the driver, but I really don't see why that is ever needed?
You need it if you store your source art in a different format on disk (e.g.
using jpeg) and don't want to deal with compression yourself - I believe
e.g. Quake III does
On Thu, 25 Dec 2003 20:00:48 -0800 (PST), Alex Deucher wrote:
--- Felix Khling [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] wrote:
After a brief look at the utah driver: the S3 driver is definitely
not
based on the utah-driver. They are completely different. However, the
Ian Romanick wrote:
Log message:
All of the libglx.a and libGLcore.a code now uses __GLcontextModes to
track FBconfigs / visuals.
Just a heads up. The next step will be to enable fake support for
SGIX_fbconfig on the server-side. Basically, I will just assign an
FBconfig ID to the visuals
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-12-29 23:41 ---
DRI was enabled
23 matches
Mail list logo
