set max width and max height when building mesa?

@cyrush I dunno what is up with the discussions imported from email. I was having trouble doing even a basic textual search I think should have worked. So, I went back to the actual email mbox archive data and recovered this...
Thu, 13 Aug 2009 15:12:07 -0600
"Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> I added support in build_visit for patching Mesa 7.5 to increase
> the offscreen limit to 16k pixels instead of the default 4096
> width/height limit.

Hrm.  I had thought there was talk of doing this on the Mesa list...
maybe it never made it in.  Anyway, I think there's some interest in
something larger; I'll check with upstream so we don't have to keep
patching.

> Also, we don't have Mesa 7.5 in our thirdparty directory in svn.  Do
> we want it there?

*shrug*.  7.5.1 will be coming soon enough (definitely before 2.0) and
we'll need to upgrade to it for Windows so I think we should upgrade
all around for consistency.

-tom

Thu, 13 Aug 2009 17:19:36 -0400
I sure wouldn't object.  I've never heard of any problems due to increasing it -- and I almost want to say someone had tried something even larger, like 32k or 64k, with no problems.

Maybe we can sneak a 32k limit into 7.5.1 with no one noticing?  ;-)

Of course, I'd really like to just support a multi-pass tiled image save for larger images so that we can work within OpenGL limits (which are sometimes closer to Mesa's 4096), but that's more work.  :-)

--
Jeremy Meredith
Oak Ridge National Laboratory

> -----Original Message-----
> From: tom fogal [mailto:tfogal at alumni.unh.edu]
> Sent: Thursday, August 13, 2009 5:12 PM
> To: visit-developers at email.ornl.gov
> Subject: Re: [visit-developers] [visit-commits] Update to trunk (8124)
> 
> "Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> > I added support in build_visit for patching Mesa 7.5 to increase
> > the offscreen limit to 16k pixels instead of the default 4096
> > width/height limit.
> 
> Hrm.  I had thought there was talk of doing this on the Mesa list...
> maybe it never made it in.  Anyway, I think there's some interest in
> something larger; I'll check with upstream so we don't have to keep
> patching.
> 
> > Also, we don't have Mesa 7.5 in our thirdparty directory in svn.  Do
> > we want it there?
> 
> *shrug*.  7.5.1 will be coming soon enough (definitely before 2.0) and
> we'll need to upgrade to it for Windows so I think we should upgrade
> all around for consistency.
> 
> -tom

Thu, 13 Aug 2009 14:24:12 -0700

Jeremy,

Yes, I think we do want it in our third party directory.

Eric

At 01:50 PM 8/13/2009, Meredith, Jeremy S. wrote:
>Greetings!
>
>I added support in build_visit for patching Mesa 7.5 to increase the 
>offscreen limit to 16k pixels instead of the default 4096 width/height limit.
>
>My apologies for not thinking of this sooner -- you'll have to 
>rebuild Mesa and reconfigure VisIt to pick this up.  You don't have 
>to rebuild VTK, though.  Just rename your old Mesa installation to 
>something like 7.5-4096limit, and run (as someone had suggested before):
>build_visit --thirdparty-path [INSTALLPATH] --no-thirdparty --mesa 
>--svn HEAD --console  --no-visit
>
>Also, we don't have Mesa 7.5 in our thirdparty directory in svn.  Do 
>we want it there?
>
>Changed paths:
>    M /trunk/src/svn_bin/build_visit
>
>--
>Jeremy Meredith
>Oak Ridge National Laboratory

Thu, 13 Aug 2009 15:25:52 -0600
"Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:

> I sure wouldn't object.  I've never heard of any problems due to
> increasing it -- and I almost want to say someone had tried something
> even larger, like 32k or 64k, with no problems.
>
> Maybe we can sneak a 32k limit into 7.5.1 with no one noticing? ;-)

I just begged / recommended / asked if they'd accept a patch which
would allow --with-max-width=blah at config time.

> Of course, I'd really like to just support a multi-pass tiled image
> save for larger images so that we can work within OpenGL limits
> (which are sometimes closer to Mesa's 4096), but that's more work.
> :-)

You might have heard of this "IceT" library once or twice before...
maybe we should integrate that into VisIt.

<g>

-tom

(I know, I know, we're not using the tiling capabilities yet...
someday.)

