[Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie 
Hey,

So I was trying to fix tfp test on r300g, and ran into an issue with
dri st I think.

So the way TFP works we get dri2_set_tex_buffer, which then validates the
attachment, but ignores the format passed in. So r300g picks up the kernel
buffer from the handle and sets up the texture + texture state without
the format
information.

Once we've validated, we call ctx->st->teximage and can give it a different
format however at no point does r300g get any place to change the texture format
and update its internal state.

I'm not sure if either r300g should delay setting up its internal
state for emission
until later or whether we need to enhance the st interface.

The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8
which triggers this.

Dave.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH-RFC] st/mesa: Add GL_OES_EGL_image support

2010-04-04 Thread Chia-I Wu 
On Sat, Apr 3, 2010 at 11:51 PM, Jakob Bornecrantz  wrote:
> On Sun, Mar 28, 2010 at 6:13 PM, Chia-I Wu  wrote:
>> 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 patch adds a demo
>> for the new functionality.  I've tested it with egl_x11_i915.so, but it 
>> should
>> work with other hardware drivers.
>> Do you mind having a look at the patches, especially the first one?  I'd like
>> to hear your opinions before merging the patches, and going on to work on
>> EGLImage support in st/dri.
> Terribly sorry for taking this long to reply. The patches look good go
> ahead and commit. Regarding EGLImage in st/dri don't let me stop you
> if you have a itch to do it. If I get time over sometime I'll ask you
> then if you have done anything.
That's fine.  I will rebase the patches and commit soon.

I might need to switch my focus to Windows for a while.  I guess I will use the
chance to convert st/wgl to st_api.h and finally drop st_public.h.  Until it is
too painful to work on Windows and I need to work on something fun, I will add
EGLImage support to st/dri after dropping st_public.h.
> And again thanks for the work hard work!

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium failing to build on darwin/ppc

2010-04-04 Thread tom fogal 
Jeremy Huddleston  writes:
> 
> On Apr 3, 2010, at 12:34, tom fogal wrote:
> 
> > Vinson Lee  writes:
> >> Leopard uses gcc-4.0, which didn't have built-in support for atomic
> >> variables.
> > 
> > u_atomic.h should probably check for a supported compiler; Jeremy, does
> > the attached patch produce an understandable error instead of a link
> > error?
> 
> Yeah, that bails appropriately, but the message should probably be soemthing 
> more like:
> 
> #error "galium requires a compiler that supports gcc atomics."

I see Vinson committed a better fix to the 7.8 branch.  However,
Vinson, I think you made a typo:

  #elif defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 401)

That version should be "410", not "401", right?

-tom

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] mesa: update_arrays() depends on program state.

2010-04-04 Thread Henri Verbeet 
It uses ctx->VertexProgram._Current.
---
 src/mesa/main/state.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index 589029d..b971cc9 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -582,9 +582,6 @@ _mesa_update_state_locked( GLcontext *ctx )
if (new_state & _DD_NEW_SEPARATE_SPECULAR)
   update_separate_specular( ctx );
 
-   if (new_state & (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT))
-  update_arrays( ctx );
-
if (new_state & (_NEW_BUFFERS | _NEW_VIEWPORT))
   update_viewport_matrix(ctx);
 
@@ -620,6 +617,8 @@ _mesa_update_state_locked( GLcontext *ctx )
   new_prog_state |= update_program( ctx );
}
 
+   if (new_state & (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT))
+  update_arrays( ctx );
 
  out:
new_prog_state |= update_program_constants(ctx);
-- 
1.6.4.4


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] Gallium: ARB_half_float_vertex

2010-04-04 Thread Marek Olšák 
Hi devs,

I (and Luca mostly) have made some simple patches which add
GL_ARB_half_float_vertex to Gallium.

Author: Marek Olšák 
r300g: enable half float vertex
st/mesa: query for half float vertex support

Author: Luca Barbieri 
st/mesa: half float vertex support

Please review the commits here:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=half-float-vertex

Please let me know whether I may push this.

Cheers

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

2010-04-04 Thread Luca Barbieri 
There was some talk about doing the query with a vertex buffer target
for is_format_supported.

