On Mon, Mar 29, 2010 at 1:51 AM, Keith Whitwell
wrote:
> I've just pushed a variation on a theme a couple of people have
> explored in the past, ie. an interface to gallium without an
> intervening state-tracker.
> The purpose of this is for writing minimal test programs to exercise
> new gallium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SpliFF wrote:
> So to clarify, you're saying a partial implementation (decoder only)
> isn't an option at all? If you expose an extension it must be complete?
See the documentation for glGetCompressedTexImage.
-BEGIN PGP SIGNATURE-
Version: Gn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
> The core issue is that some people do not want to see this code in mesa
> in whatever form, because they're afraid of lawsuits. Rumour has it that
> VIA told them that they would sue. And the same things happened with SGI
>
On 03/29/10 15:34, Corbin Simpson wrote:
>
> There is already a non-infringing decoder inside Mesa, wired up
> correctly, that kicks in when the HW supports it, but there's no
> extension that exposes only decoding and loading functionality. As Ian
> said, you need an encoder as well, and no HW has
On Sun, Mar 28, 2010 at 18:39, SpliFF wrote:
> On 03/29/10 11:07, Corbin Simpson wrote:On 03/29/10 11:07, Corbin
> Simpson wrote:
> > Since neither you nor Andrew are lawyers, I would kindly ask that you
> > refrain from attempting to provide legal advice. :3
> >
>
> If you know I'm not a lawyer
On Sun, Mar 28, 2010 at 6:39 PM, SpliFF wrote:
> Solves nothing other than push the legal burden onto someone else
> (distributions) who further push the burden to the end-user. All of
> which makes it harder to use. As far as I can tell the official site of
> the "external project" claims the pro
We were talking a bit on IRC that the GLSL compiler implements the sqrt
function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as is
in the original code, the proposed patch uses just rsq+mul. Please see the
patch log for further explanation, and please review.
-Marek
From 9b834a79a1
On 03/29/10 11:07, Corbin Simpson wrote:On 03/29/10 11:07, Corbin
Simpson wrote:
> Since neither you nor Andrew are lawyers, I would kindly ask that you
> refrain from attempting to provide legal advice. :3
>
If you know I'm not a lawyer (and my nick should be the first clue) then
it isn't an i
I just noticed a potentially interesting thing.
nVidia publishes under the MIT license a software suite called "nVidia
texture tools".
This includes a library called "nvtt" that provides DXT* compression,
plus a library called "nvimage" that provides decompression.
It looks like the libraries can
On Sun, Mar 28, 2010 at 4:47 AM, SpliFF wrote:
> Hi radeonhd, nouveau, mesa3d developers,
>
> Firstly, thank you all very much for all the important work you do.
>
> I've been working as a part-time developer on the "Spring RTS" project
> (open-source game engine) which runs on linux (and other os
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Final versions of both Mesa 7.8 and 7.7.1 have been released. Links on
the Mesa website will still need to be updated, but I think Brian has to
do that.
The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'. I had
originally intended to just use
On Sun, Mar 28, 2010 at 12:19 PM, Luca Barbieri wrote:
> I posted something similar some time ago, that however could use
> hardware accelerated drivers with DRI2 or KMS, provided a substantial
> set of helpers and offered a complement of 3 demos.
>
> My solution to window-system issues was to sim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SpliFF wrote:
> In short, if anyone on these lists can see a way to decompress an s3tc
> image without doing just 1 of the items from EACH of the following 4
> claims then a legal s3tc decoder should be possible.
The problem is that, for OpenGL, just
On Sun, Mar 28, 2010 at 3:07 PM, Luca Barbieri wrote:
> On Sun, Mar 28, 2010 at 7:36 PM, Chris Ball wrote:
>> Hi,
>>
>> > http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build
>> >
>> > swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
>> > swrastg_dri.so.tmp:
I posted something similar some time ago, that however could use
hardware accelerated drivers with DRI2 or KMS, provided a substantial
set of helpers and offered a complement of 3 demos.
My solution to window-system issues was to simply have the application
provide a "draw" callback to the framewo
On Sun, Mar 28, 2010 at 7:36 PM, Chris Ball wrote:
> Hi,
>
> > http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build
> >
> > swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
> > swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4'
>
> This regres
Hi,
I've just pushed a variation on a theme a couple of people have
explored in the past, ie. an interface to gallium without an
intervening state-tracker.
The purpose of this is for writing minimal test programs to exercise
new gallium drivers in isolation from the rest of the codebase.
In fact
Hi,
> http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build
>
> swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
> swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4'
This regression is still present -- could we get a fix or a revert?
Tha
If the application provides s3tc-encoded data through
glCompressedTexImage (usually loaded from a pre-compressed texture
stored on disk), Mesa will pass it unaltered to the graphics card (as
long as the driver/card supports DXT* format ids) and will not need to
use any encoding or decoding algorith
Hi Jakob,
This patch series adds support for GL_OES_EGL_image to st/mesa. The first
patch implements st_manager::get_egl_image in st/egl. The hook is used to
check and return an st_egl_image, which describes an EGLImageKHR. The second
patch implements GL_OES_EGL_image in st/mesa, and the last p
Brian,
Your fix is right. The last_fence variable was a remnant of some state
tracker code I based the change on, and had no place here.
Jose
On Wed, 2010-03-24 at 19:50 -0700, Brian Paul wrote:
> Module: Mesa
> Branch: master
> Commit: 9a5241758231b2dd5ae757645158fa33051f5507
> URL:
> http:
Hi Jakob,
This patch series adds support for GL_OES_EGL_image to st/mesa. The first
patch implements st_manager::get_egl_image in st/egl. The hook is used to
check and return an st_egl_image, which describes an EGLImageKHR. The second
patch implements GL_OES_EGL_image in st/mesa, and the last p
Jesse Barnes wrote:
> On Thu, 4 Mar 2010 15:20:46 -0800
> Jesse Barnes wrote:
>
>> On Fri, 05 Mar 2010 00:16:45 +0100
>> Michel Dänzer wrote:
>>
>>> On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote:
Jesse Barnes wrote:
> Would anyone have objections if these lists moved to freedeskt
Hi radeonhd, nouveau, mesa3d developers,
Firstly, thank you all very much for all the important work you do.
I've been working as a part-time developer on the "Spring RTS" project
(open-source game engine) which runs on linux (and other os). Some time
ago I tried the engine on the open-source ATI
I'm not even sure if its fully working, and I've done some nasty stuff
in the autoconf.in that probably doesn't belong there,
also the dri makefile change to use g++ instead of cc, not sure if
there is a cleaner way to do that either.
Dave.
0001-llvmpipe-add-initial-autoconf-support.patch
Descr
http://bugs.freedesktop.org/show_bug.cgi?id=27312
--- Comment #8 from Chia-I Wu 2010-03-28 01:51:22 PST ---
(In reply to comment #0)
> tmpBuf = (GLubyte *)malloc(4*sizeof(GLubyte));
> glReadPixels(12, 12, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, tmpBuf);
>
> /*
26 matches
Mail list logo
