Okay looking for some review/comments, esp on the addition to the
ctx->Const structure to denote if sRGB on FBOs is possible.
Since just enabling the extension doesn't mean anything, we should
probably enable it on anything that enables EXT_texture_sRGB.
Dave.
0001-mesa-965-add-support-for-GL_E
https://bugs.freedesktop.org/show_bug.cgi?id=33447
--- Comment #3 from Bryan Henderson 2011-01-27
19:18:44 PST ---
Created an attachment (id=42625)
View: https://bugs.freedesktop.org/attachment.cgi?id=42625
Review: https://bugs.freedesktop.org/review?bug=33447&attachment=42625
Patch to use th
X server drivers are usually discussed on one of the xorg mailing lists,
not mesa-dev.
You may want to check out the posted documentation on www.x.org before
asking questions, such as:
http://www.x.org/releases/X11R7.6/doc/xorg-server/Xserver-spec.html
http://www.x.org/releases/X11
As with the other question, Xorg has mailing lists for the X servers, but
any X server using .a modules instead of .so modules is so old and obsolete
you're not likely to get help with it anywhere.
On 01/27/11 06:42 PM, kumar vemuri wrote:
> Is this a wrong forum to post this question ? Can someon
Is this a wrong forum to post this question ? Can someone suggest the
right forum if so?
thx
K
On Thu, 2011-01-27 at 07:45 +0530, kumar vemuri wrote:
> Hi,
>
> A few questions on libdri.a which is a device-independent DRI module
> loaded by the xserver during initialization.
>
> a. Can someon
Is this the wrong forum to post this question? Can someone suggest the
right one if so...
thx
K
On Thu, 2011-01-27 at 13:20 +0530, kumar vemuri wrote:
> Hi,
>
> Am new to linux graphics driver dev and is my spare time project.
> Can someone answer some fundamental questions.
>
> Its reg
Just to make sure that this patch was sent out, so replied again here.
Hi Chia-I,
Could you please review this small patch?
Regards,
Jammy
On Thu, Jan 27, 2011 at 1:32 PM, Jammy Zhou wrote:
> egl_dri2 has been made built-in driver of EGL recently, and it depends on
> _glapi_get_proc_address s
https://bugs.freedesktop.org/show_bug.cgi?id=33440
Brian Paul changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=33494
--- Comment #5 from XoD 2011-01-27 15:03:51 PST ---
(In reply to comment #4)
> (In reply to comment #4)
> > If I haven't debbuggeur attach ut2004 terminate on a DBUS error (Signal
> > SIGBUS)
>
> A bus error indicates something may have gone wr
On 27.01.2011 23:20, Ian Romanick wrote:
> On 01/26/2011 04:30 AM, Christoph Bumiller wrote:
> > The current copy propagation code would propagate TEMP[0].x from (6)
> > into TEMP[1].x from (8) in the following, which is clearly wrong:
>
> > 6: MOV TEMP[1].x, TEMP[0].
> > 7: MOV TEMP[0]
On 27.01.2011 23:20, Christoph Bumiller wrote:
> On 27.01.2011 07:34, Eric Anholt wrote:
>> On Wed, 26 Jan 2011 13:30:04 +0100, Christoph Bumiller
>> wrote:
>>> The current copy propagation code would propagate TEMP[0].x from (6)
>>> into TEMP[1].x from (8) in the following, which is clearly wron
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/27/2011 02:20 PM, Christoph Bumiller wrote:
> glsl: add test for copy propagation bug
I converted the test to shader_runner and pushed it as
glsl-copy-propagation-loop-1.
Thanks for the test case.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
On 27.01.2011 07:34, Eric Anholt wrote:
> On Wed, 26 Jan 2011 13:30:04 +0100, Christoph Bumiller
> wrote:
>> The current copy propagation code would propagate TEMP[0].x from (6)
>> into TEMP[1].x from (8) in the following, which is clearly wrong:
>>
>> 6: MOV TEMP[1].x, TEMP[0].
>> 7:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/26/2011 04:30 AM, Christoph Bumiller wrote:
> The current copy propagation code would propagate TEMP[0].x from (6)
> into TEMP[1].x from (8) in the following, which is clearly wrong:
>
> 6: MOV TEMP[1].x, TEMP[0].
> 7: MOV TEMP[0].x,
https://bugs.freedesktop.org/show_bug.cgi?id=33440
--- Comment #5 from Alex Deucher 2011-01-27 13:56:18 PST ---
Seem to work fine here on 64-bit Linux.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the ass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/26/2011 06:16 PM, Zack Rusin wrote:
> Module: Mesa
> Branch: master
> Commit: 59dbdbbb7d0ff90dc7561b1bc337bbb918755103
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=59dbdbbb7d0ff90dc7561b1bc337bbb918755103
>
> Author: Zack Rusin
https://bugs.freedesktop.org/show_bug.cgi?id=33440
Dimitry Andric changed:
What|Removed |Added
Attachment #42416|0 |1
is obsolete|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/26/2011 05:49 PM, Chad Versace wrote:
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -250,6 +250,7 @@ static const struct extension extension_table[] = {
>
> /* Vendor extensions */
> { "GL_3DFX_texture_compr
This doesn't work, you use pipe_resource.depth0 for the array size but
the gallium interface wants you to use pipe_resource.array_size.
Do we fix the state tracker or the interface ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.fr
On Wed, Jan 26, 2011 at 3:17 AM, José Fonseca wrote:
> On Mon, 2011-01-24 at 20:52 -0800, Marek Olšák wrote:
>> Let's assume there are two options with names such that one is a substring
>> of another. Previously, if we only specified the longer one as a debug
>> option,
>> the shorter one would
I did configure again, with the same error.
I'm using this configure line:
./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2\
--enable-gallium-nouveau --with-state-trackers=glx,dri,egl \
--with-egl-platforms=drm --enable-gles-overlay \
Just do ./configure again. After that it should compile just fine.
-- Lucas
Am Donnerstag, den 27.01.2011, 15:13 +0100 schrieb Alberich de megres:
> Hi,
>
> I'm trying to compile mesa trunk.
> But i get this error:
>
> gcc -c -o pipe_nouveau.o pipe_nouveau.c -I../../../../include
> -I../../../.
On 01/27/11 07:46 AM, Owain Ainsworth wrote:
> As someone who was making a fuss about talloc at XDS2010 (then dropped
> off the map due to being insanely busy), i am entirely in favour of
> this.
>
> No time to do any code review right now but spiritually I like this.
Same here - talloc is just a
On Wed, Jan 26, 2011 at 12:17 PM, José Fonseca wrote:
> On Mon, 2011-01-24 at 20:52 -0800, Marek Olšák wrote:
> > Let's assume there are two options with names such that one is a
> substring
> > of another. Previously, if we only specified the longer one as a debug
> option,
> > the shorter one w
On Mon, Jan 24, 2011 at 11:07:23AM -0800, Kenneth Graunke wrote:
> Hello,
>
> This patch series introduces 'ralloc', an MIT-licensed recursive memory
> allocator inspired by talloc.
>
> Since the glsl2 merge, there have been concerns over using talloc in Mesa
> due to its LGPLv3 license. Whether
Hi,
I'm trying to compile mesa trunk.
But i get this error:
gcc -c -o pipe_nouveau.o pipe_nouveau.c -I../../../../include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../src/gallium/include -I../../../../src/gallium/winsys
-I/usr/include/libdrm-D_GNU_SOURCE
Hi Chad,
The least common denominator we're trying to target is MSVC, which doesn't
support most of C99 till date.
We could add -Werror=declaration-after-statement but only in the shared
components (ie., src/mesa, src/gallium/auxiliary) but not src/mesa/drivers &
src/gallium/drivers as there m
27 matches
Mail list logo