After gallium-resources is merged, this should be automatically possible.

BTW, the st/mesa patch originally was from Dave Airlie and was
slightly changed by me.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

2010-04-04 Thread Marek Olšák 
On Sun, Apr 4, 2010 at 9:41 PM, Luca Barbieri wrote:

> There was some talk about doing the query with a vertex buffer target
> for is_format_supported.
>

Does it mean there will be format fallbacks? Because dword-unaligned but
still pretty common (i.e. GL1.1) vertex formats aren't supported by r300,
most often we hit R16G16B16. What will happen when is_format_supported says
NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3, which
every in-tree state tracker ignores.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium failing to build on darwin/ppc

2010-04-04 Thread Vinson Lee 
> -Original Message-
> 
> I see Vinson committed a better fix to the 7.8 branch.  However,
> Vinson, I think you made a typo:
> 
>   #elif defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 401)
> 
> That version should be "410", not "401", right?
> 

The PIPE_CC_GCC_VERSION macro doesn't use __GNUC_PATCHLEVEL__.

src/gallium/include/pipe/p_config.h
54  #if defined(__GNUC__)
55  #define PIPE_CC_GCC
56  #define PIPE_CC_GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__)
57  #endif

printf("PIPE_CC_GCC_VERSION: %d\n", PIPE_CC_GCC_VERSION);
PIPE_CC_GCC_VERSION: 402

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

2010-04-04 Thread Luca Barbieri 
> Does it mean there will be format fallbacks? Because dword-unaligned but
> still pretty common (i.e. GL1.1) vertex formats aren't supported by r300,
> most often we hit R16G16B16. What will happen when is_format_supported says
> NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3, which
> every in-tree state tracker ignores.

I'm not sure I understand correctly what you are saying.

The idea is to do like you did in your patch, but instead of calling
screen->get_param(screen, PIPE_CAP_HALF_FLOAT_VERTEX), calling
screen->is_format_supported(screen, PIPE_FORMAT_R16G16B16G16,
PIPE_BUFFER, ..., ...).

The PIPE_BUFFER target is supported in gallium-resources, but I'm not
sure whether this way of querying vertex formats is supported; it
would probably need to be added first.

If you mean that r300 doesn't support R16G16B16, I suppose you can
just use R16G16B16A16 and ignore the extra fetched w element (the
vertex buffer stride will make this work properly).

However, if non-dword-aligned vertex buffer strides or vertex element
offsets are not supported, I think you have a serious problem, which
is however independent of half float vertices since I don't think
OpenGL places any alignment constraints on those values (correct me if
I'm wrong).

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

2010-04-04 Thread Marek Olšák 
On Sun, Apr 4, 2010 at 10:28 PM, Luca Barbieri wrote:

> > Does it mean there will be format fallbacks? Because dword-unaligned but
> > still pretty common (i.e. GL1.1) vertex formats aren't supported by r300,
> > most often we hit R16G16B16. What will happen when is_format_supported
> says
> > NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3,
> which
> > every in-tree state tracker ignores.
>
> I'm not sure I understand correctly what you are saying.
>
> The idea is to do like you did in your patch, but instead of calling
> screen->get_param(screen, PIPE_CAP_HALF_FLOAT_VERTEX), calling
> screen->is_format_supported(screen, PIPE_FORMAT_R16G16B16G16,
> PIPE_BUFFER, ..., ...).
>
> The PIPE_BUFFER target is supported in gallium-resources, but I'm not
> sure whether this way of querying vertex formats is supported; it
> would probably need to be added first.
>
> If you mean that r300 doesn't support R16G16B16, I suppose you can
> just use R16G16B16A16 and ignore the extra fetched w element (the
> vertex buffer stride will make this work properly).
>

I've tried to do it this way, it locks up (unless I am missing something).

However, if non-dword-aligned vertex buffer strides or vertex element
> offsets are not supported, I think you have a serious problem, which
> is however independent of half float vertices since I don't think
> OpenGL places any alignment constraints on those values (correct me if
> I'm wrong).
>

You're right.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

2010-04-04 Thread Luca Barbieri 
>> If you mean that r300 doesn't support R16G16B16, I suppose you can
>> just use R16G16B16A16 and ignore the extra fetched w element (the
>> vertex buffer stride will make this work properly).
>
> I've tried to do it this way, it locks up (unless I am missing something).

Shouldn't there be official ATI hardware documentation for r300
describing such things? (just curious)

Otherwise, I guess you could trace the ATI binary driver and see what it does...

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie 
On Sun, Apr 4, 2010 at 8:31 PM, Dave Airlie  wrote:
> Hey,
>
> So I was trying to fix tfp test on r300g, and ran into an issue with
> dri st I think.
>
> So the way TFP works we get dri2_set_tex_buffer, which then validates the
> attachment, but ignores the format passed in. So r300g picks up the kernel
> buffer from the handle and sets up the texture + texture state without
> the format
> information.
>
> Once we've validated, we call ctx->st->teximage and can give it a different
> format however at no point does r300g get any place to change the texture 
> format
> and update its internal state.
>
> I'm not sure if either r300g should delay setting up its internal
> state for emission
> until later or whether we need to enhance the st interface.
>
> The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8
> which triggers this.
>

Here's a hacky patch to demonstrate the issue, though it doesn't fix the problem
I'm seeing with the test, just one less thing wrong.

Dave.


0001-dri-st-add-hacky-tfp-format-override.patch
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

2010-04-04 Thread Nicolai Haehnle 
Hi,

On Sat, Apr 3, 2010 at 3:31 AM, Tom Stellard  wrote:
> I have completed a first draft of my Google Summer of Code
> proposal, and I would appreciate feedback from some of the
> Mesa developers.  I have included the project plan from my
> proposal in this email, and you can also view my full proposal here:
> http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tstellar/t126997450856
> However, I think you will need a google login to view it.

I like your proposal, and I believe it's quite workable as a GSoC
project as far as scope is concerned. The LLVM points mentioned are
valid, but since you seem to be interested in focusing on R300, I
believe you are absolutely on the right track, since if you complete
the tasks outlined in your project, it will be a very tangible step
forward *right now*.


> Schedule / Deliverables:
> 1. Enable branch emulation for Gallium drivers (4 weeks)
> 2. Unroll loops for Gallium drivers (2 - 3 weeks)

I believe your time estimate for loop unrolling should be longer, and
for branch emulation probably shorter, particularly since there is
existing work. So branch emulation should go much quicker; I don't
think the part about re-translating to TGSI is too difficult.

> Midterm Evaluation
> 3. Loops and Conditionals for R500 fragment and vertex shaders (4 weeks)

This part is in some ways the most interesting one, and even if we do
go to LLVM eventually (but I doubt it's going to happen any time
soon), this part will still be needed.

It would definitely be great to see this project come to fruition!

cu,
Nicolai

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

2010-04-04 Thread Nicolai Haehnle 
On Sat, Apr 3, 2010 at 2:37 PM, Luca Barbieri  wrote:
> Note all "X compiler is bad for VLIW or whatever GPU architecture"
> objections are irrelevant, since almost all optimizations are totally
> architecture independent.

Way back I actually looked into LLVM for R300. I was totally
unconvinced by their vector support back then, but that may well have
changed. In particular, I'm curious about how LLVM deals with
writemasks. Writing to only a select subsets of components of a vector
is something I've seen in a lot of shaders, but it doesn't seem to be
too popular in CPU-bound SSE code, which is probably why LLVM didn't
support it well. Has that improved?

The trouble with writemasks is that it's not something you can just
implement one module for. All your optimization passes, from simple
peephole to the smartest loop modifications need to understand the
meaning of writemasks.


> This is obviously not achievable if Mesa/Gallium contributors are
> supposed to write the compiler optimization themselves, since clearly
> there is not even enough manpower to support a relatively up-to-date
> version of OpenGL or, say, to have drivers that can allocate and fence
> GPU memory in a sensible and fast way, or implement hierarchical Z
> buffers, or any of the other things expected from a decent driver,
> that the Mesa drivers don't do.

I agree, though if I were to start an LLVM-based compilation project,
I would do it for R600+, not for R300. That would be a very different
kind of project.


> So, for a GSoC project, I'd kind of suggest:
> (1) Adapt the gallivm/llvmpipe TGSI->LLVM converter to also generate
> AoS code (i.e. RGBA vectors as opposed to , , etc.) if
> possible or write one from scratch otherwise
> (2) Write a LLVM->TGSI backend, restricted to programs without any control 
> flow
> (3) Make LLVM->TGSI always work (even with control flow and DDX/DDY)
> (4) Hook up all useful LLVM optimizations

A LLVM->TGSI conversion is not the best way to go because TGSI doesn't
match the hardware all that well, at least in the Radeon family.
R300-R500 fragment programs have the weird RGB/A split, and R600+ is
yet another beast that looks quite different from TGSI. So at least
for Radeon, I believe it would be best to generate hardware-level
instructions directly from LLVM, possibly via some Radeon-family
specific intermediate representation.

The thing is, a lot of the optimizations in the r300 compiler are
actually there *because* TGSI (and Mesa instructions) are not a good
match for what the hardware looks like. So replacing those
optimizations by an LLVM pass which then becomes useless due to a drop
to TGSI seems a bit silly.

In a way, this is rather frustrating when dealing with the assembly
produced by the Mesa GLSL compiler. That compiler is rather
well-meaning and tries to deal well with scalar values, but then those
"optimizations" are actually counterproductive for Radeon, because
they end up e.g. using instructions like RCP and RSQ on one of the RGB
components, which happens to be a really bad idea. It would be nice if
we could feed e.g. LLVM IR into the Gallium driver instead of TGSI,
and let the Gallium driver worry about all optimizations.

Anyway, I'm convinced that LLVM (or something like it) is necessary
for the future. However, for this particular GSoC proposal, it's off
the mark.

cu,
Nicolai

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie 
>
> Here's a hacky patch to demonstrate the issue, though it doesn't fix the 
> problem
> I'm seeing with the test, just one less thing wrong.
>

Here's a second patch that actually fixes the piglit tfp test for me on r300g.

Dave.


0001-dri-st-add-hacky-tfp-format-override-v2.patch
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] Gallium: EXT_gpu_program_parameters

2010-04-04 Thread Marek Olšák 
Hi devs,

this extensions is extensively used in Wine for obvious performance reasons
and is quite popular in the GL community, therefore we should advertise it.
All needed code seems to be already in mesa/main, so unless I overlooked
something, the patch below is sufficient. Any comments, please?

-Marek

diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 0118c60..ae5e62b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -183,6 +183,7 @@ void st_init_extensions(struct st_context *st)
ctx->Extensions.EXT_framebuffer_object = GL_TRUE;
ctx->Extensions.EXT_framebuffer_multisample = GL_TRUE;
ctx->Extensions.EXT_fog_coord = GL_TRUE;
+   ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
ctx->Extensions.EXT_multi_draw_arrays = GL_TRUE;
ctx->Extensions.EXT_pixel_buffer_object = GL_TRUE;
ctx->Extensions.EXT_point_parameters = GL_TRUE;
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] segfault in readpix demo with GL_OES_read_format on r300g