> > -----Original Message-----
> > From: tom fogal [mailto:tfogal at alumni.unh.edu]
> > Sent: Thursday, August 13, 2009 5:12 PM
> > To: visit-developers at email.ornl.gov
> > Subject: Re: [visit-developers] [visit-commits] Update to trunk (8124)
> > 
> > "Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> > > I added support in build_visit for patching Mesa 7.5 to increase
> > > the offscreen limit to 16k pixels instead of the default 4096
> > > width/height limit.
> > 
> > Hrm.  I had thought there was talk of doing this on the Mesa list...
> > maybe it never made it in.  Anyway, I think there's some interest in
> > something larger; I'll check with upstream so we don't have to keep
> > patching.
> > 
> > > Also, we don't have Mesa 7.5 in our thirdparty directory in svn.  Do
> > > we want it there?
> > 
> > *shrug*.  7.5.1 will be coming soon enough (definitely before 2.0) and
> > we'll need to upgrade to it for Windows so I think we should upgrade
> > all around for consistency.
> > 
> > -tom

Thu, 13 Aug 2009 17:26:25 -0400
Okay, maybe if 7.5.1 is imminent, we'll just remember to do that when it's available.  <nudge nudge>

--
Jeremy Meredith
Oak Ridge National Laboratory

> -----Original Message-----
> From: Eric Brugger [mailto:brugger1 at llnl.gov]
> Sent: Thursday, August 13, 2009 5:24 PM
> To: visit-developers at email.ornl.gov
> Subject: Re: [visit-developers] [visit-commits] Update to trunk (8124)
> 
> 
> Jeremy,
> 
> Yes, I think we do want it in our third party directory.
> 
> Eric
> 
> At 01:50 PM 8/13/2009, Meredith, Jeremy S. wrote:
> >Greetings!
> >
> >I added support in build_visit for patching Mesa 7.5 to increase the
> >offscreen limit to 16k pixels instead of the default 4096 width/height
> limit.
> >
> >My apologies for not thinking of this sooner -- you'll have to
> >rebuild Mesa and reconfigure VisIt to pick this up.  You don't have
> >to rebuild VTK, though.  Just rename your old Mesa installation to
> >something like 7.5-4096limit, and run (as someone had suggested
> before):
> >build_visit --thirdparty-path [INSTALLPATH] --no-thirdparty --mesa
> >--svn HEAD --console  --no-visit
> >
> >Also, we don't have Mesa 7.5 in our thirdparty directory in svn.  Do
> >we want it there?
> >
> >Changed paths:
> >    M /trunk/src/svn_bin/build_visit
> >
> >--
> >Jeremy Meredith
> >Oak Ridge National Laboratory

Thu, 13 Aug 2009 17:27:05 -0400
Yeah, I didn't want to assume too much there.  Dunno how the tiling for large saves fits in with its current place of integration.

--
Jeremy Meredith
Oak Ridge National Laboratory

> -----Original Message-----
> From: tom fogal [mailto:tfogal at alumni.unh.edu]
> Sent: Thursday, August 13, 2009 5:26 PM
> To: VisIt Developers
> Subject: Re: [visit-developers] [visit-commits] Update to trunk (8124)
> 
> "Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> 
> > I sure wouldn't object.  I've never heard of any problems due to
> > increasing it -- and I almost want to say someone had tried something
> > even larger, like 32k or 64k, with no problems.
> >
> > Maybe we can sneak a 32k limit into 7.5.1 with no one noticing? ;-)
> 
> I just begged / recommended / asked if they'd accept a patch which
> would allow --with-max-width=blah at config time.
> 
> > Of course, I'd really like to just support a multi-pass tiled image
> > save for larger images so that we can work within OpenGL limits
> > (which are sometimes closer to Mesa's 4096), but that's more work.
> > :-)
> 
> You might have heard of this "IceT" library once or twice before...
> maybe we should integrate that into VisIt.
> 
> <g>
> 
> -tom
> 
> (I know, I know, we're not using the tiling capabilities yet...
> someday.)
> 
> > > -----Original Message-----
> > > From: tom fogal [mailto:tfogal at alumni.unh.edu]
> > > Sent: Thursday, August 13, 2009 5:12 PM
> > > To: visit-developers at email.ornl.gov
> > > Subject: Re: [visit-developers] [visit-commits] Update to trunk
> (8124)
> > >
> > > "Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> > > > I added support in build_visit for patching Mesa 7.5 to increase
> > > > the offscreen limit to 16k pixels instead of the default 4096
> > > > width/height limit.
> > >
> > > Hrm.  I had thought there was talk of doing this on the Mesa
> list...
> > > maybe it never made it in.  Anyway, I think there's some interest
> in
> > > something larger; I'll check with upstream so we don't have to keep
> > > patching.
> > >
> > > > Also, we don't have Mesa 7.5 in our thirdparty directory in svn.
> Do
> > > > we want it there?
> > >
> > > *shrug*.  7.5.1 will be coming soon enough (definitely before 2.0)
> and
> > > we'll need to upgrade to it for Windows so I think we should
> upgrade
> > > all around for consistency.
> > >
> > > -tom

Thu, 13 Aug 2009 17:06:55 -0600
"Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:

> Okay, maybe if 7.5.1 is imminent, we'll just remember to do that when
> it's available. <nudge nudge>

Okay, i'll remember to do it when the 7.5.1 upgrade comes.  I'm not
quite sure if that qualifies as 'imminent', but certainly it'll be well
before 2.0.

-tom

> > -----Original Message-----
> > From: Eric Brugger [mailto:brugger1 at llnl.gov]
> > Sent: Thursday, August 13, 2009 5:24 PM
> > To: visit-developers at email.ornl.gov
> > Subject: Re: [visit-developers] [visit-commits] Update to trunk (8124)
> > 
> > 
> > Jeremy,
> > 
> > Yes, I think we do want it in our third party directory.
> > 
> > Eric
> > 
> > At 01:50 PM 8/13/2009, Meredith, Jeremy S. wrote:
> > >Greetings!
> > >
> > >I added support in build_visit for patching Mesa 7.5 to increase the
> > >offscreen limit to 16k pixels instead of the default 4096 width/height
> > limit.
> > >
> > >My apologies for not thinking of this sooner -- you'll have to
> > >rebuild Mesa and reconfigure VisIt to pick this up.  You don't have
> > >to rebuild VTK, though.  Just rename your old Mesa installation to
> > >something like 7.5-4096limit, and run (as someone had suggested
> > before):
> > >build_visit --thirdparty-path [INSTALLPATH] --no-thirdparty --mesa
> > >--svn HEAD --console  --no-visit
> > >
> > >Also, we don't have Mesa 7.5 in our thirdparty directory in svn.  Do
> > >we want it there?
> > >
> > >Changed paths:
> > >    M /trunk/src/svn_bin/build_visit
> > >
> > >--
> > >Jeremy Meredith
> > >Oak Ridge National Laboratory

Thu, 13 Aug 2009 17:13:53 -0600
"Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> Yeah, I didn't want to assume too much there.  Dunno how the tiling
> for large saves fits in with its current place of integration.

It doesn't :\

It's been a while since I've looked at it, but IIRC the problem is
actually on the SR side as opposed to an IceT issue.  When we render to
a tile, we of course only have a portion of the image per process.  Yet
downstream image manipulation code assumes it'll have the full image.
So tiles break that assumption, causing features like shadowing, depth
cueing, and mixing VR with other plots to break.

It'd be nice if shadowing/depth cueing was *part* of rendering instead
of an aftereffect.  Volunteers? :)

-tom

> > -----Original Message-----
> > From: tom fogal [mailto:tfogal at alumni.unh.edu]
> > Sent: Thursday, August 13, 2009 5:26 PM
> > To: VisIt Developers
> > Subject: Re: [visit-developers] [visit-commits] Update to trunk (8124)
> > 
> > "Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> > 
> > > I sure wouldn't object.  I've never heard of any problems due to
> > > increasing it -- and I almost want to say someone had tried something
> > > even larger, like 32k or 64k, with no problems.
> > >
> > > Maybe we can sneak a 32k limit into 7.5.1 with no one noticing? ;-)
> > 
> > I just begged / recommended / asked if they'd accept a patch which
> > would allow --with-max-width=blah at config time.
> > 
> > > Of course, I'd really like to just support a multi-pass tiled image
> > > save for larger images so that we can work within OpenGL limits
> > > (which are sometimes closer to Mesa's 4096), but that's more work.
> > > :-)
> > 
> > You might have heard of this "IceT" library once or twice before...
> > maybe we should integrate that into VisIt.
> > 
> > <g>
> > 
> > -tom
> > 
> > (I know, I know, we're not using the tiling capabilities yet...
> > someday.)
> > 
> > > > -----Original Message-----
> > > > From: tom fogal [mailto:tfogal at alumni.unh.edu]
> > > > Sent: Thursday, August 13, 2009 5:12 PM
> > > > To: visit-developers at email.ornl.gov
> > > > Subject: Re: [visit-developers] [visit-commits] Update to trunk
> > (8124)
> > > >
> > > > "Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> > > > > I added support in build_visit for patching Mesa 7.5 to increase
> > > > > the offscreen limit to 16k pixels instead of the default 4096
> > > > > width/height limit.
> > > >
> > > > Hrm.  I had thought there was talk of doing this on the Mesa
> > list...
> > > > maybe it never made it in.  Anyway, I think there's some interest
> > in
> > > > something larger; I'll check with upstream so we don't have to keep
> > > > patching.
> > > >
> > > > > Also, we don't have Mesa 7.5 in our thirdparty directory in svn.
> > Do
> > > > > we want it there?
> > > >
> > > > *shrug*.  7.5.1 will be coming soon enough (definitely before 2.0)
> > and
> > > > we'll need to upgrade to it for Windows so I think we should
> > upgrade
> > > > all around for consistency.
> > > >
> > > > -tom

Fri, 14 Aug 2009 09:57:57 -0400
tom fogal wrote:
> It'd be nice if shadowing/depth cueing was *part* of rendering instead
> of an aftereffect.  Volunteers? :)

While we're on the topic of redesigning rendering, it might be nice if 
the rendering portion were entirely separated out from the data 
manipulation portion.  I/O and data manipulation is a very different job 
from image generating and compositing.  You might want to use a 
different set of resources.

-Sean

__
Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean

Fri, 14 Aug 2009 06:48:29 -0700
Sean, so I thought separating rendering from I/O was kinda what the
viewer/engine were already doing? Am I missing something?

Also, regarding quote of Tom's point. Some aspects of rendering, such as
shadows, depth cueing (fog), reflections (ray tracing) are features of
the WHOLE SCENE itself and not a specific plot in the scene. So, having
shadows/depth cueing on the new 'rendering tab' Hank proposed would not
make as much sense has also having a 'global rendering' tab for SCENE
LEVEL controls.

Mark

On Fri, 2009-08-14 at 06:57, Sean Ahern wrote:
> tom fogal wrote:
> > It'd be nice if shadowing/depth cueing was *part* of rendering instead
> > of an aftereffect.  Volunteers? :)
> 
> While we're on the topic of redesigning rendering, it might be nice if 
> the rendering portion were entirely separated out from the data 
> manipulation portion.  I/O and data manipulation is a very different job 
> from image generating and compositing.  You might want to use a 
> different set of resources.
> 
> -Sean
> 
> __
> Sean Ahern
> Oak Ridge National Laboratory
> AIM: ornlsean
-- 
Mark C. Miller, Lawrence Livermore National Laboratory

Fri, 14 Aug 2009 10:24:46 -0400
Mark Miller wrote:
> Sean, so I thought separating rendering from I/O was kinda what the
> viewer/engine were already doing? Am I missing something?

I'm talking about separating scalable data processing (engine) from 
scalable rendering (also engine).  Separating the display client from 
the data processing portion is the viewer/engine split.

Imagine that you need 1000 engines to scalably read the data and process 
it down to some representation.  It's not necessarily the case that 1000 
processors are the correct architecture to render that data, especially 
given that your rendering target might be a small screen, a tiled 
display, collaborative screens, a single very large anti-aliased image, 
etc.  A better architecture would be to have a set of rendering 
processes to which the data processing engine would communicate the 
data.  Those rendering processes would be configured to use whatever 
resources are best for the rendering job.

VisIt's parallelism architecture is designed to scale the I/O and data 
processing side.  And that's not a bad choice.  But because the two are 
not separated, it means that we are fixed to a single method for 
scalable rendering.

-Sean

__
Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean

Fri, 14 Aug 2009 07:23:58 -0700
My two cents:
I spoke to some PV folks about this a few years ago and they were fairly
negative about this ... grumbling about it only being only good for a
research paper, etc.

So whenever I've heard a mention of this since, I have assumed it is a PR
thing more than a "we really use this" thing.

-h

On Fri, Aug 14, 2009 at 6:57 AM, Sean Ahern <ahern at ornl.gov> wrote:

> tom fogal wrote:
>
>> It'd be nice if shadowing/depth cueing was *part* of rendering instead
>> of an aftereffect.  Volunteers? :)
>>
>
> While we're on the topic of redesigning rendering, it might be nice if the
> rendering portion were entirely separated out from the data manipulation
> portion.  I/O and data manipulation is a very different job from image
> generating and compositing.  You might want to use a different set of
> resources.
>
> -Sean
>
> __
> Sean Ahern
> Oak Ridge National Laboratory
> AIM: ornlsean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://email.ornl.gov/pipermail/visit-developers/attachments/20090814/8844df1b/attachment.html>

Fri, 14 Aug 2009 07:18:13 -0700
Ok, I follow.

Some of the concepts from parallelization in time might be applicable in
the case you describe.

You could imagine a system with 10,000 cpus and 1,000 of which have GPU
co-processors. So, the engine lives on all 10,000 and there is one MPI
comm for the I/O and pipeline execute for that. But, then data is
gathered to the 1000 GPU-enabled cpus for the rendering part.

Brad and I spent a little time thinking about how to divy up N
processors in the engine into K smaller MPI comms, one for each
timestep. That would be somewhat similar to divying up for I/O and
rendering.

Neat idea though.

Mark

On Fri, 2009-08-14 at 07:24, Sean Ahern wrote:
> Mark Miller wrote:
> > Sean, so I thought separating rendering from I/O was kinda what the
> > viewer/engine were already doing? Am I missing something?
> 
> I'm talking about separating scalable data processing (engine) from 
> scalable rendering (also engine).  Separating the display client from 
> the data processing portion is the viewer/engine split.
> 
> Imagine that you need 1000 engines to scalably read the data and process 
> it down to some representation.  It's not necessarily the case that 1000 
> processors are the correct architecture to render that data, especially 
> given that your rendering target might be a small screen, a tiled 
> display, collaborative screens, a single very large anti-aliased image, 
> etc.  A better architecture would be to have a set of rendering 
> processes to which the data processing engine would communicate the 
> data.  Those rendering processes would be configured to use whatever 
> resources are best for the rendering job.
> 
> VisIt's parallelism architecture is designed to scale the I/O and data 
> processing side.  And that's not a bad choice.  But because the two are 
> not separated, it means that we are fixed to a single method for 
> scalable rendering.
> 
> -Sean
> 
> __
> Sean Ahern
> Oak Ridge National Laboratory
> AIM: ornlsean
-- 
Mark C. Miller, Lawrence Livermore National Laboratory

Fri, 14 Aug 2009 10:58:56 -0400
Hank Childs wrote:
> I spoke to some PV folks about this a few years ago and they were fairly 
> negative about this ... grumbling about it only being only good for a 
> research paper, etc.
> 
> So whenever I've heard a mention of this since, I have assumed it is a 
> PR thing more than a "we really use this" thing.

Interesting.  Was the grumbling about the concept, or the PV 
implementation?  Because I think the concept is a sound one, but could 
easily be implemented badly.

As a counter point, the EnSight DR rendering infrastructure uses this 
same method, and they've been reporting good success with it.  Maybe I 
should bend Randy and Dan's ear next time I see them.

-Sean

__
Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean

Fri, 14 Aug 2009 11:00:11 -0400
Mark Miller wrote:
> Some of the concepts from parallelization in time might be applicable in
> the case you describe.
> 
> You could imagine a system with 10,000 cpus and 1,000 of which have GPU
> co-processors. So, the engine lives on all 10,000 and there is one MPI
> comm for the I/O and pipeline execute for that. But, then data is
> gathered to the 1000 GPU-enabled cpus for the rendering part.

That's one of the use cases I'm thinking of.  We already run into that. 
  My vis cluster at ORNL has 16 cores per node, but only 2 GPUs.  To do 
hardware rendering, I can only run 2 engines per node.  I would love to 
be able to separate the two.

> Brad and I spent a little time thinking about how to divy up N
> processors in the engine into K smaller MPI comms, one for each
> timestep. That would be somewhat similar to divying up for I/O and
> rendering.
> 
> Neat idea though.

-Sean

__
Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean

Fri, 14 Aug 2009 08:04:36 -0700
On Fri, Aug 14, 2009 at 7:58 AM, Sean Ahern <ahern at ornl.gov> wrote:

> Hank Childs wrote:
>
>> I spoke to some PV folks about this a few years ago and they were fairly
>> negative about this ... grumbling about it only being only good for a
>> research paper, etc.
>>
>> So whenever I've heard a mention of this since, I have assumed it is a PR
>> thing more than a "we really use this" thing.
>>
>
> Interesting.  Was the grumbling about the concept, or the PV
> implementation?  Because I think the concept is a sound one, but could
> easily be implemented badly.

I don't think the gripes were about the PV implementation ... just that
vanilla SR on the compute engine was sufficient and the rest wasn't solving
a real problem.

>
> As a counter point, the EnSight DR rendering infrastructure uses this same
> method, and they've been reporting good success with it.  Maybe I should
> bend Randy and Dan's ear next time I see them.

I have to admit that I very jaded when people tell me how great their tools
are, regardless of context or source.  No knock on Randy, who we all like.
 (And no implied slight on Dan, who I've never met.)

-h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://email.ornl.gov/pipermail/visit-developers/attachments/20090814/92fc1807/attachment.html>

Fri, 14 Aug 2009 11:08:03 -0400
Hank Childs wrote:
> I don't think the gripes were about the PV implementation ... just that 
> vanilla SR on the compute engine was sufficient and the rest wasn't 
> solving a real problem.

I will admit that separating rendering probably targets a <50% use case. 
  SR on the engine is sufficient for a large portion of what people do.

> I have to admit that I very jaded when people tell me how great their 
> tools are, regardless of context or source.  No knock on Randy, who we 
> all like.  (And no implied slight on Dan, who I've never met.)

-Sean

__
Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean

Fri, 14 Aug 2009 10:42:29 -0600
Sean Ahern <ahern at ornl.gov> writes:
> Mark Miller wrote:

> > Some of the concepts from parallelization in time might be
> > applicable in the case you describe.
> >
> > You could imagine a system with 10,000 cpus and 1,000 of which have
> > GPU co-processors. So, the engine lives on all 10,000 and there is
> > one MPI comm for the I/O and pipeline execute for that. But, then
> > data is gathered to the 1000 GPU-enabled cpus for the rendering
> > part.

I had an enlightening conversation with Claudio Silva here about this
once.  Many years back now, he wrote a paper demonstrating that the
number of nodes used in compositing should generally be fewer than
those used in rendering, plus a method to generate/figure out those
compositing nodes.

> That's one of the use cases I'm thinking of.  We already run into
> that.  My vis cluster at ORNL has 16 cores per node, but only 2 GPUs.
> To do hardware rendering, I can only run 2 engines per node.  I would
> love to be able to separate the two.

That hasn't been true since August 2008, Sean!  Use '-n-gpus-per-node 2
-hw-accel'.  My test platform for all of that *was* lens ;)

The caveats are that in released versions of VisIt can't use OGL 2.0+
features.  So, plots like the volume and molecule will crash in that
mode.  That's all fixed with my recent tuvok merge, due to all the GLEW
changes, but of course that's trunk-only.  Secondly, you're forced to
render on the non-GPU processes, even if that doesn't make much sense.

I'll also throw out: while I have some serious doubts that rendering on
the non-GPU processes makes sense, this is technically still an open
question.  It's something I (+ others) am likely to answer within the
next month.

> > Brad and I spent a little time thinking about how to divy up N
> > processors in the engine into K smaller MPI comms, one for each
> > timestep. That would be somewhat similar to divying up for I/O and
> > rendering.
> >
> > Neat idea though.

It would be pretty easy to *create* the "Render-comm" in
Engine::SetupDisplay (if I'm remembering the method name correctly).
Actually using it would be a different story, of course...

-tom

Fri, 14 Aug 2009 12:49:05 -0400
tom fogal wrote:
> I had an enlightening conversation with Claudio Silva here about this
> once.  Many years back now, he wrote a paper demonstrating that the
> number of nodes used in compositing should generally be fewer than
> those used in rendering, plus a method to generate/figure out those
> compositing nodes.

Interesting.

> That hasn't been true since August 2008, Sean!  Use '-n-gpus-per-node 2
> -hw-accel'.  My test platform for all of that *was* lens ;)

Yes, I know, Tom.  You and I worked that out!  But I'm not talking about 
hybrid hw/sw routes, I'm talking about separating rendering into a 
different architecture.  The stuff you did was great!  I want to go even 
further.  Remember, this thread was spawned by someone's comment that 
they wanted to do multi-tile rendering, something we can't do right now. 
  That's a use case that separating data processing from rendering would 
enable.

-Sean

__
Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean

Fri, 14 Aug 2009 11:44:59 -0600
tom fogal <tfogal at alumni.unh.edu> writes:
> "Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> 
> > I sure wouldn't object.  I've never heard of any problems due
> > to increasing it -- and I almost want to say someone had tried
> > something even larger, like 32k or 64k, with no problems.
> >
> > Maybe we can sneak a 32k limit into 7.5.1 with no one noticing? ;-)
>
> I just begged / recommended / asked if they'd accept a patch which
> would allow --with-max-width=blah at config time.

Mesa 7.5.1 will now support --with-max-width and --with-max-height
configure options.  That said, raising the numbers above 4k^2 *does*
have a negative impact on rasterization accuracy.  I've appended a
quote of the comment I was referred to below.

-tom

>From ./src/mesa/swrast/s_tritemp.h:

 * Some notes on rasterization accuracy:
 *
 * This code uses fixed point arithmetic (the GLfixed type) to iterate
 * over the triangle edges and interpolate ancillary data (such as Z,
 * color, secondary color, etc).  The number of fractional bits in
 * GLfixed and the value of SUB_PIXEL_BITS has a direct bearing on the
 * accuracy of rasterization.
 *
 * If SUB_PIXEL_BITS=4 then we'll snap the vertices to the nearest
 * 1/16 of a pixel.  If we're walking up a long, nearly vertical edge
 * (dx=1/16, dy=1024) we'll need 4 + 10 = 14 fractional bits in
 * GLfixed to walk the edge without error.  If the maximum viewport
 * height is 4K pixels, then we'll need 4 + 12 = 16 fractional bits.
 *
 * Historically, Mesa has used 11 fractional bits in GLfixed, snaps
 * vertices to 1/16 pixel and allowed a maximum viewport height of 2K
 * pixels.  11 fractional bits is actually insufficient for accurately
 * rasterizing some triangles.  More recently, the maximum viewport
 * height was increased to 4K pixels.  Thus, Mesa should be using 16
 * fractional bits in GLfixed.  Unfortunately, there may be some issues
 * with setting FIXED_FRAC_BITS=16, such as multiplication overflow.
 * This will have to be examined in some detail...
 *
 * For now, if you find rasterization errors, particularly with tall,
 * sliver triangles, try increasing FIXED_FRAC_BITS and/or decreasing
 * SUB_PIXEL_BITS.

Fri, 14 Aug 2009 13:49:46 -0400
Just to clarify, it sounds like this will only impact you if you actually create an image (or polygon, specifically) that large -- from that description defining that MAX_WIDTH/HEIGHT number to a larger value doesn't seem like it would cause accuracy problems by itself.

(Oh, and great, that's awesome news!)

--
Jeremy Meredith
Oak Ridge National Laboratory

> -----Original Message-----
> From: tom fogal [mailto:tfogal at alumni.unh.edu]
> Sent: Friday, August 14, 2009 1:45 PM
> To: VisIt Developers
> Subject: Re: [visit-developers] [visit-commits] Update to trunk (8124)
> 
> tom fogal <tfogal at alumni.unh.edu> writes:
> > "Meredith, Jeremy S." <jsmeredith at ornl.gov> writes:
> >
> > > I sure wouldn't object.  I've never heard of any problems due
> > > to increasing it -- and I almost want to say someone had tried
> > > something even larger, like 32k or 64k, with no problems.
> > >
> > > Maybe we can sneak a 32k limit into 7.5.1 with no one noticing? ;-)
> >
> > I just begged / recommended / asked if they'd accept a patch which
> > would allow --with-max-width=blah at config time.
> 
> Mesa 7.5.1 will now support --with-max-width and --with-max-height
> configure options.  That said, raising the numbers above 4k^2 *does*
> have a negative impact on rasterization accuracy.  I've appended a
> quote of the comment I was referred to below.
> 
> -tom
> 
> >From ./src/mesa/swrast/s_tritemp.h:
> 
>  * Some notes on rasterization accuracy:
>  *
>  * This code uses fixed point arithmetic (the GLfixed type) to iterate
>  * over the triangle edges and interpolate ancillary data (such as Z,
>  * color, secondary color, etc).  The number of fractional bits in
>  * GLfixed and the value of SUB_PIXEL_BITS has a direct bearing on the
>  * accuracy of rasterization.
>  *
>  * If SUB_PIXEL_BITS=4 then we'll snap the vertices to the nearest
>  * 1/16 of a pixel.  If we're walking up a long, nearly vertical edge
>  * (dx=1/16, dy=1024) we'll need 4 + 10 = 14 fractional bits in
>  * GLfixed to walk the edge without error.  If the maximum viewport
>  * height is 4K pixels, then we'll need 4 + 12 = 16 fractional bits.
>  *
>  * Historically, Mesa has used 11 fractional bits in GLfixed, snaps
>  * vertices to 1/16 pixel and allowed a maximum viewport height of 2K
>  * pixels.  11 fractional bits is actually insufficient for accurately
>  * rasterizing some triangles.  More recently, the maximum viewport
>  * height was increased to 4K pixels.  Thus, Mesa should be using 16
>  * fractional bits in GLfixed.  Unfortunately, there may be some issues
>  * with setting FIXED_FRAC_BITS=16, such as multiplication overflow.
>  * This will have to be examined in some detail...
>  *
>  * For now, if you find rasterization errors, particularly with tall,
>  * sliver triangles, try increasing FIXED_FRAC_BITS and/or decreasing
>  * SUB_PIXEL_BITS.

Fri, 14 Aug 2009 13:54:57 -0400
Meredith, Jeremy S. wrote:
> Just to clarify, it sounds like this will only impact you if you
> actually create an image (or polygon, specifically) that large --
> from that description defining that MAX_WIDTH/HEIGHT number to a
> larger value doesn't seem like it would cause accuracy problems by
> itself.

That's also the way I read it.  It also sounds like the errors really 
are limited to precision.  So you might get a rasterized edge or line 
that's not reproducible.  You shouldn't get truly bad geometry.  As 
failure modes go, that's a niggling one that we shouldn't have to worry 
about.

> (Oh, and great, that's awesome news!)

Definitely.

-Sean

__
Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean

Fri, 14 Aug 2009 14:05:36 -0400
Just speculating, I think it might actually cause a problem with (brace yourself, terminology overload coming) "perfect meshing".  I.e. adjacent polygons might have single-pixel holes because their edge steppings aren't being rasterized the same from both the left- and right-adjacent polygons.  Again, if it's really restricted to big images, though, I'm not concerned.

As for the configure-time option, we need to remember to change build_visit to remove the patching I added when we move to 7.5.1, then.

--
Jeremy Meredith
Oak Ridge National Laboratory

> -----Original Message-----
> From: Sean Ahern [mailto:ahern at ornl.gov]
> Sent: Friday, August 14, 2009 1:55 PM
> To: VisIt Developers
> Subject: Re: [visit-developers] [visit-commits] Update to trunk (8124)
> 
> Meredith, Jeremy S. wrote:
> > Just to clarify, it sounds like this will only impact you if you
> > actually create an image (or polygon, specifically) that large --
> > from that description defining that MAX_WIDTH/HEIGHT number to a
> > larger value doesn't seem like it would cause accuracy problems by
> > itself.
> 
> That's also the way I read it.  It also sounds like the errors really
> are limited to precision.  So you might get a rasterized edge or line
> that's not reproducible.  You shouldn't get truly bad geometry.  As
> failure modes go, that's a niggling one that we shouldn't have to worry
> about.
> 
> > (Oh, and great, that's awesome news!)
> 
> Definitely.
> 
> -Sean
> 
> __
> Sean Ahern
> Oak Ridge National Laboratory
> AIM: ornlsean

Fri, 14 Aug 2009 14:07:54 -0400
Meredith, Jeremy S. wrote:
> Just speculating, I think it might actually cause a problem with
> (brace yourself, terminology overload coming) "perfect meshing".
> I.e. adjacent polygons might have single-pixel holes because their
> edge steppings aren't being rasterized the same from both the left-
> and right-adjacent polygons.  Again, if it's really restricted to big
> images, though, I'm not concerned.

Yeah, okay, that sounds familiar.  And I'm also not that worried.

> As for the configure-time option, we need to remember to change
> build_visit to remove the patching I added when we move to 7.5.1,
> then.

-Sean

__
Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean
visit-dav / visit

set max width and max height when building mesa? #19430

Describe the bug

To Reproduce

Expected behavior

Desktop
