On Thu, Jan 13, 2011 at 5:04 PM, Dave Airlie wrote:
> Okay i've done an initial implementation for mesa core and swrast and
> i965, since that was the only hw I had locally.
>
> I'll take a look at gallium support later, I've also got 80% of a
> GL_EXT_framebuffer_sRGB done.
Okay here is gallium
Okay i've done an initial implementation for mesa core and swrast and
i965, since that was the only hw I had locally.
I'll take a look at gallium support later, I've also got 80% of a
GL_EXT_framebuffer_sRGB done.
Dave.
0001-mesa-swrast-implement-EXT_texture_sRGB_decode.patch
Description: Binar
On Wed, Jan 12, 2011 at 7:35 AM, Fredrik Höglund wrote:
> On Tuesday 11 January 2011, Alex Deucher wrote:
>> On Fri, Jan 7, 2011 at 2:57 AM, Fredrik Höglund wrote:
>> > On Thursday 16 December 2010, Michel Dänzer wrote:
>> >> The bigger issue here is that no blit should be necessary in the first
I'd really like to make sure someone else has read EXT_texture_sRGB
and agrees with me ;-)
This fixes the fbo-srgb test I wrote on 965 hw hence I'd rather
someone else reviewed it since I haven't independently tested the
piglit test.
Dave.
0001-i965-fix-fbo-srgb-on-i965.patch
Description: Binar
https://bugs.freedesktop.org/show_bug.cgi?id=31907
--- Comment #8 from Brian Paul 2011-01-12 19:54:52 PST ---
Mesa commit 2fa6012f6a0b02de6093cbccba3bf4432f072e57 may have fixed this. Can
you retest?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
And it looks like that Kenneth already fixed it in the meantime. Hehe,
at least I learned something new about linking.
Thanks Kenneth!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
No, I just found the real issue while reading the gentoo guide on
"--as-needed".
In fact the only thing that is wrong here is the order of objects and
libraries:
$(APP_CXX) $(INCLUDES) $(CFLAGS) $(LDFLAGS) $(OBJECTS) $(GLSL2_OBJECTS)
builtin_stubs.o $(TALLOC_LIBS) -o builtin_compiler
When pu
Tobias Jakobi wrote:
Some further testing shows that the LDFLAGS seem to cause the problem.
More specifically the '--as-needed' which is passed to the linker.
As needed should probably be removed from the link line when we're
linking with g++.
Last I looked into such issues, I found that the
Some further testing shows that the LDFLAGS seem to cause the problem.
More specifically the '--as-needed' which is passed to the linker.
I don't know how to fix this, but I figure it could become a problem for
a lot more users since more and more distros seem to use '--as-needed'
by default.
Hello,
I just bisected a build error I encountered when updating to latest git
master.
The bad commit is:
33d0c44910860e0522bd56a0f8637a69e0c4a456
glsl: Autogenerate builtin_functions.cpp as part of the build process.
http://cgit.freedesktop.org/mesa/mesa/commit/?id=33d0c44910860e0522bd56a0f86
---
src/mesa/drivers/dri/intel/intel_fbo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index cbb6275..0db5a49 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dr
This is like how we track FragmentProgram._Current for the computed
ARB fragment program for fixed function texenv, but this gives direct
access to the gl_shader_program for drivers to codegen from, skipping
ARB_fp.
---
src/mesa/main/mtypes.h |1 +
src/mesa/main/state.c | 13 +
This gets one more piece of the pipeline onto the new codegen backend.
Once ARB_fragment_program can generate GLSL programs, we can nuke the
old backend.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |6 +++---
src/mesa/drivers/dri/i965/brw_wm_state.c |4 ++--
2 files changed, 5 insertions(
It would be nice if we handled optimized uniform math like this in
some generic way, since people often end up doing uniform expressions
in shaders, but for now keep this hard-coded like it was in the
texenvprogram code.
---
src/glsl/builtin_variables.h |1 +
src/mesa/main/uniforms.c |
This is a work-in-progress patch series to switch texenvprogram.c from
generating ARB_fp style Mesa IR to generating GLSL IR as its product.
For drivers without native GLSL codegen, that is then turned into the
Mesa IR that can be consumed. However, for 965 we don't use the Mesa
IR product and jus
This is used in the upcoming fixed function shader_program generation,
and shader_program and ARB programs are together in this code until
both fragment and vertex ff get converted.
---
src/mesa/program/prog_cache.c | 53 +---
src/mesa/program/prog_cache.h |
It fails on assertions if the key isn't actually present.
---
src/mesa/main/shaderobj.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 647fd31..89d0f4d 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/m
For fixed function fragment processing in GLSL IR, we want to be able
to reference this state value. gl_* not explicitly permitted is
reserved, so using this variable name internally shouldn't be any
issue.
---
src/glsl/builtin_variables.h |4
src/mesa/main/uniforms.c | 11
Kenneth Graunke wrote:
Right...as Corbin mentioned, the script is written for Python 2.6.
I can change it to 2.5 if necessary, but 2.6 has been out for over two years,
so I didn't think it'd be a problem.
If 2.6 is needed/better then who am I to ask for 2.5 :-).
Maybe configure should be chan
I found the bug, fixed it and pushed the fix to master.
With this optimisation a simple shader which just samples a texture
won't have any alu instructions any more. Since we look only at alu
instructions to determine the maximum gpu count used whe end up with a
gpu count of 0.
Thanks for the hel
Argfl. Sending to list as well.
On Wed, Jan 12, 2011 at 11:36 AM, Corbin Simpson
wrote:
> You're using Python 2.5 and this script needs Python 2.6.
>
> Do we want to keep Python 2.5 compat?
>
> ~ C.
>
> On Wed, Jan 12, 2011 at 4:09 AM, Andy Furniss wrote:
>> Kenneth Graunke wrote:
>>>
>>> Now th
Am Mittwoch, den 12.01.2011, 19:34 +0100 schrieb Michel Dänzer:
> This breaks on my RV635, e.g. the edges of the cube in fgl_glxgears
> become randomly coloured rather than white, but the same kind of
> corruption also appears elsewhere, e.g. with a Windows 7 VM in VMware
> Workstation.
Interestin
2011/1/6 Paulo Zanoni :
> diff --git a/src/egl/opengles2/.gitignore b/src/egl/opengles2/.gitignore
> index bbfb095..8e4bc34 100644
> --- a/src/egl/opengles2/.gitignore
> +++ b/src/egl/opengles2/.gitignore
> @@ -1,3 +1,3 @@
> es2gears
> +es2tri
> es2_info
> -tri
For some reason this chunk wasn't
On Die, 2011-01-11 at 15:47 -0800, Christian KXXnig wrote:
> Module: Mesa
> Branch: master
> Commit: 93a95ad8ff1d543f886f123029d1329513729c4b
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=93a95ad8ff1d543f886f123029d1329513729c4b
>
> Author: Christian König
> Date: Sun Dec 12 15
I've fixed the getopt.h dependency and talloc linking. MSVC is now
building without errors.
MinGW cross-compilation is still broken because a different compiler
must be used for builtin_functions (ordinary gcc instead of
i586-mingw32msvc-gcc)
This was also necessary for Michal's glsl frontend, s
Kenneth Graunke wrote:
Now that this works with both make and SCons, builtin_function.cpp no
longer needs to live in the repository.
After updating talloc to avoid a build error I am now getting -
Regenerating builtin_function.cpp...
python -t -O -O builtins/tools/generate_builtins.py
/home/a
Hi All,
*Mesa Version : Mesa 7.10.0*
$ ./configure --enable-debug --enable-gles1 --enable-gles2
--enable-gallium-svga --enable-gallium-i915 --enable-gallium-i965
--enable-gallium-llvm --disable-glut --with-dri-drivers=
--disable-gallium-radeon --enable-gles-overlay
--with-state-trackers=egl,ve
27 matches
Mail list logo