2010-04-04 Thread Dave Airlie 
Starting program: /home/airlied/mesa/progs/demos/readpix
[Thread debugging using libthread_db enabled]
GL_VERSION = 2.1 Mesa 7.9-devel
GL_RENDERER = Gallium 0.4 on RV530

Program received signal SIGSEGV, Segmentation fault.
0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
at main/framebuffer.c:1021
1021}
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-8.fc12.i686 libICE-1.0.6-1.fc12.i686
libSM-1.1.0-7.fc12.i686 libX11-1.3-1.fc12.i686
libXdamage-1.1.2-1.fc12.i686 libXext-1.1-2.fc12.i686
libXfixes-4.0.4-1.fc12.i686 libXi-1.3-2.fc12.i686
libXmu-1.0.5-1.fc12.i686 libXt-1.0.7-1.fc12.i686
libXxf86vm-1.1.0-1.fc12.i686 libgcc-4.4.3-4.fc12.i686
libstdc++-4.4.3-4.fc12.i686 libuuid-2.16.2-5.fc12.i686
libxcb-1.5-1.fc12.i686
(gdb) bt
#0  0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
at main/framebuffer.c:1021
#1  0xb7d75758 in _mesa_GetIntegerv (pname=35738, params=0x804c41c)
at main/get.c:5576
#2  0x080493ae in Init (argc=1, argv=0xb2b4) at readpix.c:354
#3  main (argc=1, argv=0xb2b4) at readpix.c:396
(gdb)


Dave.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] Emergency Mesa 7.8.1 release coming this Monday.

2010-04-04 Thread Ian Romanick 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

Over the weekend I was alerted that some values in Mesa's glxext.h do
not match the values in the OpenGL registry.  Specifically, the value of
GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK is wrong both in name and in value.
 I am going to fix this by syncing the official version of glxext.h from
the Khronos website.  In the mean time please do not distribute or use
the copy of glxext.h in Mesa.  Use version 27 or later from the
OpenGL.org website:

http://www.opengl.org/registry/api/glxext.h

I won't have time to make the release until Monday morning PDT.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku5JsMACgkQX1gOwKyEAw+CNwCfeFQFIK25HPAlfh+g/nFtLUno
AMAAn2500k2DwL9JvNgCybl8pOiqrTrS
=kRJm
-END PGP SIGNATURE-

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

2010-04-04 Thread Luca Barbieri 
> Way back I actually looked into LLVM for R300. I was totally
> unconvinced by their vector support back then, but that may well have
> changed. In particular, I'm curious about how LLVM deals with
> writemasks. Writing to only a select subsets of components of a vector
> is something I've seen in a lot of shaders, but it doesn't seem to be
> too popular in CPU-bound SSE code, which is probably why LLVM didn't
> support it well. Has that improved?
>
> The trouble with writemasks is that it's not something you can just
> implement one module for. All your optimization passes, from simple
> peephole to the smartest loop modifications need to understand the
> meaning of writemasks.

You should be able to just use
shufflevector/insertelement/extractelement to mix the new computed
values with the previous values in the vector register (as well as
doing swizzles).

There is also the option of immediately scalarizing, optimizing the
scalar code, and then revectorizing.
This risks pessimizing the input code, but might turn out to work well.

> I agree, though if I were to start an LLVM-based compilation project,
> I would do it for R600+, not for R300. That would be a very different
> kind of project.

> A LLVM->TGSI conversion is not the best way to go because TGSI doesn't
> match the hardware all that well, at least in the Radeon family.
> R300-R500 fragment programs have the weird RGB/A split, and R600+ is
> yet another beast that looks quite different from TGSI. So at least
> for Radeon, I believe it would be best to generate hardware-level
> instructions directly from LLVM, possibly via some Radeon-family
> specific intermediate representation.

The advantage of LLVM->TGSI would be that it works with all drivers
without any driver specific code, so it probably makes sense as an
initial step.
nv30/nv40 fragment programs map almost directly to TGSI (with the
addition of condition codes, and half float precision, and a few other
things).
Things that end up using an existing graphics API like vmware svga, or
using the llvm optimizer for game development, also need tgsi-like
output.
Thus, even if TGSI itself becomes irrelevant at some point, any
nontrivial parts of the LLVM->TGSI code should be needed anyway for
those cases.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Chia-I Wu 
On Sun, Apr 4, 2010 at 6:31 PM, Dave Airlie  wrote:
> Hey,
>
> So I was trying to fix tfp test on r300g, and ran into an issue with
> dri st I think.
>
> So the way TFP works we get dri2_set_tex_buffer, which then validates the
> attachment, but ignores the format passed in. So r300g picks up the kernel
> buffer from the handle and sets up the texture + texture state without
> the format
> information.
>
> Once we've validated, we call ctx->st->teximage and can give it a different
> format however at no point does r300g get any place to change the texture 
> format
> and update its internal state.
>
> I'm not sure if either r300g should delay setting up its internal
> state for emission
> until later or whether we need to enhance the st interface.
>
> The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8
> which triggers this.
The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
passes the test with the patch?

