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 w
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 visual
Hi there,
I have just switched to Gentoo Linux (2.4.20 Kernel)
and I have downloaded a dripkg installation install.sh
script. Unfortunately trying to install provides me
with the following listing in the dri.log. I have
emerged xfree-drm but still no joy. Apparently it
would seem that I hav
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 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 thi
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 t
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 n
> > 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 a
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 t
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 the
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 p
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 expo
> 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
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 car
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
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 IR
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.
Ia
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.
P
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-
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 HAPPEN
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 themsel
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 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; thei
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 separate might help prevent compatibility problems with their
interface, or a
24 matches
Mail list logo
