[Bug 29276] [r300g][regression] 0ad game no longer starts

https://bugs.freedesktop.org/show_bug.cgi?id=29276

--- Comment #4 from Marek Olšák <maraeo <at> gmail.com> 2010-07-31 21:51:19 PDT ---
Make sure you have both the driver and libGL*.so from git properly installed,
and please let me know if you still have problems even with latest libGL*.so.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Bug 29337] New: glsl2: GLSL compiler errors with most piglit tests

https://bugs.freedesktop.org/show_bug.cgi?id=29337

           Summary: glsl2: GLSL compiler errors with most piglit tests
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mesa-dev <at> lists.freedesktop.org
        ReportedBy: tstellar <at> gmail.com

Created an attachment (id=37494)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37494)
Valgrind output for glsl-fs-exp piglit test.

Most of the piglit tests I try with the glsl2 branch fail with this error (some
have more than just this one):

Failed to compile FS: 0:2(10): error: function `main' return type has
qualifiers

The full piglit results are here:
http://ix.cs.uoregon.edu/~tstellar/piglit/glsl2/

I've observed this behavior on two different machines, both of which run
Gentoo.  It seems like it might be a memory bug, I've attached the valgrind
output from one of the tests.   This test passes when run with valgrind, but

[Bug 29337] glsl2: GLSL compiler errors with most piglit tests

https://bugs.freedesktop.org/show_bug.cgi?id=29337

--- Comment #1 from Tom Stellard <tstellar <at> gmail.com> 2010-07-31 22:49:15 PDT ---
Created an attachment (id=37495)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=37495)
config.log from my mesa build

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: gallium bound checking patch broke r600g in weird way

On Sat, Jul 31, 2010 at 7:10 AM, Zack Rusin <zackr <at> vmware.com> wrote:
> On Friday 30 July 2010 17:51:21 Jakob Bornecrantz wrote:
>> On 30 jul 2010, at 14.02, Jakob Bornecrantz wrote:
>> > On 30 jul 2010, at 13.32, Brian Paul wrote:
>> >> On 07/30/2010 12:38 PM, Jerome Glisse wrote:
>> >>> Hi Brian,
>> >>>
>> >>> I am facing a strange segfault with r600g on top of lastest git,
>> >>> git bisect pointed to gallium: implement bounds checking for
>> >>> constant buffers
>> >>> My feeling is that it should only affect software pipeline but
>> >>> somehow r600g seem to take different path now, attached if full
>> >>> but i can't make much sense out of it, do you have a clue on what
>> >>> might went wrong ?
>> >>
>> >> I took a quick look but didn't find anything.
>> >>
>> >> Maybe try a make clean and rebuild just in case?
>> >
>> > I'm getting the same with swrastg on in 32bit VM, "git clean -fdx":ed
>> > even.
>>
>> Me and Jerome tracked it down to the SSE code generated by the tgsi
>> runtime. Exporting GALLIUM_NOSSE avoids the bug. I'm guessing you are
>> either using LLVM or 64bit which doesn't have SSE codegen.
I am having this warning

  draw/draw_vs_sse.c: In function ‘draw_create_vs_sse’:
  draw/draw_vs_sse.c:172: warning: assignment from incompatible pointer type

Re: opencl (clover) patches question

On Friday 30 July 2010 14:13:06 Jorge Villaseñor wrote:
> Is there some public roadmap to get this working? somewhere we can
> start hacking?  As Anthony I'm a newcomer and I'm looking for getting
> OpenCL/clover up.

Not right now, I'll try to start something on the fdo wiki within the next few 
days.
_______________________________________________
mesa-dev mailing list
mesa-dev <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: opencl (clover) patches question

On Monday 26 July 2010 03:48:31 Jonathan Hamilton wrote:
> Hi,
> I have been looking into what would be needed to modify in clang to
> support opencl recently, although there is an opencl flag to set in the
> lang options, it doesn't really seem to do much, so the modifications
> seem non-trivial (to me at least). 

I think you're over-thinking it. I guess what you're referring is support for 
things like floatX (e.g. float4), __local and so on, but those aren't part of 
the language itself, they're actually simple defines. So what we need  is a 
private header which defines the OpenCL C types and attributes. E.g.
typedef __attribute__(( ext_vertex_type(4) )) float float4;
typedef __attribute__(( ext_vertex_type(2) )) float float2;
and so on. Each compiled OpenCL kernel would implicitly include this header. 
We'll need pretty much the same thing for builtins (but along with actual 
definitions of those).

> Also, am I correct in assuming that the general flow goes:
> openCL code -> clang -> llvm bytecode -> TGSI -> gallium driver?

That's exactly right.

z

[Bug 29344] New: Long urls in chromium causes X to close when I use compositing window manager.

https://bugs.freedesktop.org/show_bug.cgi?id=29344

           Summary: Long urls in chromium causes X to close when I use
                    compositing window manager.
           Product: Mesa
           Version: unspecified
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: GLX
        AssignedTo: mesa-dev <at> lists.freedesktop.org
        ReportedBy: bay <at> hackerdom.ru

I file this bug in chromium bugzilla.
http://code.google.com/p/chromium/issues/detail?id=50881&can=5&colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS

In short: when I open long URL in chromium the X server hangs.
I have mesa 7.8.2 installed and intel drivers for videocard.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x495c20]
1: /usr/bin/X (0x400000+0x5d606) [0x45d606]
2: /lib/libpthread.so.0 (0x7f2d9766b000+0xf110) [0x7f2d9767a110]
3: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f2d95495000+0x384a8)
[0x7f2d954cd4a8] (in dri2GetBuffersWithFormat, file glxdri2.c, in cycle)
4: /usr/lib64/dri/i965_dri.so (0x7f2d93eb4000+0x2091d) [0x7f2d93ed491d] (in
intel_update_renderbuffers, file intelcontex.c, line 270)
5: /usr/lib64/dri/i965_dri.so (0x7f2d93eb4000+0x3123d) [0x7f2d93ee523d] (in

Re: talloc (Was: Merge criteria for glsl2 branch)

On Tue, 27 Jul 2010 21:32:57 +0100, José Fonseca <jfonseca <at> vmware.com> wrote:
> 
> On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote:
> > As everyone knows, a group of us at Intel have been rewriting Mesa's
> > GLSL compiler.  The work started out-of-tree as a stand alone compiler.
> >  We moved all of our work to the glsl2 branch in the Mesa tree as soon
> > as we had some actual code being generated.  This was about month ago.
> > Since that time we have implemented quite a bit more code generation and
> > a complete linker.  The compiler is not done, but it gets closer every day.
> > 
> > I think now is the time to start discussing merge criteria.  It is well
> > known that the Intel graphics team favors quarterly releases.  In order
> > to align with other people's release schedules, we'd really like to have
> > the new compiler in a Mesa release at the end of Q3 (end of September /
> > beginning of October).  That's just over two months from now.  In order
> > to have a credible release, the compiler needs to be merged to master
> > before then.  A reasonable estimate puts the end of August as the latest
> > possible merge time.  Given how far the compiler has come in the last
> > month, I have a lot of faith in being able to hit that target.
> > 
> > We have developed our own set of merge requirements, and these are
> > listed below.  Since this is such a large subsystem, we want to solicit
> > input from the other stakeholders.
> > 
> >  * No piglit regressions, except draw_buffers-05.vert, compared to
> >     master in swrast, i965, or i915.
> > 
> >  * Any failing tests do not crash (segfault, assertion failure, etc.).
> > 
> > draw_buffers-05.vert is specifically excluded because I'm not sure the

Re: [PATCH] mesa: increase the relative address offset limit to 4096 in ARB_vp/fp

On Sat, 31 Jul 2010 20:32:29 +0200, Marek Olšák <maraeo <at> gmail.com> wrote:
> Also program_parse.tab.c has been regenerated.
> 
> This fixes the parser error:
> 
>   ARB_vp: error: relative address offset too large
> 
> See also: https://bugs.freedesktop.org/show_bug.cgi?id=28628
> 
> 4096 * sizeof(vec4) is the maximum size of the constant buffer on NV50,
> so it is a reasonable limit, at least for now.
> (should there be any limit at all?)
> 
> Piglit: vp-arl-constant-array-huge-relative-offset

The limit comes from:

    (26) What limits should be imposed on the constants that can be added to
    or subtracted from the address register for relative addressing?  Negative
    offsets are sometimes useful for shifting down in an array.

      RESOLVED:  -64 to +63 should be sufficient for the time being.  Offset
      sizes are limited to allow offsets to be baked into device-dependent
      instruction encodings.

so wine is really being nonportable here and should handle it itself,
but I'm fine with just removing the limits in the core and letting the
drivers complain if they can't be supported.  4096 doesn't make sense as
a limit, as constant buffer size limits should already be expressed
through MAX_PROGRAM_PARAMETERS_ARB.

Re: [PATCH] mesa: increase the relative address offset limit to 4096 in ARB_vp/fp

On Sat, 2010-07-31 at 20:32 +0200, Marek Olšák wrote:
> Also program_parse.tab.c has been regenerated.
> 
> This fixes the parser error:
> 
>   ARB_vp: error: relative address offset too large
> 
> See also: https://bugs.freedesktop.org/show_bug.cgi?id=28628
> 
> 4096 * sizeof(vec4) is the maximum size of the constant buffer on NV50,
> so it is a reasonable limit, at least for now.
> (should there be any limit at all?)

Sorry about butting in, but is this the same issue that's tracked here?
https://bugs.freedesktop.org/show_bug.cgi?id=23975

--

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22

_______________________________________________
mesa-dev mailing list
mesa-dev <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev