Re: [Mesa-dev] News about my GSoC proposal
Am 21.03.2011 11:43, schrieb Denis Steckelmacher: > […] > I'm open to any suggestion. I now understand the majority of the Mesa code (I > read most of it past week), and I also read some parts of the OpenVG state > tracker (a state tracker not too far from OpenGL, but way simpler, and built > directly on top of Gallium, so close to what I want to experiment the > following weeks). Have you considered working on Clover, the OpenCL state tracker? It seems like it would fit your criteria of wanting to work on a state tracker not burdened by all the legacy stuff as much as the current GL implementation. Philipp ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: In update_samplers(), clear all samplers at once.
Keith Whitwell [2011-03-21 18:43]: > On Mon, 2011-03-21 at 19:28 +0100, Tilman Sauerbeck wrote: > > Signed-off-by: Tilman Sauerbeck > > --- > > > > update_samplers() showed up in a profile of Heroes of Newerth; > > this patch pushes it down the profile by ~3%. > > > > Does this seem plausible? > > > > src/mesa/state_tracker/st_atom_sampler.c |5 +++-- > > 1 files changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/src/mesa/state_tracker/st_atom_sampler.c > > b/src/mesa/state_tracker/st_atom_sampler.c > > index 474cbd5..4374ac1 100644 > > --- a/src/mesa/state_tracker/st_atom_sampler.c > > +++ b/src/mesa/state_tracker/st_atom_sampler.c > > @@ -129,12 +129,13 @@ update_samplers(struct st_context *st) > > > > st->state.num_samplers = 0; > > > > + memset(st->state.samplers, 0, st->ctx->Const.MaxTextureImageUnits * > > + sizeof(struct pipe_sampler_state)); > > + > > At a glance, could the memset be moved up another couple of lines and > changed to: > > memset(st->state.samplers, 0, st->state.num_samplers * sizeof(struct > pipe_sampler_state)); I wondered about this, too. Consider the case where the sampler state is undefined when update_samplers() is called though -- then we might end up with partially uninitialized samplers, no? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpd6mh5uL0Yr.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: In update_samplers(), clear all samplers at once.
On Mon, 2011-03-21 at 19:28 +0100, Tilman Sauerbeck wrote: > Signed-off-by: Tilman Sauerbeck > --- > > update_samplers() showed up in a profile of Heroes of Newerth; > this patch pushes it down the profile by ~3%. > > Does this seem plausible? > > src/mesa/state_tracker/st_atom_sampler.c |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/src/mesa/state_tracker/st_atom_sampler.c > b/src/mesa/state_tracker/st_atom_sampler.c > index 474cbd5..4374ac1 100644 > --- a/src/mesa/state_tracker/st_atom_sampler.c > +++ b/src/mesa/state_tracker/st_atom_sampler.c > @@ -129,12 +129,13 @@ update_samplers(struct st_context *st) > > st->state.num_samplers = 0; > > + memset(st->state.samplers, 0, st->ctx->Const.MaxTextureImageUnits * > + sizeof(struct pipe_sampler_state)); > + At a glance, could the memset be moved up another couple of lines and changed to: memset(st->state.samplers, 0, st->state.num_samplers * sizeof(struct pipe_sampler_state)); Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: In update_samplers(), clear all samplers at once.
Signed-off-by: Tilman Sauerbeck
---
update_samplers() showed up in a profile of Heroes of Newerth;
this patch pushes it down the profile by ~3%.
Does this seem plausible?
src/mesa/state_tracker/st_atom_sampler.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_sampler.c
b/src/mesa/state_tracker/st_atom_sampler.c
index 474cbd5..4374ac1 100644
--- a/src/mesa/state_tracker/st_atom_sampler.c
+++ b/src/mesa/state_tracker/st_atom_sampler.c
@@ -129,12 +129,13 @@ update_samplers(struct st_context *st)
st->state.num_samplers = 0;
+ memset(st->state.samplers, 0, st->ctx->Const.MaxTextureImageUnits *
+ sizeof(struct pipe_sampler_state));
+
/* loop over sampler units (aka tex image units) */
for (su = 0; su < st->ctx->Const.MaxTextureImageUnits; su++) {
struct pipe_sampler_state *sampler = st->state.samplers + su;
- memset(sampler, 0, sizeof(*sampler));
-
if (samplersUsed & (1 << su)) {
struct gl_texture_object *texobj;
struct gl_texture_image *teximg;
--
1.7.3.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: implement clamping controls (ARB_color_buffer_float)
On 03/21/2011 05:43 PM, Marek Olšák wrote:
> On Mon, Mar 21, 2011 at 4:50 PM, Brian Paul wrote:
>
>> On 03/21/2011 09:10 AM, Keith Whitwell wrote:
>>
>>> On Mon, 2011-03-21 at 02:12 +0100, Marek Olšák wrote:
>>>
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index cf6c5b5..f6ad456 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -81,6 +81,8 @@ struct pipe_rasterizer_state
{
unsigned flatshade:1;
unsigned light_twoside:1;
+ unsigned clamp_vertex_color:1;
+ unsigned clamp_fragment_color:1;
unsigned front_ccw:1;
unsigned cull_face:2; /**< PIPE_FACE_x */
unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
>>>
>>> Don't know if this affects the overall packing of the struct. Have you
>>> been able to check?
>>>
>>> Otherwise the interface changes look good to me.
>>>
>>
>>
>> How do most GPUs handle this clamping? Is it done with extra shader code
>> or is it a discrete operation? If most hardware does it with shader code,
>> maybe we should just do it that way too in Gallium and avoid the new cap
>> bits, etc.
>>
>
> There is a bit in the CB_COLOR[0-7]_INFO register on R600 which controls
> color clamping before blending. I am not sure whether it can be used for
> ARB_color_buffer_float or whether it's strictly dependent on the colorbuffer
> format.
>
> Christoph, do you happen to know whether NV50/NVC0 has a hardware state
> for it too?
>
>
Sure,
there's a command to control per-RT fragment colour clamping and one to
enable/disable vertex colour clamping. No fiddling with shaders.
Not sure where exactly the clamping happens, but it's supposed to behave
like OpenGL requires it to.
(So we just call them FRAG_COLOR_CLAMP_EN and VERT_COLOR_CLAMP_EN,
on nv50 the latter is part of the color semantic/linkage setup, on nvc0
it always applies to the dedicated colour outputs.)
>
>> OpenGL 3.0 deprecates the per-vertex and per-fragment clamp controls so
>> people will have to do it in their shaders eventually.
>>
>>
>> Re: your comment in rasterizer.rst:
>>
>>
>> XXX: this happens _before_ the geometry shader and thus might not belong
>> here.
>>
>> So is there some question about where the per-vertex clamp is to be done?
>> It seems to me that it should be done after the geometry shader.
>>
>
> You're right. I will remove that comment.
>
> Marek
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: implement clamping controls (ARB_color_buffer_float)
On Mon, Mar 21, 2011 at 4:50 PM, Brian Paul wrote:
> On 03/21/2011 09:10 AM, Keith Whitwell wrote:
>
>> On Mon, 2011-03-21 at 02:12 +0100, Marek Olšák wrote:
>>
>>> diff --git a/src/gallium/include/pipe/p_state.h
>>> b/src/gallium/include/pipe/p_state.h
>>> index cf6c5b5..f6ad456 100644
>>> --- a/src/gallium/include/pipe/p_state.h
>>> +++ b/src/gallium/include/pipe/p_state.h
>>> @@ -81,6 +81,8 @@ struct pipe_rasterizer_state
>>> {
>>> unsigned flatshade:1;
>>> unsigned light_twoside:1;
>>> + unsigned clamp_vertex_color:1;
>>> + unsigned clamp_fragment_color:1;
>>> unsigned front_ccw:1;
>>> unsigned cull_face:2; /**< PIPE_FACE_x */
>>> unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
>>>
>>
>> Don't know if this affects the overall packing of the struct. Have you
>> been able to check?
>>
>> Otherwise the interface changes look good to me.
>>
>
>
> How do most GPUs handle this clamping? Is it done with extra shader code
> or is it a discrete operation? If most hardware does it with shader code,
> maybe we should just do it that way too in Gallium and avoid the new cap
> bits, etc.
>
There is a bit in the CB_COLOR[0-7]_INFO register on R600 which controls
color clamping before blending. I am not sure whether it can be used for
ARB_color_buffer_float or whether it's strictly dependent on the colorbuffer
format.
Christopher, do you happen to know whether NV50/NVC0 has a hardware state
for it too?
> OpenGL 3.0 deprecates the per-vertex and per-fragment clamp controls so
> people will have to do it in their shaders eventually.
>
>
> Re: your comment in rasterizer.rst:
>
>
> XXX: this happens _before_ the geometry shader and thus might not belong
> here.
>
> So is there some question about where the per-vertex clamp is to be done?
> It seems to me that it should be done after the geometry shader.
>
You're right. I will remove that comment.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: implement clamping controls (ARB_color_buffer_float)
Yeah I moved it from the rasterizer state to the blend state, but then I
realized the rasterizer state had been a better place. The thing is the
fragment color clamping is done right after the fragment shader output is
written, that is before the alpha test, before the depth/stencil test, and
therefore long before blending. So I don't know where to put it. Obviously,
the depth-stencil-alpha state is a better candidate than the blend state.
Also you can do some nasty things with it. For example, you can use the
clamping to clamp the fragment color after the fragment shader and then
multiply it by 2 in the blending stage, effectively outputting a value in
the range [0, 2].
Marek
On Mon, Mar 21, 2011 at 4:36 PM, Keith Whitwell wrote:
> On Mon, 2011-03-21 at 16:23 +0100, Christoph Bumiller wrote:
> > On 03/21/2011 02:12 AM, Marek Olšák wrote:
> >
> > > diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> > > index cf6c5b5..f6ad456 100644
> > > --- a/src/gallium/include/pipe/p_state.h
> > > +++ b/src/gallium/include/pipe/p_state.h
> > > @@ -81,6 +81,8 @@ struct pipe_rasterizer_state
> > > {
> > > unsigned flatshade:1;
> > > unsigned light_twoside:1;
> > > + unsigned clamp_vertex_color:1;
> > > + unsigned clamp_fragment_color:1;
> > > unsigned front_ccw:1;
> > > unsigned cull_face:2; /**< PIPE_FACE_x */
> > > unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
> >
> > Hadn't you put clamp_fragment_color in the blend state initially ?
> > It seems like a more logical place to me.
>
> Indeed you're right. Fragment color clamping takes place in the part of
> the pipeline governed by the blend CSO.
>
> Keith
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: implement clamping controls (ARB_color_buffer_float)
On 03/21/2011 09:10 AM, Keith Whitwell wrote:
On Mon, 2011-03-21 at 02:12 +0100, Marek Olšák wrote:
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index cf6c5b5..f6ad456 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -81,6 +81,8 @@ struct pipe_rasterizer_state
{
unsigned flatshade:1;
unsigned light_twoside:1;
+ unsigned clamp_vertex_color:1;
+ unsigned clamp_fragment_color:1;
unsigned front_ccw:1;
unsigned cull_face:2; /**< PIPE_FACE_x */
unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
Don't know if this affects the overall packing of the struct. Have you
been able to check?
Otherwise the interface changes look good to me.
How do most GPUs handle this clamping? Is it done with extra shader
code or is it a discrete operation? If most hardware does it with
shader code, maybe we should just do it that way too in Gallium and
avoid the new cap bits, etc.
OpenGL 3.0 deprecates the per-vertex and per-fragment clamp controls
so people will have to do it in their shaders eventually.
Re: your comment in rasterizer.rst:
XXX: this happens _before_ the geometry shader and thus might not
belong here.
So is there some question about where the per-vertex clamp is to be
done? It seems to me that it should be done after the geometry shader.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: implement clamping controls (ARB_color_buffer_float)
On Mon, 2011-03-21 at 16:23 +0100, Christoph Bumiller wrote:
> On 03/21/2011 02:12 AM, Marek Olšák wrote:
>
> > diff --git a/src/gallium/include/pipe/p_state.h
> > b/src/gallium/include/pipe/p_state.h
> > index cf6c5b5..f6ad456 100644
> > --- a/src/gallium/include/pipe/p_state.h
> > +++ b/src/gallium/include/pipe/p_state.h
> > @@ -81,6 +81,8 @@ struct pipe_rasterizer_state
> > {
> > unsigned flatshade:1;
> > unsigned light_twoside:1;
> > + unsigned clamp_vertex_color:1;
> > + unsigned clamp_fragment_color:1;
> > unsigned front_ccw:1;
> > unsigned cull_face:2; /**< PIPE_FACE_x */
> > unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
>
> Hadn't you put clamp_fragment_color in the blend state initially ?
> It seems like a more logical place to me.
Indeed you're right. Fragment color clamping takes place in the part of
the pipeline governed by the blend CSO.
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: implement clamping controls (ARB_color_buffer_float)
On 03/21/2011 02:12 AM, Marek Olšák wrote:
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index cf6c5b5..f6ad456 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -81,6 +81,8 @@ struct pipe_rasterizer_state
> {
> unsigned flatshade:1;
> unsigned light_twoside:1;
> + unsigned clamp_vertex_color:1;
> + unsigned clamp_fragment_color:1;
> unsigned front_ccw:1;
> unsigned cull_face:2; /**< PIPE_FACE_x */
> unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
Hadn't you put clamp_fragment_color in the blend state initially ?
It seems like a more logical place to me.
Beyond that I don't mind where it ends up though, both CSOs are growing
a little too large for my taste.
Christoph
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] gallium: implement clamping controls (ARB_color_buffer_float)
On Mon, 2011-03-21 at 02:12 +0100, Marek Olšák wrote:
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index cf6c5b5..f6ad456 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -81,6 +81,8 @@ struct pipe_rasterizer_state
> {
> unsigned flatshade:1;
> unsigned light_twoside:1;
> + unsigned clamp_vertex_color:1;
> + unsigned clamp_fragment_color:1;
> unsigned front_ccw:1;
> unsigned cull_face:2; /**< PIPE_FACE_x */
> unsigned fill_front:2; /**< PIPE_POLYGON_MODE_x */
Don't know if this affects the overall packing of the struct. Have you
been able to check?
Otherwise the interface changes look good to me.
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] mesa/gallium: add NV_texture_barrier
On Sat, 2011-03-12 at 00:48 +0100, Marek Olšák wrote: > On Fri, Mar 11, 2011 at 2:56 PM, Keith Whitwell wrote: > > > > So my suggestion would be to name this something else, perhaps taking > > language from the NV extension. > > > > Alright. > > There are two patches attached in this email. The former is my attempt at > display list support that I missed. The latter changes the gallium entry > point to: > > void (*texture_barrier)(struct pipe_context *); > > Please review. > > Best regards > Marek Looks great Marek. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] News about my GSoC proposal
Hello, I can consider working on a hardware driver, but I'm not very familiar with these pieces of software. I will also need to work two weeks without my main computer, on a Packard Bell laptop with an RS690m graphics card (r300g driver). The r300g driver is already mature, exept one memory corruption bug on my RS690 (reported on the bugzilla as bug nr 35457). I planned to use llvmpipe to work on Mesa or my state tracker. Nevertheless, I have an ATI Radeon 4800 or so somewhere at home, so I can put it in my computer (instead of the integrated RS690, yes, another RS690, they chase me) and try to work on the r600g driver, but I don't know if I will be able to do something interesting. I'm open to any suggestion. I now understand the majority of the Mesa code (I read most of it past week), and I also read some parts of the OpenVG state tracker (a state tracker not too far from OpenGL, but way simpler, and built directly on top of Gallium, so close to what I want to experiment the following weeks). Best regards, Denis Steckelmacher. > Hi Denis, > > I think the work to replace Mesa IR with GLSL IR is being done by Intel (it > was mentioned on #dri-devel, feel free to drop by), but I don't think they > will want to touch the st_mesa_to_tgsi part. > > Have you considered working on a hardware driver? Sometimes, stable and fast > drivers are all that users need. :) > > Marek > > On Sun, Mar 20, 2011 at 6:52 PM, Denis Steckelmacher wrote: > > Hello, > > > > One week has passed since my last mail, talking about an OpenGL 4.1 Core > > state > > tracker. There has been great interest and many remarks, so thanks to > > you > > all. > > > > I write this mail to give some more information about my future > > proposal, > > and > > to say that I have not disappeared and that I'm already working. I'm > > currently > > browsing the whole Mesa code, not only Gallium, and even EGL and GLX > > code. The > > project of replacing Mesa IR with GLSL IR seems to be really > > interesting, > > and > > it seems I will apply to do that (plus some other things if I have time > > to do > > so, but I doubt it, as Mesa IR is really heavily used in Mesa and the > > Mesa state tracker). > > > > I'm also reading the code to have a more precise idea about the amount > > of > > work > > needed to make a simple OpenGL 3+ Core state tracker, as an experiment > > during > > the following months, before the Summer of Code. This way, I will be > > able > > to > > see if it's possible and interresting. > > > > So, thanks a lot for your replies to my previous mails, I now know what > > you want and I find that interesting. > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
