headers
bugzilla-daemon | 1 Nov 2007 01:02

[Bug 12906] reproducible crash in _mesa_set_viewport

http://bugs.freedesktop.org/show_bug.cgi?id=12906

------- Comment #10 from brian.paul <at> tungstengraphics.com  2007-10-31 17:07 PST -------
Could you try the Mesa 7.0.2 release candidate at www.mesa3d.org/beta/ ?

I made some changes in the oldCtx/_mesa_unreference_framebuffer() code a while
back that may fix this.

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Permalink | Reply | 0 comments |
headers
Ian Romanick | 1 Nov 2007 01:18
Picon
Favicon

Softpipe processing of quads


I've been digging through the softpipe code in gallium for the past few
days.  I think I'm starting to "get it".  I do have one question about
the way quads are processed.

It looks like the triangle setup code produces a row of quads and passes
them off, one at a time, to the fragment shader.  The fragment shader
then does the attribute interpolation and passes the fragments to the
real shader.  Is that correct?

It seems like instead we'd want the setup code to produce large groups
of quads with all of attributes pre-interpolated.  Each quad would be
tagged with some ordering information.  The shader code could then
process quads however it wanted as longs as the tagged ordering
information was respected.  This would allow a few things:

1. Group quad processing to better use the tile cache.

2. Trivially distribute quad processing to multiple CPU cores (not just
on Cell, either).

3. If the shader doesn't modify Z values, early Z culling could be
performed.

I don't see any easy way to achieve this with the current code.  Am I
missing something, or is this a place where I could jump in and help?
Permalink | Reply | 2 comments |
headers
Brian Paul | 1 Nov 2007 01:49

Re: Softpipe processing of quads

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've been digging through the softpipe code in gallium for the past few
> days.  I think I'm starting to "get it".  I do have one question about
> the way quads are processed.
> 
> It looks like the triangle setup code produces a row of quads and passes
> them off, one at a time, to the fragment shader.  The fragment shader
> then does the attribute interpolation and passes the fragments to the
> real shader.  Is that correct?
> 
> It seems like instead we'd want the setup code to produce large groups
> of quads with all of attributes pre-interpolated.  Each quad would be
> tagged with some ordering information.  The shader code could then
> process quads however it wanted as longs as the tagged ordering
> information was respected.  This would allow a few things:
> 
> 1. Group quad processing to better use the tile cache.
> 
> 2. Trivially distribute quad processing to multiple CPU cores (not just
> on Cell, either).
> 
> 3. If the shader doesn't modify Z values, early Z culling could be
> performed.
> 
> I don't see any easy way to achieve this with the current code.  Am I
> missing something, or is this a place where I could jump in and help?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zou, Nanhai | 1 Nov 2007 02:18
Picon
Favicon

Re: i965 glsl support


> -----Original Message-----
> From: Brian Paul [mailto:brian.paul <at> tungstengraphics.com]
> Sent: 2007年10月31日 23:55
> To: Zou, Nanhai
> Cc: Nan hai Zou; MESA-Devel
> Subject: Re: i965 glsl support
> 
> Zou Nan hai wrote:
> > On Mon, 2007-10-29 at 23:58, Brian Paul wrote:
> >> Nan hai Zou wrote:
> >>
> >> [... git check-in info ...]
> >>
> >> Nan,
> >>
> >> Since you've merged the i965 GLSL support into Mesa/master, can you
> >> summarize what state it's in?  Is it fully functional, or are there some
> >> unfinished bits?
> >>
> >> In any case, it's great to have this!
> >>
> >> I've found one problem, however.  In shader/program.c in
> >> _mesa_new_shader() you added a call to ctx->Driver.NewProgram():
> >>
> >> struct gl_program *
> >> _mesa_new_program(GLcontext *ctx, GLenum target, GLuint id)
> >> {
> >>     if (ctx->Driver.NewProgram)
> >>          return ctx->Driver.NewProgram(ctx, target, id);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Paul | 1 Nov 2007 02:30

Re: i965 glsl support

On 10/31/07, Zou, Nanhai <nanhai.zou <at> intel.com> wrote:
>
>
> > -----Original Message-----
> > From: Brian Paul [mailto:brian.paul <at> tungstengraphics.com]
> > Sent: 2007年10月31日 23:55
> > To: Zou, Nanhai
> > Cc: Nan hai Zou; MESA-Devel
> > Subject: Re: i965 glsl support
> >
> > Zou Nan hai wrote:
> > > On Mon, 2007-10-29 at 23:58, Brian Paul wrote:
> > >> Nan hai Zou wrote:
> > >>
> > >> [... git check-in info ...]
> > >>
> > >> Nan,
> > >>
> > >> Since you've merged the i965 GLSL support into Mesa/master, can you
> > >> summarize what state it's in?  Is it fully functional, or are there some
> > >> unfinished bits?
> > >>
> > >> In any case, it's great to have this!
> > >>
> > >> I've found one problem, however.  In shader/program.c in
> > >> _mesa_new_shader() you added a call to ctx->Driver.NewProgram():
> > >>
> > >> struct gl_program *
> > >> _mesa_new_program(GLcontext *ctx, GLenum target, GLuint id)
> > >> {
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Nov 2007 02:37

[Bug 12906] reproducible crash in _mesa_set_viewport

http://bugs.freedesktop.org/show_bug.cgi?id=12906

------- Comment #11 from myself <at> rojer.pp.ru  2007-10-31 18:42 PST -------
yes, i recompiled xorg-server with MesaLib-7.0.2-rc1 and it fixed the crash.
thanks a lot, Brian!

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Nov 2007 02:48

[Bug 12906] reproducible crash in _mesa_set_viewport

http://bugs.freedesktop.org/show_bug.cgi?id=12906

------- Comment #12 from myself <at> rojer.pp.ru  2007-10-31 18:53 PST -------
oh, but please have a look at the double fault bug as well (segfault in the
XkbEnableDisableControls in the SIGSEGV handler path).

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Nov 2007 02:56

[Bug 12935] ProgramEnvParameter4xyARB does not alias ProgramParameter4xyNV

http://bugs.freedesktop.org/show_bug.cgi?id=12935

------- Comment #2 from sroland <at> tungstengraphics.com  2007-10-31 19:01 PST -------
Created an attachment (id=12282)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=12282&action=view)
patch to alias ProgramEnvParameter4xyARB and ProgramParameter4xyNV

Here's a quick stab at the problem (obviously not including all the files which
need to be recreated).
I think it might break NV_vertex_program, because I thought I should make
ProgramParameter4xyNV an alias to ProgramEnvParameter4xyARB in gl_API.xml but
that didn't work (the scripts didn't generate the non-vectorized versions in
this case for the glx code).

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Nov 2007 06:40

[Bug 13033] [i965 64bit]Mesa demo case arbocclude failed

http://bugs.freedesktop.org/show_bug.cgi?id=13033

gordon.jin <at> intel.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mesa3d-
                   |                            |dev <at> lists.sourceforge.net
         AssignedTo|nanhai.zou <at> intel.com        |haihao.xiang <at> intel.com

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Permalink | Reply | 0 comments |
headers
Keith Whitwell | 1 Nov 2007 09:11

Re: Softpipe processing of quads

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've been digging through the softpipe code in gallium for the past few
> days.  I think I'm starting to "get it".  I do have one question about
> the way quads are processed.
> 
> It looks like the triangle setup code produces a row of quads and passes
> them off, one at a time, to the fragment shader.  The fragment shader
> then does the attribute interpolation and passes the fragments to the
> real shader.  Is that correct?

Yes.

> It seems like instead we'd want the setup code to produce large groups
> of quads with all of attributes pre-interpolated.  Each quad would be
> tagged with some ordering information.  The shader code could then
> process quads however it wanted as longs as the tagged ordering
> information was respected.  This would allow a few things:

Yes of course.  Softpipe is not an optimized rasterizer...  We're 
figuring things out at this point.

> 1. Group quad processing to better use the tile cache.
> 
> 2. Trivially distribute quad processing to multiple CPU cores (not just
> on Cell, either).
> 
> 3. If the shader doesn't modify Z values, early Z culling could be
(Continue reading)

Permalink | Reply | 0 comments |

Gmane