The teximage callback has an internal_format parameter that specifies how the
pipe texture should be treated.  It can differ from the format of the texture.
It seems to suffice for TFP.  I was lazy enough not to use it :(

-- 
o...@lunarg.com
From 2a1c9adc331523be84db243fffabb9dc9d0843eb Mon Sep 17 00:00:00 2001
From: Chia-I Wu 
Date: Mon, 5 Apr 2010 10:06:52 +0800
Subject: [PATCH] st/dri: Fix setTexBuffer2 with __DRI_TEXTURE_FORMAT_RGB.

When the format is __DRI_TEXTURE_FORMAT_RGB, the texture should be
treated as if there is no alpha channel.
---
 src/gallium/state_trackers/dri/drm/dri2.c |   18 +-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index c632f0f..09e5e04 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -84,9 +84,25 @@ dri2_set_tex_buffer2(__DRIcontext *pDRICtx, GLint target,
pt = drawable->textures[ST_ATTACHMENT_FRONT_LEFT];
 
if (pt) {
+  enum pipe_format internal_format = pt->format;
+
+  if (format == __DRI_TEXTURE_FORMAT_RGB)  {
+ /* only need to cover the formats recognized by dri_fill_st_visual */
+ switch (internal_format) {
+ case PIPE_FORMAT_B8G8R8A8_UNORM:
+internal_format = PIPE_FORMAT_B8G8R8X8_UNORM;
+break;
+ case PIPE_FORMAT_A8R8G8B8_UNORM:
+internal_format = PIPE_FORMAT_X8R8G8B8_UNORM;
+break;
+ default:
+break;
+ }
+  }
+
   ctx->st->teximage(ctx->st,
 (target == GL_TEXTURE_2D) ? ST_TEXTURE_2D : ST_TEXTURE_RECT,
-0, drawable->stvis.color_format, pt, FALSE);
+0, internal_format, pt, FALSE);
}
 }
 
-- 
1.7.0

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] segfault in readpix demo with GL_OES_read_format on r300g

2010-04-04 Thread Chia-I Wu 
On Mon, Apr 5, 2010 at 7:42 AM, Dave Airlie  wrote:
> Starting program: /home/airlied/mesa/progs/demos/readpix
> [Thread debugging using libthread_db enabled]
> GL_VERSION = 2.1 Mesa 7.9-devel
> GL_RENDERER = Gallium 0.4 on RV530
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
>    at main/framebuffer.c:1021
> 1021    }
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-8.fc12.i686 libICE-1.0.6-1.fc12.i686
> libSM-1.1.0-7.fc12.i686 libX11-1.3-1.fc12.i686
> libXdamage-1.1.2-1.fc12.i686 libXext-1.1-2.fc12.i686
> libXfixes-4.0.4-1.fc12.i686 libXi-1.3-2.fc12.i686
> libXmu-1.0.5-1.fc12.i686 libXt-1.0.7-1.fc12.i686
> libXxf86vm-1.1.0-1.fc12.i686 libgcc-4.4.3-4.fc12.i686
> libstdc++-4.4.3-4.fc12.i686 libuuid-2.16.2-5.fc12.i686
> libxcb-1.5-1.fc12.i686
> (gdb) bt
> #0  0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38)
>    at main/framebuffer.c:1021
> #1  0xb7d75758 in _mesa_GetIntegerv (pname=35738, params=0x804c41c)
>    at main/get.c:5576
> #2  0x080493ae in Init (argc=1, argv=0xb2b4) at readpix.c:354
> #3  main (argc=1, argv=0xb2b4) at readpix.c:396
> (gdb)
I have the segfault with i915g and non-gallium fakeglx.  It seems _mesa_Get*
should also validate the states before getting these state variables

 - GL_IMPLEMENTATION_COLOR_READ_TYPE_OES
 - GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES

-- 
o...@lunarg.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie 
On Mon, Apr 5, 2010 at 12:49 PM, Chia-I Wu  wrote:
> On Sun, Apr 4, 2010 at 6:31 PM, Dave Airlie  wrote:
>> Hey,
>>
>> So I was trying to fix tfp test on r300g, and ran into an issue with
>> dri st I think.
>>
>> So the way TFP works we get dri2_set_tex_buffer, which then validates the
>> attachment, but ignores the format passed in. So r300g picks up the kernel
>> buffer from the handle and sets up the texture + texture state without
>> the format
>> information.
>>
>> Once we've validated, we call ctx->st->teximage and can give it a different
>> format however at no point does r300g get any place to change the texture 
>> format
>> and update its internal state.
>>
>> I'm not sure if either r300g should delay setting up its internal
>> state for emission
>> until later or whether we need to enhance the st interface.
>>
>> The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8
>> which triggers this.
> The attached patch fixes tfp test for me (with i915g).  Could you see if r300g
> passes the test with the patch?
>
> The teximage callback has an internal_format parameter that specifies how the
> pipe texture should be treated.  It can differ from the format of the texture.
> It seems to suffice for TFP.  I was lazy enough not to use it :(
>

That was my first attempt also, however it fails as the texture is
already created, and
in r300g we already have worked out the hw state assuming the texture
format won't
change. This seems to be what gallium expects. So in this case you end
up recreating
a new texture at finalise because the formats don't match and you lose
the pixmap.

Dave.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] ARB draw buffers + texenv program

2010-04-04 Thread Chia-I Wu 
On Sat, Apr 03, 2010 at 01:43:04PM +1000, Dave Airlie wrote:
> Just going down the r300g piglit failures and noticed fbo-drawbuffers
> failed, I've no idea
> if this passes on Intel hw, but it appears the texenvprogram really
> needs to understand the
> draw buffers. The attached patch fixes it here for me on r300g anyone
> want to test this on Intel
> with the piglit test before/after?
i915g has MaxDrawBuffers == 1 and the test is skipped.

-- 
o...@lunarg.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Chia-I Wu 
On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie  wrote:
>> The attached patch fixes tfp test for me (with i915g).  Could you see if 
>> r300g
>> passes the test with the patch?
>> The teximage callback has an internal_format parameter that specifies how the
>> pipe texture should be treated.  It can differ from the format of the 
>> texture.
>> It seems to suffice for TFP.  I was lazy enough not to use it :(
> That was my first attempt also, however it fails as the texture is
> already created, and
> in r300g we already have worked out the hw state assuming the texture
> format won't
> change. This seems to be what gallium expects. So in this case you end
> up recreating
> a new texture at finalise because the formats don't match and you lose
> the pixmap.
r300g does not see the texture before st_finalize_texture, right?  It seems to
me that the patch should give the correct behavior but a (really bad)
unnecessary texture copy in st_finalize_texture.  Could we avoid the copy by
solely changing the sampler view?

-- 
o...@lunarg.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie 
On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu  wrote:
> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie  wrote:
>>> The attached patch fixes tfp test for me (with i915g).  Could you see if 
>>> r300g
>>> passes the test with the patch?
>>> The teximage callback has an internal_format parameter that specifies how 
>>> the
>>> pipe texture should be treated.  It can differ from the format of the 
>>> texture.
>>> It seems to suffice for TFP.  I was lazy enough not to use it :(
>> That was my first attempt also, however it fails as the texture is
>> already created, and
>> in r300g we already have worked out the hw state assuming the texture
>> format won't
>> change. This seems to be what gallium expects. So in this case you end
>> up recreating
>> a new texture at finalise because the formats don't match and you lose
>> the pixmap.
> r300g does not see the texture before st_finalize_texture, right?  It seems to
> me that the patch should give the correct behavior but a (really bad)
> unnecessary texture copy in st_finalize_texture.  Could we avoid the copy by
> solely changing the sampler view?

It sees the texture via
dri_st_framebuffer_validate_att(drawable->stfb,
ST_ATTACHMENT_FRONT_LEFT)
which causes the texture to be creates from the dri2 buffer handle,

The thing is we need the exact buffer object we get from the X server,
we can't copy it to another texture later, as it destroys the shared texture
and just seems to create another private one.

Dave.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev