headers
Francisco Jerez | 1 Mar 2010 03:25

Re: [PATCH] Nouveau_vieux "fixes"

randrianasulu <at> gmail.com writes:

> Hello all!
>
> After unsuccesfull battle with git-send-email I just  send these two patches  from Kmail. Botch as
attachments and inlin, but inline 
> version probably will be damaged in process.....
>
Thanks, both patches pushed (after some minor reformatting: please, use
git-format-patch next time).

> Patch 1: add XRGB8888 into nouveau_fbo.c, makes xmoto actually display its demo, not abort
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> index 1db8c5d..8464786 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
>  <at>  <at>  -215,6 +215,8  <at>  <at>  get_tex_format(struct gl_texture_image *ti)
>         switch (ti->TexFormat) {
>         case MESA_FORMAT_ARGB8888:
>                 return GL_RGBA8;
> +       case MESA_FORMAT_XRGB8888:
> +               return GL_RGB8;
>         case MESA_FORMAT_RGB565:
>                 return GL_RGB5;
>         default:
>
>
> Patch 2: add two stencil operation cases in nv04_state_raster.c, allow demos/reflect and
demos/dinoshade actually work. Dinoshade
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joakim Sindholt | 1 Mar 2010 03:43

Re: Gallium software fallback/draw command failure

On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
> Hi,
> 
> I am a bit puzzled, how a pipe driver should handle
> draw callback failure ? On radeon (pretty sure nouveau
> or intel hit the same issue) we can only know when one
> of the draw_* context callback is call if we can do
> the rendering or not.
> 
> The failure here is dictated by memory constraint, ie
> if user bind big texture, big vbo ... we might not have
> enough GPU address space to bind all the desired object
> (even for drawing a single triangle) ?
> 
> What should we do ? None of the draw callback can return
> a value ? Maybe for a GL stack tracker we should report
> GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
> is i think pipe driver are missing something here. Any
> idea ? Thought ? Is there already a plan to address that ? :)
> 
> Cheers,
> Jerome

I think a vital point you're missing is: do we even care? If rendering
fails because we simply can't render any more, do we even want to fall
back? I can see a point in having a cap on how large a buffer can be
rendered but apart from that, I'm not sure there even is a problem.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Airlie | 1 Mar 2010 06:15
Picon
Gravatar

Re: Gallium software fallback/draw command failure

On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt <bacn <at> zhasha.com> wrote:
> On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
>> Hi,
>>
>> I am a bit puzzled, how a pipe driver should handle
>> draw callback failure ? On radeon (pretty sure nouveau
>> or intel hit the same issue) we can only know when one
>> of the draw_* context callback is call if we can do
>> the rendering or not.
>>
>> The failure here is dictated by memory constraint, ie
>> if user bind big texture, big vbo ... we might not have
>> enough GPU address space to bind all the desired object
>> (even for drawing a single triangle) ?
>>
>> What should we do ? None of the draw callback can return
>> a value ? Maybe for a GL stack tracker we should report
>> GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
>> is i think pipe driver are missing something here. Any
>> idea ? Thought ? Is there already a plan to address that ? :)
>>
>> Cheers,
>> Jerome
>
> I think a vital point you're missing is: do we even care? If rendering
> fails because we simply can't render any more, do we even want to fall
> back? I can see a point in having a cap on how large a buffer can be
> rendered but apart from that, I'm not sure there even is a problem.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Corbin Simpson | 1 Mar 2010 06:35
Picon
Gravatar

Re: Gallium software fallback/draw command failure

On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie <airlied <at> gmail.com> wrote:
> On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt <bacn <at> zhasha.com> wrote:
>> On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
>>> Hi,
>>>
>>> I am a bit puzzled, how a pipe driver should handle
>>> draw callback failure ? On radeon (pretty sure nouveau
>>> or intel hit the same issue) we can only know when one
>>> of the draw_* context callback is call if we can do
>>> the rendering or not.
>>>
>>> The failure here is dictated by memory constraint, ie
>>> if user bind big texture, big vbo ... we might not have
>>> enough GPU address space to bind all the desired object
>>> (even for drawing a single triangle) ?
>>>
>>> What should we do ? None of the draw callback can return
>>> a value ? Maybe for a GL stack tracker we should report
>>> GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
>>> is i think pipe driver are missing something here. Any
>>> idea ? Thought ? Is there already a plan to address that ? :)
>>>
>>> Cheers,
>>> Jerome
>>
>> I think a vital point you're missing is: do we even care? If rendering
>> fails because we simply can't render any more, do we even want to fall
>> back? I can see a point in having a cap on how large a buffer can be
>> rendered but apart from that, I'm not sure there even is a problem.
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
José Fonseca | 1 Mar 2010 12:21
Favicon

Re: Gallium software fallback/draw command failure

On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> Hi,
> 
> I am a bit puzzled, how a pipe driver should handle
> draw callback failure ? On radeon (pretty sure nouveau
> or intel hit the same issue) we can only know when one
> of the draw_* context callback is call if we can do
> the rendering or not.
> 
> The failure here is dictated by memory constraint, ie
> if user bind big texture, big vbo ... we might not have
> enough GPU address space to bind all the desired object
> (even for drawing a single triangle) ?
> 
> What should we do ? None of the draw callback can return
> a value ? Maybe for a GL stack tracker we should report
> GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
> is i think pipe driver are missing something here. Any
> idea ? Thought ? Is there already a plan to address that ? :)

Gallium draw calls had return codes before. They were used for the
fallover driver IIRC and were recently deleted.

Either we put the return codes back, or we add a new
pipe_context::validate() that would ensure that all necessary conditions
to draw successfully are met.

Putting return codes on bind time won't work, because one can't set all
atoms simultaneously -- atoms are set one by one, so when one's setting
the state there are state combinations which may exceed the available
(Continue reading)

Permalink | Reply | 16 comments |
headers
José Fonseca | 1 Mar 2010 12:32
Favicon

Re: Gallium software fallback/draw command failure

On Sun, 2010-02-28 at 21:35 -0800, Corbin Simpson wrote:
> On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie <airlied <at> gmail.com> wrote:
> > On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt <bacn <at> zhasha.com> wrote:
> >> On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
> >>> Hi,
> >>>
> >>> I am a bit puzzled, how a pipe driver should handle
> >>> draw callback failure ? On radeon (pretty sure nouveau
> >>> or intel hit the same issue) we can only know when one
> >>> of the draw_* context callback is call if we can do
> >>> the rendering or not.
> >>>
> >>> The failure here is dictated by memory constraint, ie
> >>> if user bind big texture, big vbo ... we might not have
> >>> enough GPU address space to bind all the desired object
> >>> (even for drawing a single triangle) ?
> >>>
> >>> What should we do ? None of the draw callback can return
> >>> a value ? Maybe for a GL stack tracker we should report
> >>> GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
> >>> is i think pipe driver are missing something here. Any
> >>> idea ? Thought ? Is there already a plan to address that ? :)
> >>>
> >>> Cheers,
> >>> Jerome
> >>
> >> I think a vital point you're missing is: do we even care? If rendering
> >> fails because we simply can't render any more, do we even want to fall
> >> back? I can see a point in having a cap on how large a buffer can be
> >> rendered but apart from that, I'm not sure there even is a problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Whitwell | 1 Mar 2010 12:46
Favicon

Re: Gallium software fallback/draw command failure

On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
> On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> > Hi,
> > 
> > I am a bit puzzled, how a pipe driver should handle
> > draw callback failure ? On radeon (pretty sure nouveau
> > or intel hit the same issue) we can only know when one
> > of the draw_* context callback is call if we can do
> > the rendering or not.
> > 
> > The failure here is dictated by memory constraint, ie
> > if user bind big texture, big vbo ... we might not have
> > enough GPU address space to bind all the desired object
> > (even for drawing a single triangle) ?
> > 
> > What should we do ? None of the draw callback can return
> > a value ? Maybe for a GL stack tracker we should report
> > GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
> > is i think pipe driver are missing something here. Any
> > idea ? Thought ? Is there already a plan to address that ? :)
> 
> Gallium draw calls had return codes before. They were used for the
> fallover driver IIRC and were recently deleted.
> 
> Either we put the return codes back, or we add a new
> pipe_context::validate() that would ensure that all necessary conditions
> to draw successfully are met.
> 
> Putting return codes on bind time won't work, because one can't set all
> atoms simultaneously -- atoms are set one by one, so when one's setting
(Continue reading)

Permalink | Reply | 14 comments |
headers
Jerome Glisse | 1 Mar 2010 12:55

Re: Gallium software fallback/draw command failure

On Mon, Mar 01, 2010 at 11:46:08AM +0000, Keith Whitwell wrote:
> On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
> > On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> > > Hi,
> > > 
> > > I am a bit puzzled, how a pipe driver should handle
> > > draw callback failure ? On radeon (pretty sure nouveau
> > > or intel hit the same issue) we can only know when one
> > > of the draw_* context callback is call if we can do
> > > the rendering or not.
> > > 
> > > The failure here is dictated by memory constraint, ie
> > > if user bind big texture, big vbo ... we might not have
> > > enough GPU address space to bind all the desired object
> > > (even for drawing a single triangle) ?
> > > 
> > > What should we do ? None of the draw callback can return
> > > a value ? Maybe for a GL stack tracker we should report
> > > GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
> > > is i think pipe driver are missing something here. Any
> > > idea ? Thought ? Is there already a plan to address that ? :)
> > 
> > Gallium draw calls had return codes before. They were used for the
> > fallover driver IIRC and were recently deleted.
> > 
> > Either we put the return codes back, or we add a new
> > pipe_context::validate() that would ensure that all necessary conditions
> > to draw successfully are met.
> > 
> > Putting return codes on bind time won't work, because one can't set all
(Continue reading)

Permalink | Reply | 13 comments |
headers
Keith Whitwell | 1 Mar 2010 13:07
Favicon

Re: Gallium software fallback/draw command failure

On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
> On Mon, Mar 01, 2010 at 11:46:08AM +0000, Keith Whitwell wrote:
> > On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
> > > On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> > > > Hi,
> > > > 
> > > > I am a bit puzzled, how a pipe driver should handle
> > > > draw callback failure ? On radeon (pretty sure nouveau
> > > > or intel hit the same issue) we can only know when one
> > > > of the draw_* context callback is call if we can do
> > > > the rendering or not.
> > > > 
> > > > The failure here is dictated by memory constraint, ie
> > > > if user bind big texture, big vbo ... we might not have
> > > > enough GPU address space to bind all the desired object
> > > > (even for drawing a single triangle) ?
> > > > 
> > > > What should we do ? None of the draw callback can return
> > > > a value ? Maybe for a GL stack tracker we should report
> > > > GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
> > > > is i think pipe driver are missing something here. Any
> > > > idea ? Thought ? Is there already a plan to address that ? :)
> > > 
> > > Gallium draw calls had return codes before. They were used for the
> > > fallover driver IIRC and were recently deleted.
> > > 
> > > Either we put the return codes back, or we add a new
> > > pipe_context::validate() that would ensure that all necessary conditions
> > > to draw successfully are met.
> > >
(Continue reading)

Permalink | Reply | 4 comments |
headers
Olivier Galibert | 1 Mar 2010 13:40
Picon
Favicon

Re: Gallium software fallback/draw command failure

On Mon, Mar 01, 2010 at 12:55:09PM +0100, Jerome Glisse wrote:
> So you don't like the pipe_context::validate() of Jose ? My
> taste goes to the pipe_context::validate() and having state
> tracker setting the proper flag according to the API they
> support (GL_OUT_OF_MEMORY for GL), this means just drop
> rendering command that we can't do.

validate-then-do is a race condition waiting to happen.  Validate is
also a somewhat costly operation to do, and 99.999% of the time for
nothing.  You don't want to optimize for the error case, and that's
what validate *is*.

  OG.

------------------------------------------------------------------------------
Download Intel&#174; 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
Permalink | Reply | 7 comments |

Gmane