Re: [Mesa-dev] [PATCH 7/8] st/vdpau: Destroy context when initialization fails

[Christian König]

Am 12.12.2013 23:47, schrieb Aaron Watry:

Prevents a potential memory leak found when tracking down something else.


Patch is : Reviewed-by: Christian König 


---
  src/gallium/state_trackers/vdpau/device.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/vdpau/device.c 
b/src/gallium/state_trackers/vdpau/device.c
index 309fee4..fb9c68c 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -86,6 +86,7 @@ vdp_imp_device_create_x11(Display *display, int screen, 
VdpDevice *device,
 return VDP_STATUS_OK;
  
  no_handle:

+   dev->context->destroy(dev->context);
 /* Destroy vscreen */
  no_context:
 vl_screen_destroy(dev->vscreen);


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 19/23] glsl: Add image built-in function generator.

[Francisco Jerez]

Kenneth Graunke  writes:

> On 11/26/2013 12:02 AM, Francisco Jerez wrote:
> [snip]
>> +   add_image_function("imageLoad",
>> +  image_builtin_builder(*this)
>> +  .emit_stub("__intrinsic_image_load")
>> +  .has_return()
>> +  .has_vector_data_type()
>> +  .has_float_data_type()
>> +  .read_only());
>
> I agree with Paul...I'm not a huge fan of using this pattern here.
>
> Using true/false, i.e.
> add_image_function("imageLoad", true, true, true, true, false, ...);
> is clearly awful.
>
> But what about using a flags bitfield?  Something like:
>
> enum image_function_flags {
>RETURNS_DATA= (1 << 0),
>HAS_VECTOR_DATA_TYPE= (1 << 1),
>SUPPORTS_FLOATING_POINT_IMAGES  = (1 << 2),
>READ_ONLY   = (1 << 3),
>EMIT_STUB   = (1 << 4),
> };
>
> and then:
>
> void
> add_image_function(const char *name,
>unsigned num_arguments,
>uint32_t flags);
>
> i.e.
> add_image_function("imageLoad", 0,
>RETURNS_DATA |
>HAS_VECTOR_DATA_TYPE |
>SUPPORTS_FLOATING_POINT_IMAGES |
>READ_ONLY);
>
> That remains readable, like your code, but follows an extremely common
> pattern we already use all over the place.
>
That would be a reasonable solution too, I'll have a look into it.

Thanks.

> --Ken


pgpGtZjz9aAOb.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 1/9] st/mesa: always prefer pipe->clear over clear_with_quad

[Jose Fonseca]

This is worse for SW renderers...

Jose

- Original Message -
> From: Marek Olšák 
> 
> ---
>  src/mesa/state_tracker/st_cb_clear.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_cb_clear.c
> b/src/mesa/state_tracker/st_cb_clear.c
> index 887e58b..46f2f8d 100644
> --- a/src/mesa/state_tracker/st_cb_clear.c
> +++ b/src/mesa/state_tracker/st_cb_clear.c
> @@ -476,14 +476,16 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
>}
> }
>  
> -   /*
> -* If we're going to use clear_with_quad() for any reason, use it for
> -* everything possible.
> +   /* Only use quad-based clearing for the renderbuffers which cannot
> +* use pipe->clear. We want to always use pipe->clear for the other
> +* renderbuffers, because it's likely to be faster. Even if there is
> +* a combined depth-stencil buffer, the depth and stencil components
> +* may be stored separately internally.
>  */
> if (quad_buffers) {
> -  quad_buffers |= clear_buffers;
>clear_with_quad(ctx, quad_buffers);
> -   } else if (clear_buffers) {
> +   }
> +   if (clear_buffers) {
>/* We can't translate the clear color to the colorbuffer format,
> * because different colorbuffers may have different formats.
> */
> --
> 1.8.3.2
> 
> ___
> 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

[Mesa-dev] [PATCH] radeonsi: Since we're not using HiS, use more buffer space for HiZ.

[Andreas Hartmetz]

Also move a comment that was in the wrong place.
---
 src/gallium/drivers/radeonsi/si_state.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index d99cfe8..ee2372f 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1751,7 +1751,7 @@ void si_update_db_draw_state(struct r600_context *rctx, 
struct r600_surface *zsb
 
/* db */
 
-   /* TODO HiS aka stencil buffer htile goes here */
+   /* not using HiS aka stencil buffer htile for now, the benefits are 
unclear */
db_render_override = S_02800C_FORCE_HIS_ENABLE0(V_02800C_FORCE_DISABLE) 
|
 S_02800C_FORCE_HIS_ENABLE1(V_02800C_FORCE_DISABLE);
 
@@ -1763,6 +1763,7 @@ void si_update_db_draw_state(struct r600_context *rctx, 
struct r600_surface *zsb
hiz_enable = rtex->htile_buffer && !level;
}
if (hiz_enable) {
+   /* Force off means no force, DB_SHADER_CONTROL decides */
db_render_override |= 
S_02800C_FORCE_HIZ_ENABLE(V_02800C_FORCE_OFF);
} else {
db_render_override |= 
S_02800C_FORCE_HIZ_ENABLE(V_02800C_FORCE_DISABLE);
@@ -1877,7 +1878,8 @@ static void si_db(struct r600_context *rctx, struct 
si_pm4_state *pm4,
/* use htile only for first level */
if (rtex->htile_buffer && !level) {
z_info |= S_028040_TILE_SURFACE_ENABLE(1);
-   /* Force off means no force, DB_SHADER_CONTROL decides */
+   /* we are not using HiS for now, so use more of the buffer for 
HiZ */
+   s_info |= S_028044_TILE_STENCIL_DISABLE(1);
uint64_t va = r600_resource_va(&rctx->screen->b.b, 
&rtex->htile_buffer->b.b);
db_htile_data_base = va >> 8;
db_htile_surface = S_028ABC_FULL_CACHE(1);
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/9] st/mesa: always prefer pipe->clear over clear_with_quad

[Marek Olšák]

It will only be worse for combined Z-stencil buffers if Z and
stencil are interleaved, and if SW rasterizers don't support any kind
of fast clear.

Marek

On Fri, Dec 13, 2013 at 3:21 PM, Jose Fonseca  wrote:
> This is worse for SW renderers...
>
> Jose
>
> - Original Message -
>> From: Marek Olšák 
>>
>> ---
>>  src/mesa/state_tracker/st_cb_clear.c | 12 +++-
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_cb_clear.c
>> b/src/mesa/state_tracker/st_cb_clear.c
>> index 887e58b..46f2f8d 100644
>> --- a/src/mesa/state_tracker/st_cb_clear.c
>> +++ b/src/mesa/state_tracker/st_cb_clear.c
>> @@ -476,14 +476,16 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
>>}
>> }
>>
>> -   /*
>> -* If we're going to use clear_with_quad() for any reason, use it for
>> -* everything possible.
>> +   /* Only use quad-based clearing for the renderbuffers which cannot
>> +* use pipe->clear. We want to always use pipe->clear for the other
>> +* renderbuffers, because it's likely to be faster. Even if there is
>> +* a combined depth-stencil buffer, the depth and stencil components
>> +* may be stored separately internally.
>>  */
>> if (quad_buffers) {
>> -  quad_buffers |= clear_buffers;
>>clear_with_quad(ctx, quad_buffers);
>> -   } else if (clear_buffers) {
>> +   }
>> +   if (clear_buffers) {
>>/* We can't translate the clear color to the colorbuffer format,
>> * because different colorbuffers may have different formats.
>> */
>> --
>> 1.8.3.2
>>
>> ___
>> 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

Re: [Mesa-dev] [PATCH 1/9] st/mesa: always prefer pipe->clear over clear_with_quad

[Jose Fonseca]

What you mean by "fast clear"?

llvmpipe depth-stencil buffers are interleaved, and AFAICT partial clears will 
be done with quads.  In other words, this will make llvmpipe slower.

In truth, this will all drivers with interleaved z/s bufferss slower.  That is, 
this is optimizing for some drivers at expense of others which might have 
interleaved depth-stencil buffer.  The very fact that it is worthwhile doing 
this change for your gpu means that it must be worthwhile for others to leave 
it as it was...

So, if this provides a significant performance difference, then I think the 
only option to have everybody happy is to have cap to choose the optimal 
behavior.

Jose

- Original Message -
> It will only be worse for combined Z-stencil buffers if Z and
> stencil are interleaved, and if SW rasterizers don't support any kind
> of fast clear.
> 
> Marek
> 
> On Fri, Dec 13, 2013 at 3:21 PM, Jose Fonseca  wrote:
> > This is worse for SW renderers...
> >
> > Jose
> >
> > - Original Message -
> >> From: Marek Olšák 
> >>
> >> ---
> >>  src/mesa/state_tracker/st_cb_clear.c | 12 +++-
> >>  1 file changed, 7 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/src/mesa/state_tracker/st_cb_clear.c
> >> b/src/mesa/state_tracker/st_cb_clear.c
> >> index 887e58b..46f2f8d 100644
> >> --- a/src/mesa/state_tracker/st_cb_clear.c
> >> +++ b/src/mesa/state_tracker/st_cb_clear.c
> >> @@ -476,14 +476,16 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
> >>}
> >> }
> >>
> >> -   /*
> >> -* If we're going to use clear_with_quad() for any reason, use it for
> >> -* everything possible.
> >> +   /* Only use quad-based clearing for the renderbuffers which cannot
> >> +* use pipe->clear. We want to always use pipe->clear for the other
> >> +* renderbuffers, because it's likely to be faster. Even if there is
> >> +* a combined depth-stencil buffer, the depth and stencil components
> >> +* may be stored separately internally.
> >>  */
> >> if (quad_buffers) {
> >> -  quad_buffers |= clear_buffers;
> >>clear_with_quad(ctx, quad_buffers);
> >> -   } else if (clear_buffers) {
> >> +   }
> >> +   if (clear_buffers) {
> >>/* We can't translate the clear color to the colorbuffer format,
> >> * because different colorbuffers may have different formats.
> >> */
> >> --
> >> 1.8.3.2
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cvIgdPYPFAOCEZnN3p40o7cbw0cTfSQzytP%2Byju9mDI%3D%0A&s=b1c126addd7be0ac34d91039bb019dabb14c976597b451daa14f440755d95f14
> >>
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Since we're not using HiS, use more buffer space for HiZ.

[Marek Olšák]

HiS might be useful for anything that uses id Tech 4, like Doom 3,
ETQW, etc. I'm not sure about later chips, but R300-R500 has to
disable HiZ entirely if certain stencil operations are used.

Marek

On Fri, Dec 13, 2013 at 4:58 PM, Andreas Hartmetz  wrote:
> Also move a comment that was in the wrong place.
> ---
>  src/gallium/drivers/radeonsi/si_state.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index d99cfe8..ee2372f 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -1751,7 +1751,7 @@ void si_update_db_draw_state(struct r600_context *rctx, 
> struct r600_surface *zsb
>
> /* db */
>
> -   /* TODO HiS aka stencil buffer htile goes here */
> +   /* not using HiS aka stencil buffer htile for now, the benefits are 
> unclear */
> db_render_override = 
> S_02800C_FORCE_HIS_ENABLE0(V_02800C_FORCE_DISABLE) |
>  
> S_02800C_FORCE_HIS_ENABLE1(V_02800C_FORCE_DISABLE);
>
> @@ -1763,6 +1763,7 @@ void si_update_db_draw_state(struct r600_context *rctx, 
> struct r600_surface *zsb
> hiz_enable = rtex->htile_buffer && !level;
> }
> if (hiz_enable) {
> +   /* Force off means no force, DB_SHADER_CONTROL decides */
> db_render_override |= 
> S_02800C_FORCE_HIZ_ENABLE(V_02800C_FORCE_OFF);
> } else {
> db_render_override |= 
> S_02800C_FORCE_HIZ_ENABLE(V_02800C_FORCE_DISABLE);
> @@ -1877,7 +1878,8 @@ static void si_db(struct r600_context *rctx, struct 
> si_pm4_state *pm4,
> /* use htile only for first level */
> if (rtex->htile_buffer && !level) {
> z_info |= S_028040_TILE_SURFACE_ENABLE(1);
> -   /* Force off means no force, DB_SHADER_CONTROL decides */
> +   /* we are not using HiS for now, so use more of the buffer 
> for HiZ */
> +   s_info |= S_028044_TILE_STENCIL_DISABLE(1);
> uint64_t va = r600_resource_va(&rctx->screen->b.b, 
> &rtex->htile_buffer->b.b);
> db_htile_data_base = va >> 8;
> db_htile_surface = S_028ABC_FULL_CACHE(1);
> --
> 1.8.3.2
>
> ___
> 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

Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing

[Courtney Goeltzenleuchter]

Hi Chris,

How goes arb_texture_view?
I'd like to see what you have. Please let me know if I can help.

Thanks,
Courtney


On Mon, Nov 25, 2013 at 1:42 PM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:

> I've added a viewport_array-rc2 branch to my github repository with
> updates from the feedback so far. Also includes a commit from Ian to Add
> varying slot for viewport index.
>
> Courtney
>
>
> On Fri, Nov 22, 2013 at 3:51 PM, Courtney Goeltzenleuchter <
> court...@lunarg.com> wrote:
>
>> Got it.
>>
>>
>> On Fri, Nov 22, 2013 at 2:55 PM, Chris Forbes  wrote:
>>
>>> It's just that last block that were messed up -- rest was context.
>>>
>>> Sorry for any confusion.
>>>
>>>
>>> On Sat, Nov 23, 2013 at 10:06 AM, Courtney Goeltzenleuchter <
>>> court...@lunarg.com> wrote:
>>>
 Hi Chris,

 I'm using this version of the spec:
 http://www.opengl.org/registry/specs/ARB/viewport_array.txt

 On Thu, Nov 21, 2013 at 4:41 PM, Chris Forbes  wrote:

> I was just comparing to the list in the ARB_viewport_array spec.
>
>
> On Fri, Nov 22, 2013 at 11:33 AM, Courtney Goeltzenleuchter <
> court...@lunarg.com> wrote:
>
>> Hi Chris,
>>
>> Where are you getting your defines?
>> I copied them from include/GL/gl.h
>> #define GL_VIEWPORT 0x0BA2
>> /* Scissor box */
>> #define GL_SCISSOR_BOX 0x0C10
>> #define GL_SCISSOR_TEST 0x0C11
>> #define GL_SCISSOR_TEST 0x0C11
>> #define GL_DEPTH_RANGE 0x0B70
>>
>> Ah, FIRST_VERTEX looks different.
>> #define GL_FIRST_VERTEX_CONVENTION0x8E4D
>>
>> I'll add PROVOKING_VERTEX
>>
>> Looks like UNDEFINED_VERTEX was wrong as well.
>> (include/GL/glext.h) #define GL_UNDEFINED_VERTEX   0x8260
>>
>>  I was modelling one of the other extension xml files and they had
>> similar defines, though I could see no effect including or excluding 
>> them.
>>
>> Should I just get rid of the definitions for values that already
>> exist in gl.h or glext.h?
>>
>> Courtney
>>
>>
>> On Thu, Nov 21, 2013 at 1:00 PM, Chris Forbes wrote:
>>
>>> I'm surprised the build system accepts the conflicting second
>>> definition of SCISSOR_BOX at all, actually -- that's weird.
>>>
>>>
>>> On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes wrote:
>>>
 I mean some of the values don't match the spec :)


 On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter <
 court...@lunarg.com> wrote:

>
>
> On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes wrote:
>
>> Oops -- the 8E4E is obviously correct. Artifact of me switching
>> how I
>> was commenting halfway through.
>>
>> On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes 
>> wrote:
>> > These are bogus:
>> >
>> > +
>> > +
>> > +
>> > +
>> > +
>>
>
 In the spec I'm using I see:

 New Tokens

 Accepted by the  parameter of GetBooleanv, GetIntegerv, 
 GetFloatv,
 GetDoublev and GetInteger64v:

 MAX_VIEWPORTS   0x825B
 VIEWPORT_SUBPIXEL_BITS  0x825C
 VIEWPORT_BOUNDS_RANGE   0x825D
 LAYER_PROVOKING_VERTEX  0x825E
 VIEWPORT_INDEX_PROVOKING_VERTEX 0x825F

 Accepted by the  parameter of GetIntegeri_v:

 *SCISSOR_BOX 0x0C10*

 Accepted by the  parameter of GetFloati_v:

 *VIEWPORT0x0BA2*

 Accepted by the  parameter of GetDoublei_v:

 *DEPTH_RANGE 0x0B70*

 Accepted by the  parameter of Enablei, Disablei, and IsEnabledi:

 *SCISSOR_TEST0x0C11*

 Thus my confusion regarding "bogus" values.

 Returned in the  parameter from a Get query with a  of
 LAYER_PROVOKING_VERTEX or VIEWPORT_INDEX_PROVOKING_VERTEX:

 FIRST_VERTEX_CONVENTION 0x8E4D
 LAST_VERTEX_CONVENTION  0x8E4E
 PROVOKING_VERTEX0x8E4F
 UNDEFINED_VERTEX0x8260




>
> What do you mean by "bogus"?
> I was emulating other extension xml files. Are these not needed
> because they are already defined in gl_ext.h?
>
>
>> >
>> > 0x8E4D
>> >
>> > +
>> >
>> > 0x8E4E
>> >
>> > add: 
>> >
>> > +
>> >
>>>

Re: [Mesa-dev] [PATCH 04/10] i965: Emit full-length PIPE_CONTROLs for (non-write) flushes.

[Daniel Vetter]

On Thu, Dec 12, 2013 at 01:26:36AM -0800, Kenneth Graunke wrote:
> The PIPE_CONTROL packet actually has 5 DWords on Gen6+:
> 1. Header
> 2. Flags
> 3. Address
> 4. Immediate Data: Lower DWord
> 5. Immediate Data: Upper DWord
> 
> We just never emitted the last one.  While it appears to work, it's
> probably safer to emit the entire thing.

Afaik PIPE_CONTROL auto-switches the size of the write depending upon the
cmd length. We've already seen an increase from gen5 to gen6 (the flags
dword was added) and got away with it in the kernel for an awful lot of
time. So if you don't have any special plans wrt bdw compatibility I don't
think you need this.

MI_FLUSH_DW for the blitter (and other !render rings) works the same
magic. And judging from Bspec that's still the case for bdw+

Cheers, Daniel
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index d2f0e90..bc381fb 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -484,11 +484,12 @@ void
>  brw_emit_pipe_control_flush(struct brw_context *brw, uint32_t flags)
>  {
> if (brw->gen >= 6) {
> -  BEGIN_BATCH(4);
> -  OUT_BATCH(_3DSTATE_PIPE_CONTROL | (4 - 2));
> +  BEGIN_BATCH(5);
> +  OUT_BATCH(_3DSTATE_PIPE_CONTROL | (5 - 2));
>OUT_BATCH(flags);
>OUT_BATCH(0);
>OUT_BATCH(0);
> +  OUT_BATCH(0);
>ADVANCE_BATCH();
> } else {
>BEGIN_BATCH(4);
> -- 
> 1.8.4.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/10] i965: Use Global GTT for Sandybridge post-sync non-zero workaround.

[Daniel Vetter]

On Thu, Dec 12, 2013 at 01:26:37AM -0800, Kenneth Graunke wrote:
> The kernel doesn't even set up the aliasing PPGTT on Sandybridge, so any
> writes marked as PPGTT will likely just get dropped on the floor.

Ermh, aliasing ppgtt is enabled on snb. But the CS write stuff is broken
and will always land in the global gtt anyway, hence why it's crucial to
set the write domain to DOMAIN_INSTRUCTION. Otherwise the kernel w/a
doesn't kick in and you write to the scratch page. btw we have a kernel
param to figure out whether you should target ppgtt or not.
> 
> This begs the question: is the simple act of /requesting/ a write good
> enough for the workaround, or does it need to actually work?  Past
> experience suggests the workaround was effective even with PPGTT
> selected.  But perhaps we'll get lucky and this will help even more...
> 
> Signed-off-by: Kenneth Graunke 

See above, it doesn't really matter on snb (and strictly speaking the
ppgtt selector is the right thing to do anyway on all kernels mesa
supports still). On later generations the hw ignores this bit and forces
ppgtt anyway.

Since we do the exact same thing in the pipe_control i-g-t testcase (and
that one checks whether the write lands) for gen6&7, this is

Reviewed-by: Daniel Vetter 

> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index bc381fb..d360943 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -625,7 +625,8 @@ intel_emit_post_sync_nonzero_flush(struct brw_context 
> *brw)
> OUT_BATCH(_3DSTATE_PIPE_CONTROL | (4 - 2));
> OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
> OUT_RELOC(brw->batch.workaround_bo,
> -  I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION, 0);
> + I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION,
> + PIPE_CONTROL_GLOBAL_GTT_WRITE);
> OUT_BATCH(0); /* write data */
> ADVANCE_BATCH();
>  
> -- 
> 1.8.4.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/10] i965: Use full-length PIPE_CONTROL packets for workaround writes.

[Daniel Vetter]

On Thu, Dec 12, 2013 at 01:26:38AM -0800, Kenneth Graunke wrote:
> I believe that PIPE_CONTROL uses the length field to decide whether to
> do 32-bit or 64-bit writes.  A length of 4 would do a 32-bit write,
> while a length of 5 would do a 64-bit write.  (I haven't verified this,
> though.)
> 
> For workaround writes, we don't care what value gets written, or how
> much data.  We're only writing something because hardware bugs mandate
> that do so.  So using a 64-bit write should be fine.
> 
> Signed-off-by: Kenneth Graunke 

Note that 64bit writes with PIPE_CONTROL (and MI_FLUSH_DW, too) have a
stern w/a notice on all gen6+ generations that bit5 of the target address
must be cleared. I haven't checked existing users, but these here seem
safe. So

Reviewed-by: Daniel Vetter 
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index d360943..afc4850 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -536,12 +536,13 @@ gen7_emit_vs_workaround_flush(struct brw_context *brw)
>  {
> assert(brw->gen == 7);
>  
> -   BEGIN_BATCH(4);
> -   OUT_BATCH(_3DSTATE_PIPE_CONTROL | (4 - 2));
> +   BEGIN_BATCH(5);
> +   OUT_BATCH(_3DSTATE_PIPE_CONTROL | (5 - 2));
> OUT_BATCH(PIPE_CONTROL_DEPTH_STALL | PIPE_CONTROL_WRITE_IMMEDIATE);
> OUT_RELOC(brw->batch.workaround_bo,
>I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION, 0);
> OUT_BATCH(0); /* write data */
> +   OUT_BATCH(0); /* write data */
> ADVANCE_BATCH();
>  }
>  
> @@ -552,8 +553,8 @@ gen7_emit_vs_workaround_flush(struct brw_context *brw)
>  void
>  gen7_emit_cs_stall_flush(struct brw_context *brw)
>  {
> -   BEGIN_BATCH(4);
> -   OUT_BATCH(_3DSTATE_PIPE_CONTROL | (4 - 2));
> +   BEGIN_BATCH(5);
> +   OUT_BATCH(_3DSTATE_PIPE_CONTROL | (5 - 2));
> /* From p61 of the Ivy Bridge PRM (1.10.4 PIPE_CONTROL Command: DW1[20]
>  * CS Stall):
>  *
> @@ -571,6 +572,7 @@ gen7_emit_cs_stall_flush(struct brw_context *brw)
> OUT_RELOC(brw->batch.workaround_bo,
>   I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION, 0);
> OUT_BATCH(0);
> +   OUT_BATCH(0);
> ADVANCE_BATCH();
>  }
>  
> @@ -621,13 +623,14 @@ intel_emit_post_sync_nonzero_flush(struct brw_context 
> *brw)
> brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL |
> PIPE_CONTROL_STALL_AT_SCOREBOARD);
>  
> -   BEGIN_BATCH(4);
> -   OUT_BATCH(_3DSTATE_PIPE_CONTROL | (4 - 2));
> +   BEGIN_BATCH(5);
> +   OUT_BATCH(_3DSTATE_PIPE_CONTROL | (5 - 2));
> OUT_BATCH(PIPE_CONTROL_WRITE_IMMEDIATE);
> OUT_RELOC(brw->batch.workaround_bo,
>   I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION,
>   PIPE_CONTROL_GLOBAL_GTT_WRITE);
> OUT_BATCH(0); /* write data */
> +   OUT_BATCH(0); /* write data */
> ADVANCE_BATCH();
>  
> brw->batch.need_workaround_flush = false;
> -- 
> 1.8.4.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/10] i965: Introduce an OUT_RELOC64 macro.

[Daniel Vetter]

On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
> Broadwell uses 48-bit addresses.  The first DWord is the low 32 bits,
> and the second DWord is the high 16 bits.
> 
> Since individual buffers shouldn't be larger than 4GB in size, any
> offsets into those buffers (buffer->offset + delta) should fit in the
> low 32 bits.  So I believe we can simply emit 0 for the high 16-bits,
> and drm_intel_bo_emit_reloc() should patch it up.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> index 159f928..128eed9 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> @@ -178,6 +178,11 @@ void intel_batchbuffer_cached_advance(struct brw_context 
> *brw);
>   read_domains, write_domain, delta); \
>  } while (0)
>  
> +/* Handle 48-bit address relocations for Gen8+ */
> +#define OUT_RELOC64(buf, read_domains, write_domain, delta) \
> +   OUT_RELOC(buf, read_domains, write_domain, delta);   \
> +   OUT_BATCH(0);

Please not. The presumed_offset that libdrm uses is 64bits, and you need
to emit the full presumed address (and correctly shifted). Atm the kernel
never gives you a presumed reloc offset with the high bits set so it
doesn't matter. But I'd prefer if we don't need to make this opt-in
behaviour once we enable address spaces with more than 4G.

i-g-t gets away with the cheap hack since we're allowed to break igt.
Let me check ddx and libva whether I've lost this fight already ...
-Daniel
> +
>  #define ADVANCE_BATCH() intel_batchbuffer_advance(brw);
>  #define CACHED_BATCH() intel_batchbuffer_cached_advance(brw);
>  
> -- 
> 1.8.4.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/10] i965: Introduce an OUT_RELOC64 macro.

[Kenneth Graunke]

On 12/13/2013 09:28 AM, Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
>> Broadwell uses 48-bit addresses.  The first DWord is the low 32 bits,
>> and the second DWord is the high 16 bits.
>>
>> Since individual buffers shouldn't be larger than 4GB in size, any
>> offsets into those buffers (buffer->offset + delta) should fit in the
>> low 32 bits.  So I believe we can simply emit 0 for the high 16-bits,
>> and drm_intel_bo_emit_reloc() should patch it up.
>>
>> Signed-off-by: Kenneth Graunke 
>> ---
>>  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h 
>> b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
>> index 159f928..128eed9 100644
>> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
>> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
>> @@ -178,6 +178,11 @@ void intel_batchbuffer_cached_advance(struct 
>> brw_context *brw);
>>  read_domains, write_domain, delta); \
>>  } while (0)
>>  
>> +/* Handle 48-bit address relocations for Gen8+ */
>> +#define OUT_RELOC64(buf, read_domains, write_domain, delta) \
>> +   OUT_RELOC(buf, read_domains, write_domain, delta);   \
>> +   OUT_BATCH(0);
> 
> Please not. The presumed_offset that libdrm uses is 64bits, and you need
> to emit the full presumed address (and correctly shifted). Atm the kernel
> never gives you a presumed reloc offset with the high bits set so it
> doesn't matter. But I'd prefer if we don't need to make this opt-in
> behaviour once we enable address spaces with more than 4G.
> 
> i-g-t gets away with the cheap hack since we're allowed to break igt.
> Let me check ddx and libva whether I've lost this fight already ...
> -Daniel

I'm more than happy to do the right thing, I just don't know what that
is.  I don't see any uint64_t values in the interface we use at all:

OUT_RELOC becomes
   ret = drm_intel_bo_emit_reloc(brw->batch.bo, 4*brw->batch.used,
 buffer, delta,
 read_domains, write_domain);

which is:

static int
drm_intel_gem_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
drm_intel_bo *target_bo, uint32_t target_offset,
uint32_t read_domains, uint32_t write_domain)

...all 32-bit values.  It sounds like you're thinking we use Chris's
"let's presume it hasn't moved since last time" relocation stuff?  We
don't (at least not yet)...

I'm more than happy to take suggestions.

--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] llvmpipe: get rid of barycentric calculation of a0

[sroland]

From: Roland Scheidegger 

Didn't really work as well as hoped (in particular it was not generally
more accurate), will solve this differently.
---
 src/gallium/drivers/llvmpipe/lp_state_setup.c |   70 ++---
 1 file changed, 4 insertions(+), 66 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_state_setup.c 
b/src/gallium/drivers/llvmpipe/lp_state_setup.c
index 9c17d76..1d79a4a 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_setup.c
@@ -49,16 +49,6 @@
 #include "lp_state_fs.h"
 #include "lp_state_setup.h"
 
-/*
- * Set if the start point for interpolation should be calculated with a
- * more accurate method (barycentric interpolation).
- * Unfortunately, actual interpolation results of small tris with steep
- * gradients far away from the origin are still very busted, this does
- * nothing to change that (in fact it may make it worse), but some tests
- * (don't ask) really want accurate values at origin (and ONLY origin).
- */
-#define ACCURATE_A0 0
-
 
 /* currently organized to interpolate full float[4] attributes even
  * when some elements are unused.  Later, can pack vertex data more
@@ -86,9 +76,6 @@ struct lp_setup_args
LLVMValueRef dy01_ooa;
LLVMValueRef dx20_ooa;
LLVMValueRef dx01_ooa;
-   LLVMValueRef e01o;
-   LLVMValueRef e20o;
-   LLVMValueRef e12o;
struct lp_build_context bld;
 };
 
@@ -410,7 +397,6 @@ emit_coef4( struct gallivm_state *gallivm,
 LLVMValueRef a2)
 {
LLVMBuilderRef b = gallivm->builder;
-   bool accurate_a0 = ACCURATE_A0;
LLVMValueRef attr_0;
LLVMValueRef dy20_ooa = args->dy20_ooa;
LLVMValueRef dy01_ooa = args->dy01_ooa;
@@ -435,19 +421,10 @@ emit_coef4( struct gallivm_state *gallivm,
 
/* Calculate a0 - the attribute value at the origin
 */
-   if (!accurate_a0) {
-  LLVMValueRef dadx_x0= LLVMBuildFMul(b, dadx, x0_center, "dadx_x0");
-  LLVMValueRef dady_y0= LLVMBuildFMul(b, dady, y0_center, "dady_y0");
-  LLVMValueRef attr_v0= LLVMBuildFAdd(b, dadx_x0, dady_y0, "attr_v0");
-  attr_0  = LLVMBuildFSub(b, a0, attr_v0, "attr_0");
-   }
-   else {
-  LLVMValueRef ao2 = LLVMBuildFMul(b, args->e01o, a2, "");
-  LLVMValueRef ao1 = LLVMBuildFMul(b, args->e20o, a1, "");
-  LLVMValueRef ao0 = LLVMBuildFMul(b, args->e12o, a0, "");
-  attr_0 = LLVMBuildFAdd(b, ao0, ao1, "");
-  attr_0 = LLVMBuildFAdd(b, attr_0, ao2, "");
-   }
+   LLVMValueRef dadx_x0= LLVMBuildFMul(b, dadx, x0_center, "dadx_x0");
+   LLVMValueRef dady_y0= LLVMBuildFMul(b, dady, y0_center, "dady_y0");
+   LLVMValueRef attr_v0= LLVMBuildFAdd(b, dadx_x0, dady_y0, "attr_v0");
+   attr_0  = LLVMBuildFSub(b, a0, attr_v0, "attr_0");
 
store_coef(gallivm, args, slot, attr_0, dadx, dady);
 }
@@ -663,7 +640,6 @@ init_args(struct gallivm_state *gallivm,
LLVMValueRef attr_pos[3];
struct lp_type typef4 = lp_type_float_vec(32, 128);
struct lp_build_context bld;
-   bool accurate_a0 = ACCURATE_A0;
 
lp_build_context_init(&bld, gallivm, typef4);
args->bld = bld;
@@ -708,44 +684,6 @@ init_args(struct gallivm_state *gallivm,
dxy20 = LLVMBuildFMul(b, dxy20, ooa, "");
dxy01 = LLVMBuildFMul(b, dxy01, ooa, "");
 
-   if (accurate_a0) {
-  LLVMValueRef xy1xy2, xy1xy2_center, dxy12, dyx01, dyx12yx20;
-  LLVMValueRef p0, p1p2, tmp0, tmp1, shuf0145, shuf1054, shuf1u3u;
-
-  shuffles[0] = zeroi;
-  shuffles[1] = onei;
-  shuffles[2] = lp_build_const_int32(gallivm, 4);
-  shuffles[3] = lp_build_const_int32(gallivm, 5);
-  shuf0145 = LLVMConstVector(shuffles, 4);
-  shuffles[0] = onei;
-  shuffles[1] = zeroi;
-  shuffles[2] = lp_build_const_int32(gallivm, 5);
-  shuffles[3] = lp_build_const_int32(gallivm, 4);
-  shuf1054 = LLVMConstVector(shuffles, 4);
-  shuffles[0] = onei;
-  shuffles[1] = LLVMGetUndef(shuf_type);
-  shuffles[2] = lp_build_const_int32(gallivm, 3);
-  shuffles[3] = LLVMGetUndef(shuf_type);
-  shuf1u3u = LLVMConstVector(shuffles, 4);
-
-  xy1xy2 = LLVMBuildShuffleVector(b, attr_pos[1], attr_pos[2], shuf0145, 
"");
-  xy1xy2_center = LLVMBuildFSub(b, xy1xy2, pixel_center, "");
-  dxy12 = LLVMBuildFSub(b, attr_pos[1], attr_pos[2], "dxy12");
-  dxy12 = LLVMBuildFMul(b, dxy12, ooa, "");
-  dyx12yx20 = LLVMBuildShuffleVector(b, dxy12, dxy20, shuf1054, 
"dyx12yx20");
-  dyx01 = LLVMBuildShuffleVector(b, dxy01, dxy01, shuf10, "");
-  p0 = LLVMBuildFMul(b, dyx01, xy0_center, "");
-  p1p2 = LLVMBuildFMul(b, dyx12yx20, xy1xy2_center, "");
-  tmp0 = LLVMBuildExtractElement(b, p0, zeroi, "");
-  tmp1 = LLVMBuildExtractElement(b, p0, onei, "");
-  args->e01o = lp_build_broadcast_scalar(&bld, LLVMBuildFSub(b, tmp0, 
tmp1, "e01o"));
-  tmp1 = LLVMBuildShuffleVector(b, p1p2, p1p2, shuf1u3u, "");
-  tmp0 = LLVMBuildFSub(b, p1p2, tmp1, "e12o20o");
-  args->e12o = lp_build_e

Re: [Mesa-dev] [PATCH] llvmpipe: get rid of barycentric calculation of a0

[Jose Fonseca]

- Original Message -
> From: Roland Scheidegger 
> 
> Didn't really work as well as hoped (in particular it was not generally
> more accurate), will solve this differently.
> ---
>  src/gallium/drivers/llvmpipe/lp_state_setup.c |   70
>  ++---
>  1 file changed, 4 insertions(+), 66 deletions(-)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_state_setup.c
> b/src/gallium/drivers/llvmpipe/lp_state_setup.c
> index 9c17d76..1d79a4a 100644
> --- a/src/gallium/drivers/llvmpipe/lp_state_setup.c
> +++ b/src/gallium/drivers/llvmpipe/lp_state_setup.c
> @@ -49,16 +49,6 @@
>  #include "lp_state_fs.h"
>  #include "lp_state_setup.h"
>  
> -/*
> - * Set if the start point for interpolation should be calculated with a
> - * more accurate method (barycentric interpolation).
> - * Unfortunately, actual interpolation results of small tris with steep
> - * gradients far away from the origin are still very busted, this does
> - * nothing to change that (in fact it may make it worse), but some tests
> - * (don't ask) really want accurate values at origin (and ONLY origin).
> - */
> -#define ACCURATE_A0 0
> -
>  
>  /* currently organized to interpolate full float[4] attributes even
>   * when some elements are unused.  Later, can pack vertex data more
> @@ -86,9 +76,6 @@ struct lp_setup_args
> LLVMValueRef dy01_ooa;
> LLVMValueRef dx20_ooa;
> LLVMValueRef dx01_ooa;
> -   LLVMValueRef e01o;
> -   LLVMValueRef e20o;
> -   LLVMValueRef e12o;
> struct lp_build_context bld;
>  };
>  
> @@ -410,7 +397,6 @@ emit_coef4( struct gallivm_state *gallivm,
>  LLVMValueRef a2)
>  {
> LLVMBuilderRef b = gallivm->builder;
> -   bool accurate_a0 = ACCURATE_A0;
> LLVMValueRef attr_0;
> LLVMValueRef dy20_ooa = args->dy20_ooa;
> LLVMValueRef dy01_ooa = args->dy01_ooa;
> @@ -435,19 +421,10 @@ emit_coef4( struct gallivm_state *gallivm,
>  
> /* Calculate a0 - the attribute value at the origin
>  */
> -   if (!accurate_a0) {
> -  LLVMValueRef dadx_x0= LLVMBuildFMul(b, dadx, x0_center,
> "dadx_x0");
> -  LLVMValueRef dady_y0= LLVMBuildFMul(b, dady, y0_center,
> "dady_y0");
> -  LLVMValueRef attr_v0= LLVMBuildFAdd(b, dadx_x0, dady_y0,
> "attr_v0");
> -  attr_0  = LLVMBuildFSub(b, a0, attr_v0, "attr_0");
> -   }
> -   else {
> -  LLVMValueRef ao2 = LLVMBuildFMul(b, args->e01o, a2, "");
> -  LLVMValueRef ao1 = LLVMBuildFMul(b, args->e20o, a1, "");
> -  LLVMValueRef ao0 = LLVMBuildFMul(b, args->e12o, a0, "");
> -  attr_0 = LLVMBuildFAdd(b, ao0, ao1, "");
> -  attr_0 = LLVMBuildFAdd(b, attr_0, ao2, "");
> -   }
> +   LLVMValueRef dadx_x0= LLVMBuildFMul(b, dadx, x0_center, "dadx_x0");
> +   LLVMValueRef dady_y0= LLVMBuildFMul(b, dady, y0_center, "dady_y0");
> +   LLVMValueRef attr_v0= LLVMBuildFAdd(b, dadx_x0, dady_y0, "attr_v0");
> +   attr_0  = LLVMBuildFSub(b, a0, attr_v0, "attr_0");
>  
> store_coef(gallivm, args, slot, attr_0, dadx, dady);
>  }
> @@ -663,7 +640,6 @@ init_args(struct gallivm_state *gallivm,
> LLVMValueRef attr_pos[3];
> struct lp_type typef4 = lp_type_float_vec(32, 128);
> struct lp_build_context bld;
> -   bool accurate_a0 = ACCURATE_A0;
>  
> lp_build_context_init(&bld, gallivm, typef4);
> args->bld = bld;
> @@ -708,44 +684,6 @@ init_args(struct gallivm_state *gallivm,
> dxy20 = LLVMBuildFMul(b, dxy20, ooa, "");
> dxy01 = LLVMBuildFMul(b, dxy01, ooa, "");
>  
> -   if (accurate_a0) {
> -  LLVMValueRef xy1xy2, xy1xy2_center, dxy12, dyx01, dyx12yx20;
> -  LLVMValueRef p0, p1p2, tmp0, tmp1, shuf0145, shuf1054, shuf1u3u;
> -
> -  shuffles[0] = zeroi;
> -  shuffles[1] = onei;
> -  shuffles[2] = lp_build_const_int32(gallivm, 4);
> -  shuffles[3] = lp_build_const_int32(gallivm, 5);
> -  shuf0145 = LLVMConstVector(shuffles, 4);
> -  shuffles[0] = onei;
> -  shuffles[1] = zeroi;
> -  shuffles[2] = lp_build_const_int32(gallivm, 5);
> -  shuffles[3] = lp_build_const_int32(gallivm, 4);
> -  shuf1054 = LLVMConstVector(shuffles, 4);
> -  shuffles[0] = onei;
> -  shuffles[1] = LLVMGetUndef(shuf_type);
> -  shuffles[2] = lp_build_const_int32(gallivm, 3);
> -  shuffles[3] = LLVMGetUndef(shuf_type);
> -  shuf1u3u = LLVMConstVector(shuffles, 4);
> -
> -  xy1xy2 = LLVMBuildShuffleVector(b, attr_pos[1], attr_pos[2], shuf0145,
> "");
> -  xy1xy2_center = LLVMBuildFSub(b, xy1xy2, pixel_center, "");
> -  dxy12 = LLVMBuildFSub(b, attr_pos[1], attr_pos[2], "dxy12");
> -  dxy12 = LLVMBuildFMul(b, dxy12, ooa, "");
> -  dyx12yx20 = LLVMBuildShuffleVector(b, dxy12, dxy20, shuf1054,
> "dyx12yx20");
> -  dyx01 = LLVMBuildShuffleVector(b, dxy01, dxy01, shuf10, "");
> -  p0 = LLVMBuildFMul(b, dyx01, xy0_center, "");
> -  p1p2 = LLVMBuildFMul(b, dyx12yx20, xy1xy2_center, "");
> -  tmp0 = LLVMBuildExtractElement(b, p0, zeroi, "");
> -  tmp1 = LLVMBuildExtractE

Re: [Mesa-dev] [PATCH 1/9] st/mesa: always prefer pipe->clear over clear_with_quad

[Roland Scheidegger]

I agree that this seems to be pretty bad if you have interleaved
depth/stencil buffers (and no way to fast-clear them independently),
though I wonder which apps actually hit this? It looks to me like the
conditions you'd hit quad clear with one of depth/stencil but normal
clear with the other are fairly obscure (partial stencil write mask, or
rbs with different size and scissor set in a way so the scissor bounds
hit one but not the other). Which of course begs the question where that
change made a difference in the first place.

Roland

Am 13.12.2013 17:46, schrieb Jose Fonseca:
> What you mean by "fast clear"?
> 
> llvmpipe depth-stencil buffers are interleaved, and AFAICT partial clears 
> will be done with quads.  In other words, this will make llvmpipe slower.
> 
> In truth, this will all drivers with interleaved z/s bufferss slower.  That 
> is, this is optimizing for some drivers at expense of others which might have 
> interleaved depth-stencil buffer.  The very fact that it is worthwhile doing 
> this change for your gpu means that it must be worthwhile for others to leave 
> it as it was...
> 
> So, if this provides a significant performance difference, then I think the 
> only option to have everybody happy is to have cap to choose the optimal 
> behavior.
> 
> Jose
> 
> - Original Message -
>> It will only be worse for combined Z-stencil buffers if Z and
>> stencil are interleaved, and if SW rasterizers don't support any kind
>> of fast clear.
>>
>> Marek
>>
>> On Fri, Dec 13, 2013 at 3:21 PM, Jose Fonseca  wrote:
>>> This is worse for SW renderers...
>>>
>>> Jose
>>>
>>> - Original Message -
 From: Marek Olšák 

 ---
  src/mesa/state_tracker/st_cb_clear.c | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

 diff --git a/src/mesa/state_tracker/st_cb_clear.c
 b/src/mesa/state_tracker/st_cb_clear.c
 index 887e58b..46f2f8d 100644
 --- a/src/mesa/state_tracker/st_cb_clear.c
 +++ b/src/mesa/state_tracker/st_cb_clear.c
 @@ -476,14 +476,16 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
}
 }

 -   /*
 -* If we're going to use clear_with_quad() for any reason, use it for
 -* everything possible.
 +   /* Only use quad-based clearing for the renderbuffers which cannot
 +* use pipe->clear. We want to always use pipe->clear for the other
 +* renderbuffers, because it's likely to be faster. Even if there is
 +* a combined depth-stencil buffer, the depth and stencil components
 +* may be stored separately internally.
  */
 if (quad_buffers) {
 -  quad_buffers |= clear_buffers;
clear_with_quad(ctx, quad_buffers);
 -   } else if (clear_buffers) {
 +   }
 +   if (clear_buffers) {
/* We can't translate the clear color to the colorbuffer format,
 * because different colorbuffers may have different formats.
 */
 --
 1.8.3.2

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cvIgdPYPFAOCEZnN3p40o7cbw0cTfSQzytP%2Byju9mDI%3D%0A&s=b1c126addd7be0ac34d91039bb019dabb14c976597b451daa14f440755d95f14

>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=eR6SFsBDzw4W2%2Bl2SHXk12%2Fvz46iKWv1ohQNKFy4yiY%3D%0A&s=ad761b9846d926b7e49bdd0847c1846c0ae4f9f7002a4217a0c2a552f29b6b14
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Continuous Integration

[Yomi Ogunwumi]

I got it sort of running on Jenkins, on the master branch.

I can't have it build all the way through, because I'm a bit worried it'll
try to overwrite my currently installed version of Mesa on my system.

But it does tell me :

Run 'make' to build Mesa

Finished: SUCCESS

I'm guessing tests have to be written, but I don't code, so I'm a little
uncertain as to what should be done now.

I think I should let someone with a bit more knowledge of build systems
take a look.

Suggestions, Tom?

Yomi
On Oct 24, 2013 2:39 PM, "Yomi Ogunwumi"  wrote:

> I apologize. I'm in way over my head. I thought this would be easy for
> some reason but it seems I thought wrong. I'm going to step back and wrap
> my head around all of this...
>
> Yomi
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/9] st/mesa: always prefer pipe->clear over clear_with_quad

[Marek Olšák]

I'll add a cap then.

The fast clear is a technique that doesn't actually clear memory.
Instead, it postpones clearing until later time in hope that the
cleared area will be overdrawn anyway and no clearing will have to be
done. The idea is to have a clear/non-cleared 1-bit flag per tile.
Instead of clearing the renderbuffer, you just clear the flags and
save the clear value in the renderbuffer structure, because that's the
only way to remember it. If the tile state is "non-cleared", the tile
contains valid pixels. If the tile state is "cleared", the tile
contains garbage and any reads from the renderbuffer should return the
saved clear value (e.g. for blending or depth/stencil testing).

If you render a primitive and the primitive covers an entire tile, you
draw new pixels and set the tile state to non-cleared (= the tile has
valid pixels). In this case you avoid clearing entirely. If there is a
primitive edge intersecting a tile, you draw new pixels for that
primitive and then you also have to write the saved clear value to the
other pixels which are outside of the primitive. After that, you also
set the tile state to non-cleared (= the tile has valid pixels).
That's how you do rendering and avoid clearing. If you have to map the
renderbuffer or put it on the screen, you must clear the tiles which
are still in the cleared state (= the tile has invalid pixels) by
explicitly writing the clear value to those tiles. This also implies
that you can have only one clear value per renderbuffer.

Marek

On Fri, Dec 13, 2013 at 5:46 PM, Jose Fonseca  wrote:
> What you mean by "fast clear"?
>
> llvmpipe depth-stencil buffers are interleaved, and AFAICT partial clears 
> will be done with quads.  In other words, this will make llvmpipe slower.
>
> In truth, this will all drivers with interleaved z/s bufferss slower.  That 
> is, this is optimizing for some drivers at expense of others which might have 
> interleaved depth-stencil buffer.  The very fact that it is worthwhile doing 
> this change for your gpu means that it must be worthwhile for others to leave 
> it as it was...
>
> So, if this provides a significant performance difference, then I think the 
> only option to have everybody happy is to have cap to choose the optimal 
> behavior.
>
> Jose
>
> - Original Message -
>> It will only be worse for combined Z-stencil buffers if Z and
>> stencil are interleaved, and if SW rasterizers don't support any kind
>> of fast clear.
>>
>> Marek
>>
>> On Fri, Dec 13, 2013 at 3:21 PM, Jose Fonseca  wrote:
>> > This is worse for SW renderers...
>> >
>> > Jose
>> >
>> > - Original Message -
>> >> From: Marek Olšák 
>> >>
>> >> ---
>> >>  src/mesa/state_tracker/st_cb_clear.c | 12 +++-
>> >>  1 file changed, 7 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/src/mesa/state_tracker/st_cb_clear.c
>> >> b/src/mesa/state_tracker/st_cb_clear.c
>> >> index 887e58b..46f2f8d 100644
>> >> --- a/src/mesa/state_tracker/st_cb_clear.c
>> >> +++ b/src/mesa/state_tracker/st_cb_clear.c
>> >> @@ -476,14 +476,16 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
>> >>}
>> >> }
>> >>
>> >> -   /*
>> >> -* If we're going to use clear_with_quad() for any reason, use it for
>> >> -* everything possible.
>> >> +   /* Only use quad-based clearing for the renderbuffers which cannot
>> >> +* use pipe->clear. We want to always use pipe->clear for the other
>> >> +* renderbuffers, because it's likely to be faster. Even if there is
>> >> +* a combined depth-stencil buffer, the depth and stencil components
>> >> +* may be stored separately internally.
>> >>  */
>> >> if (quad_buffers) {
>> >> -  quad_buffers |= clear_buffers;
>> >>clear_with_quad(ctx, quad_buffers);
>> >> -   } else if (clear_buffers) {
>> >> +   }
>> >> +   if (clear_buffers) {
>> >>/* We can't translate the clear color to the colorbuffer format,
>> >> * because different colorbuffers may have different formats.
>> >> */
>> >> --
>> >> 1.8.3.2
>> >>
>> >> ___
>> >> mesa-dev mailing list
>> >> mesa-dev@lists.freedesktop.org
>> >> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cvIgdPYPFAOCEZnN3p40o7cbw0cTfSQzytP%2Byju9mDI%3D%0A&s=b1c126addd7be0ac34d91039bb019dabb14c976597b451daa14f440755d95f14
>> >>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/2 v3] i965: Extend fast texture upload

[Courtney Goeltzenleuchter]

This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full miptrees where were found to be common activities
in the Smokin' Guns game. The issue was found while profiling the app
but that part is not benchmarked. Smokin-Guns uses mipmap textures with
an internal format of GL_RGB (MESA_XRGB_ in the driver).

These changes need a performance tool to run against to show how they
improve execution performance for specific texture formats. Using this
benchmark I've measured the following improvement on my Ivybridge
Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.

Using 1024x1024, RGBA  source, mipmap
internal-format Before (MB/sec) After XRGB (MB/sec) After mip (MB/sec)
GL_RGBA 628.15  627.15  615.90
GL_RGB  265.95  456.35  611.53

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage_enh

Includes all feedback from gurket...@googlemail.com, matts...@gmail.com,
chad.vers...@linux.intel.com and e...@anholt.net.

Courtney Goeltzenleuchter (2):
  i965: add XRGB to tiled_memcpy
  i965: Enhance tiled_memcpy to support all levels

Courtney Goeltzenleuchter (2):
  i965: add XRGB to tiled_memcpy
  i965: Enhance tiled_memcpy to support all levels

 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] i965: add XRGB to tiled_memcpy

[Courtney Goeltzenleuchter]

MESA_FORMAT_XRGB is equivalent to MESA_FORMAT_ARGB in terms
of storage on the device, so okay to use this optimized copy routine.

This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full miptrees where were found to be common activities
in the Smokin' Guns game. The issue was found while profiling the app
but that part is not benchmarked. Smokin-Guns uses mipmap textures with
an internal format of GL_RGB (MESA_XRGB_ in the driver).

These changes need a performance tool to run against to show how they
improve execution performance for specific texture formats. Using this
benchmark I've measured the following improvement on my Ivybridge
Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.

1024x1024 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 628.15  627.15
GL_RGB  265.95  456.35

512x512 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 600.23  597.00
GL_RGB  255.50  440.62

256x256 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 489.08  487.80
GL_RGB  229.03  376.63

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage

--
1.8.1.2

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index a72d313..c12cf94 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -577,7 +577,8 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
(texImage->TexFormat == MESA_FORMAT_A8 && format == GL_ALPHA)) {
   cpp = 1;
   mem_copy = memcpy;
-   } else if (texImage->TexFormat == MESA_FORMAT_ARGB) {
+   } else if ((texImage->TexFormat == MESA_FORMAT_ARGB)
+ || (texImage->TexFormat == MESA_FORMAT_XRGB)) {
   cpp = 4;
   if (format == GL_BGRA) {
  mem_copy = memcpy;
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] i965: Enhance tiled_memcpy to support all levels

[Courtney Goeltzenleuchter]

Support all levels of a supported texture format.

Using 1024x1024, RGBA  source, mipmap
internal-format Before (MB/sec) mipmap (MB/sec)
GL_RGBA 627.15  615.90
GL_RGB  456.35  611.53
512x512
GL_RGBA 597.00  619.95
GL_RGB  440.62  611.28
256x256
GL_RGBA 487.80  587.42
GL_RGB  376.63  585.00

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage_enh

--
1.8.1.2

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index c12cf94..1642f3c 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -549,7 +549,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
uint32_t cpp;
mem_copy_fn mem_copy = NULL;
 
-   /* This fastpath is restricted to specific texture types: level 0 of
+   /* This fastpath is restricted to specific texture types:
 * a 2D BGRA, RGBA, L8 or A8 texture. It could be generalized to support
 * more types.
 *
@@ -561,7 +561,6 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
if (!brw->has_llc ||
type != GL_UNSIGNED_BYTE ||
texImage->TexObject->Target != GL_TEXTURE_2D ||
-   texImage->Level != 0 ||
pixels == NULL ||
_mesa_is_bufferobj(packing->BufferObj) ||
packing->Alignment > 4 ||
@@ -637,6 +636,10 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing->Alignment, packing->RowLength, packing->SkipPixels,
packing->SkipRows, for_glTexImage);
 
+   /* Adjust x and y offset based on miplevel */
+   xoffset += image->mt->level[texImage->Level].level_x;
+   yoffset += image->mt->level[texImage->Level].level_y;
+
linear_to_tiled(
   xoffset * cpp, (xoffset + width) * cpp,
   yoffset, yoffset + height,
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72582] [swrast] piglit getteximage-targets S3TC 2D_ARRAY regression

[bugzilla-daemon]

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

--- Comment #1 from Ian Romanick  ---
I haven't look at this test (and for some reason it doesn't show up in my
piglit runs), but I suspect this is the same issue at the copyteximage test. 
copyteximage tries to use array textures with fixed-function, but that's not
allowed.  Does "getteximage-targets S3TC 2D_ARRAY" pass on other GL
implementations?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallivm: fix pointer type for stmxcsr/ldmxcsr

[sroland]

From: Roland Scheidegger 

The argument is a i8 pointer not a i32 pointer (even though the value actually
stored/loaded IS i32). Older llvm versions didn't care but 3.2 and newer do
leading to crashes.
---
 src/gallium/auxiliary/gallivm/lp_bld_arit.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index 440dd0b..e516ae8 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -3510,10 +3510,12 @@ lp_build_fpstate_get(struct gallivm_state *gallivm)
  gallivm,
  LLVMInt32TypeInContext(gallivm->context),
  "mxcsr_ptr");
+  LLVMValueRef mxcsr_ptr8 = LLVMBuildPointerCast(builder, mxcsr_ptr,
+  LLVMPointerType(LLVMInt8TypeInContext(gallivm->context), 0), "");
   lp_build_intrinsic(builder,
  "llvm.x86.sse.stmxcsr",
  LLVMVoidTypeInContext(gallivm->context),
- &mxcsr_ptr, 1);
+ &mxcsr_ptr8, 1);
   return mxcsr_ptr;
}
return 0;
@@ -3554,7 +3556,10 @@ lp_build_fpstate_set(struct gallivm_state *gallivm,
  LLVMValueRef mxcsr_ptr)
 {
if (util_cpu_caps.has_sse) {
-  lp_build_intrinsic(gallivm->builder,
+  LLVMBuilderRef builder = gallivm->builder;
+  mxcsr_ptr = LLVMBuildPointerCast(builder, mxcsr_ptr,
+ LLVMPointerType(LLVMInt8TypeInContext(gallivm->context), 
0), "");
+  lp_build_intrinsic(builder,
  "llvm.x86.sse.ldmxcsr",
  LLVMVoidTypeInContext(gallivm->context),
  &mxcsr_ptr, 1);
-- 
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72582] [swrast] piglit getteximage-targets S3TC 2D_ARRAY regression

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|Other   |Mesa core

--- Comment #2 from Ian Romanick  ---
Nope.  The problem is in meta.  I'll see if I can come up with a fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] st/mesa: simplify integer texture check

[Brian Paul]

Just use the gl_texture_object::_IsInteger field instead of
computing it from scratch.
---
 src/mesa/state_tracker/st_atom_sampler.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_sampler.c 
b/src/mesa/state_tracker/st_atom_sampler.c
index 302e129..989e42c 100644
--- a/src/mesa/state_tracker/st_atom_sampler.c
+++ b/src/mesa/state_tracker/st_atom_sampler.c
@@ -170,21 +170,18 @@ convert_sampler(struct st_context *st,
   assert(sampler->min_lod <= sampler->max_lod);
}
 
+   /* For non-black borders... */
if (msamp->BorderColor.ui[0] ||
msamp->BorderColor.ui[1] ||
msamp->BorderColor.ui[2] ||
msamp->BorderColor.ui[3]) {
   struct st_texture_object *stobj = st_texture_object(texobj);
   struct gl_texture_image *teximg;
-  GLboolean is_integer = GL_FALSE;
+  const GLboolean is_integer = texobj->_IsIntegerFormat;
   union pipe_color_union border_color;
 
   teximg = texobj->Image[0][texobj->BaseLevel];
 
-  if (teximg) {
- is_integer = _mesa_is_enum_format_integer(teximg->InternalFormat);
-  }
-
   if (st->apply_texture_swizzle_to_border_color && stobj->sampler_view) {
  const unsigned char swz[4] =
  {
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] st/mesa: add const qualifier to st_translate_color()

[Brian Paul]

---
 src/mesa/state_tracker/st_format.c |6 +++---
 src/mesa/state_tracker/st_format.h |2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_format.c 
b/src/mesa/state_tracker/st_format.c
index ec25523..6acf983 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -1854,12 +1854,12 @@ st_QuerySamplesForFormat(struct gl_context *ctx, GLenum 
target,
  * Similarly for texture border colors.
  */
 void
-st_translate_color(union gl_color_union *colorIn,
+st_translate_color(const union gl_color_union *colorIn,
union pipe_color_union *colorOut,
GLenum baseFormat, GLboolean is_integer)
 {
if (is_integer) {
-  int *in = colorIn->i;
+  const int *in = colorIn->i;
   int *out = colorOut->i;
 
   switch (baseFormat) {
@@ -1901,7 +1901,7 @@ st_translate_color(union gl_color_union *colorIn,
   }
}
else {
-  float *in = colorIn->f;
+  const float *in = colorIn->f;
   float *out = colorOut->f;
 
   switch (baseFormat) {
diff --git a/src/mesa/state_tracker/st_format.h 
b/src/mesa/state_tracker/st_format.h
index 6e97dcb..3278748 100644
--- a/src/mesa/state_tracker/st_format.h
+++ b/src/mesa/state_tracker/st_format.h
@@ -73,7 +73,7 @@ st_QuerySamplesForFormat(struct gl_context *ctx, GLenum 
target,
 
 
 extern void
-st_translate_color(union gl_color_union *colorIn,
+st_translate_color(const union gl_color_union *colorIn,
union pipe_color_union *colorOut,
GLenum baseFormat, GLboolean is_integer);
 
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] st/mesa: add const qualifiers in sampler validation code

[Brian Paul]

---
 src/mesa/state_tracker/st_atom_sampler.c |6 +++---
 src/mesa/state_tracker/st_texture.h  |6 ++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_sampler.c 
b/src/mesa/state_tracker/st_atom_sampler.c
index 989e42c..447788c 100644
--- a/src/mesa/state_tracker/st_atom_sampler.c
+++ b/src/mesa/state_tracker/st_atom_sampler.c
@@ -130,7 +130,7 @@ convert_sampler(struct st_context *st,
 struct pipe_sampler_state *sampler,
 GLuint texUnit)
 {
-   struct gl_texture_object *texobj;
+   const struct gl_texture_object *texobj;
struct gl_context *ctx = st->ctx;
struct gl_sampler_object *msamp;
 
@@ -175,8 +175,8 @@ convert_sampler(struct st_context *st,
msamp->BorderColor.ui[1] ||
msamp->BorderColor.ui[2] ||
msamp->BorderColor.ui[3]) {
-  struct st_texture_object *stobj = st_texture_object(texobj);
-  struct gl_texture_image *teximg;
+  const struct st_texture_object *stobj = st_texture_object_const(texobj);
+  const struct gl_texture_image *teximg;
   const GLboolean is_integer = texobj->_IsIntegerFormat;
   union pipe_color_union border_color;
 
diff --git a/src/mesa/state_tracker/st_texture.h 
b/src/mesa/state_tracker/st_texture.h
index c15aeae..ac93d96 100644
--- a/src/mesa/state_tracker/st_texture.h
+++ b/src/mesa/state_tracker/st_texture.h
@@ -112,6 +112,12 @@ st_texture_object(struct gl_texture_object *obj)
return (struct st_texture_object *) obj;
 }
 
+static INLINE const struct st_texture_object *
+st_texture_object_const(const struct gl_texture_object *obj)
+{
+   return (const struct st_texture_object *) obj;
+}
+
 
 static INLINE struct pipe_resource *
 st_get_texobj_resource(struct gl_texture_object *texObj)
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] st/mesa: only set up sampler compare mode for depth textures

[Brian Paul]

The GL_ARB_shadow spec says the shadow compare mode should have no
effect when sampling a color texture.  As it was, it was up to
drivers to check for that (softpipe, llvmpipe, svga and probably
the rest don't do that).  Note: it looks like DX10 allows shadow
compare with some non-depth formats, so this case really should be
handled in the state tracker.
---
 src/mesa/state_tracker/st_atom_sampler.c |   21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_sampler.c 
b/src/mesa/state_tracker/st_atom_sampler.c
index 447788c..57670ce 100644
--- a/src/mesa/state_tracker/st_atom_sampler.c
+++ b/src/mesa/state_tracker/st_atom_sampler.c
@@ -133,12 +133,17 @@ convert_sampler(struct st_context *st,
const struct gl_texture_object *texobj;
struct gl_context *ctx = st->ctx;
struct gl_sampler_object *msamp;
+   const struct gl_texture_image *teximg;
+   GLenum texBaseFormat;
 
texobj = ctx->Texture.Unit[texUnit]._Current;
if (!texobj) {
   texobj = _mesa_get_fallback_texture(ctx, TEXTURE_2D_INDEX);
}
 
+   teximg = texobj->Image[0][texobj->BaseLevel];
+   texBaseFormat = teximg ? teximg->_BaseFormat : GL_RGBA;
+
msamp = _mesa_get_samplerobj(ctx, texUnit);
 
memset(sampler, 0, sizeof(*sampler));
@@ -176,12 +181,9 @@ convert_sampler(struct st_context *st,
msamp->BorderColor.ui[2] ||
msamp->BorderColor.ui[3]) {
   const struct st_texture_object *stobj = st_texture_object_const(texobj);
-  const struct gl_texture_image *teximg;
   const GLboolean is_integer = texobj->_IsIntegerFormat;
   union pipe_color_union border_color;
 
-  teximg = texobj->Image[0][texobj->BaseLevel];
-
   if (st->apply_texture_swizzle_to_border_color && stobj->sampler_view) {
  const unsigned char swz[4] =
  {
@@ -193,25 +195,26 @@ convert_sampler(struct st_context *st,
 
  st_translate_color(&msamp->BorderColor,
 &border_color,
-teximg ? teximg->_BaseFormat : GL_RGBA, 
is_integer);
+texBaseFormat, is_integer);
 
  util_format_apply_color_swizzle(&sampler->border_color,
  &border_color, swz, is_integer);
   } else {
  st_translate_color(&msamp->BorderColor,
 &sampler->border_color,
-teximg ? teximg->_BaseFormat : GL_RGBA, 
is_integer);
+texBaseFormat, is_integer);
   }
}
 
sampler->max_anisotropy = (msamp->MaxAnisotropy == 1.0 ?
   0 : (GLuint) msamp->MaxAnisotropy);
 
-   /* only care about ARB_shadow, not SGI shadow */
-   if (msamp->CompareMode == GL_COMPARE_R_TO_TEXTURE) {
+   /* If sampling a depth texture and using shadow comparison */
+   if ((texBaseFormat == GL_DEPTH_COMPONENT ||
+texBaseFormat == GL_DEPTH_STENCIL) &&
+   msamp->CompareMode == GL_COMPARE_R_TO_TEXTURE) {
   sampler->compare_mode = PIPE_TEX_COMPARE_R_TO_TEXTURE;
-  sampler->compare_func
- = st_compare_func_to_pipe(msamp->CompareFunc);
+  sampler->compare_func = st_compare_func_to_pipe(msamp->CompareFunc);
}
 
sampler->seamless_cube_map =
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72600] ES3 context returned when ES2 is requested

[bugzilla-daemon]

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

--- Comment #10 from Ian Romanick  ---
OpenGL ES 3.0 is intended to be almost completely backwards compatible with
OpenGL ES 2.0.  The only known incompatibilities are cubemap filtering (ES3
requires seamless filtering, but ES2 requires non-seamless) and whether or not
FBOs are shared.

If you discover what you believe to be an incompatibility, please report it to
Khronos as it represents a bug in the specification.

For the record, user-arrays (i.e., vertex data that is not stored in a VBO) is
still allowed in OpenGL ES 3.0.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72600] ES3 context returned when ES2 is requested

[bugzilla-daemon]

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

--- Comment #11 from org.freedesk...@io7m.com ---
Yes, those are the conclusions I came to as well.

The only issue here, then, is the minor irritation of the ES3 context not
setting
EGL_OPENGL_ES3_BIT_KHR. I think that's a conformance issue but I doubt anyone's
going to notice unless they're specifically validating contexts like that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: fix pointer type for stmxcsr/ldmxcsr

[Zack Rusin]

Looks good. Thanks Roland!

- Original Message -
> From: Roland Scheidegger 
> 
> The argument is a i8 pointer not a i32 pointer (even though the value
> actually
> stored/loaded IS i32). Older llvm versions didn't care but 3.2 and newer do
> leading to crashes.
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_arit.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> index 440dd0b..e516ae8 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> @@ -3510,10 +3510,12 @@ lp_build_fpstate_get(struct gallivm_state *gallivm)
>   gallivm,
>   LLVMInt32TypeInContext(gallivm->context),
>   "mxcsr_ptr");
> +  LLVMValueRef mxcsr_ptr8 = LLVMBuildPointerCast(builder, mxcsr_ptr,
> +  LLVMPointerType(LLVMInt8TypeInContext(gallivm->context), 0), "");
>lp_build_intrinsic(builder,
>   "llvm.x86.sse.stmxcsr",
>   LLVMVoidTypeInContext(gallivm->context),
> - &mxcsr_ptr, 1);
> + &mxcsr_ptr8, 1);
>return mxcsr_ptr;
> }
> return 0;
> @@ -3554,7 +3556,10 @@ lp_build_fpstate_set(struct gallivm_state *gallivm,
>   LLVMValueRef mxcsr_ptr)
>  {
> if (util_cpu_caps.has_sse) {
> -  lp_build_intrinsic(gallivm->builder,
> +  LLVMBuilderRef builder = gallivm->builder;
> +  mxcsr_ptr = LLVMBuildPointerCast(builder, mxcsr_ptr,
> +
> LLVMPointerType(LLVMInt8TypeInContext(gallivm->context),
> 0), "");
> +  lp_build_intrinsic(builder,
>   "llvm.x86.sse.ldmxcsr",
>   LLVMVoidTypeInContext(gallivm->context),
>   &mxcsr_ptr, 1);
> --
> 1.7.9.5
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72600] ES3 context returned when ES2 is requested

[bugzilla-daemon]

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

--- Comment #12 from Jordan Justen  ---
(In reply to comment #11)
> The only issue here, then, is the minor irritation of
> the ES3 context not setting EGL_OPENGL_ES3_BIT_KHR.
> I think that's a conformance issue but I doubt anyone's
> going to notice unless they're specifically validating
> contexts like that.

Is a piglit test needed then?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] st/mesa: only set up sampler compare mode for depth textures

[Roland Scheidegger]

Am 13.12.2013 21:32, schrieb Brian Paul:
> The GL_ARB_shadow spec says the shadow compare mode should have no
> effect when sampling a color texture.  As it was, it was up to
> drivers to check for that (softpipe, llvmpipe, svga and probably
> the rest don't do that).  Note: it looks like DX10 allows shadow
> compare with some non-depth formats, so this case really should be
> handled in the state tracker.
> ---
>  src/mesa/state_tracker/st_atom_sampler.c |   21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_atom_sampler.c 
> b/src/mesa/state_tracker/st_atom_sampler.c
> index 447788c..57670ce 100644
> --- a/src/mesa/state_tracker/st_atom_sampler.c
> +++ b/src/mesa/state_tracker/st_atom_sampler.c
> @@ -133,12 +133,17 @@ convert_sampler(struct st_context *st,
> const struct gl_texture_object *texobj;
> struct gl_context *ctx = st->ctx;
> struct gl_sampler_object *msamp;
> +   const struct gl_texture_image *teximg;
> +   GLenum texBaseFormat;
>  
> texobj = ctx->Texture.Unit[texUnit]._Current;
> if (!texobj) {
>texobj = _mesa_get_fallback_texture(ctx, TEXTURE_2D_INDEX);
> }
>  
> +   teximg = texobj->Image[0][texobj->BaseLevel];
> +   texBaseFormat = teximg ? teximg->_BaseFormat : GL_RGBA;
> +
> msamp = _mesa_get_samplerobj(ctx, texUnit);
>  
> memset(sampler, 0, sizeof(*sampler));
> @@ -176,12 +181,9 @@ convert_sampler(struct st_context *st,
> msamp->BorderColor.ui[2] ||
> msamp->BorderColor.ui[3]) {
>const struct st_texture_object *stobj = 
> st_texture_object_const(texobj);
> -  const struct gl_texture_image *teximg;
>const GLboolean is_integer = texobj->_IsIntegerFormat;
>union pipe_color_union border_color;
>  
> -  teximg = texobj->Image[0][texobj->BaseLevel];
> -
>if (st->apply_texture_swizzle_to_border_color && stobj->sampler_view) {
>   const unsigned char swz[4] =
>   {
> @@ -193,25 +195,26 @@ convert_sampler(struct st_context *st,
>  
>   st_translate_color(&msamp->BorderColor,
>  &border_color,
> -teximg ? teximg->_BaseFormat : GL_RGBA, 
> is_integer);
> +texBaseFormat, is_integer);
>  
>   util_format_apply_color_swizzle(&sampler->border_color,
>   &border_color, swz, is_integer);
>} else {
>   st_translate_color(&msamp->BorderColor,
>  &sampler->border_color,
> -teximg ? teximg->_BaseFormat : GL_RGBA, 
> is_integer);
> +texBaseFormat, is_integer);
>}
> }
>  
> sampler->max_anisotropy = (msamp->MaxAnisotropy == 1.0 ?
>0 : (GLuint) msamp->MaxAnisotropy);
>  
> -   /* only care about ARB_shadow, not SGI shadow */
> -   if (msamp->CompareMode == GL_COMPARE_R_TO_TEXTURE) {
> +   /* If sampling a depth texture and using shadow comparison */
> +   if ((texBaseFormat == GL_DEPTH_COMPONENT ||
> +texBaseFormat == GL_DEPTH_STENCIL) &&
> +   msamp->CompareMode == GL_COMPARE_R_TO_TEXTURE) {
>sampler->compare_mode = PIPE_TEX_COMPARE_R_TO_TEXTURE;
> -  sampler->compare_func
> - = st_compare_func_to_pipe(msamp->CompareFunc);
> +  sampler->compare_func = st_compare_func_to_pipe(msamp->CompareFunc);
> }
>  
> sampler->seamless_cube_map =
> 

Series looks good to me. Note that d3d10 not just allows using non-depth
textures for comparison filter, but requires it (you can't sample depth
textures at all, they always use the corresponding color view - granted
the resource could be depth or not but that shouldn't matter).

Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 07/10] mesa: Implement functions for clear_buffer_object extensions

[Pi Tabred]

I tried to tackle this issue:
>> There is still the issue regarding the following:
>> According to the spec, it should be possible to clear some part of a
>> buffer, even if a different, non-overlapping part is mapped, this is
>> currently not possible. It was suggested to implement ClearBufferSubData
>> using MapBufferRange. However, this does not work if a part of the
>> buffer is already mapped.
>> I am not sure how to handle this. Maybe that's something that has to be
>> done inside the different drivers?

I used BufferSubData to transfer the data, however according to the spec
BufferSubData is only guaranteed to work if the complete buffer is
unmapped.

 - _mesa_buffer_clear_subdata: default callback for dd function table
 - _mesa_ClearBufferData: API function
 - _mesa_ClearBufferSubData: API function
 - validate_clear_buffer_format: helper function, check if the
internalformat,
   format and type parameter are legal
 - convert_clear_buffer_data: helper function, convert the supplied data
   to the desired internalformat.
---
 src/mesa/main/bufferobj.c | 259
++
 src/mesa/main/bufferobj.h |   4 +
 2 files changed, 263 insertions(+)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 1219891..fb09aa9 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -41,6 +41,9 @@
 #include "fbobject.h"
 #include "mtypes.h"
 #include "texobj.h"
+#include "teximage.h"
+#include "glformats.h"
+#include "texstore.h"
 #include "transformfeedback.h"
 #include "dispatch.h"

@@ -283,6 +286,96 @@ buffer_object_subdata_range_good(struct gl_context
* ctx, GLenum target,


 /**
+ * Test the format and type parameters and set the GL error code for
+ * \c glClearBufferData and \c glClearBufferSubData.
+ *
+ * \param ctx GL context.
+ * \param internalformat  Format to which the data is to be converted.
+ * \param format  Format of the supplied data.
+ * \param typeType of the supplied data.
+ * \param caller  Name of calling function for recording errors.
+ * \return   If internalformat, format and type are legal the gl_format
+ *   corresponding to internalformat, otherwise MESA_FORMAT_NONE.
+ *
+ * \sa glClearBufferData and glClearBufferSubData
+ */
+static gl_format
+validate_clear_buffer_format(struct gl_context *ctx,
+ GLenum internalformat,
+ GLenum format, GLenum type,
+ const char* caller)
+{
+   gl_format mesaFormat;
+   GLenum errorFormatType;
+
+   mesaFormat = _mesa_validate_texbuffer_format(ctx, internalformat);
+   if (mesaFormat == MESA_FORMAT_NONE) {
+  _mesa_error(ctx, GL_INVALID_ENUM,
+  "%s(invalid internalformat)", caller);
+  return MESA_FORMAT_NONE;
+   }
+
+   /* NOTE: not mentioned in ARB_clear_buffer_object but according to
+* EXT_texture_integer there is no conversion between integer and
+* non-integer formats
+   */
+   if (_mesa_is_enum_format_signed_int(format) !=
+   _mesa_is_format_integer_color(mesaFormat)) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "%s(integer vs non-integer)", caller);
+  return MESA_FORMAT_NONE;
+   }
+
+   if (!_mesa_is_color_format(format)) {
+  _mesa_error(ctx, GL_INVALID_ENUM,
+  "%s(format is not a color format)", caller);
+  return MESA_FORMAT_NONE;
+   }
+
+   errorFormatType = _mesa_error_check_format_and_type(ctx, format,
+   type);
+   if (errorFormatType != GL_NO_ERROR) {
+  _mesa_error(ctx, GL_INVALID_ENUM,
+  "%s(invalid format or type)", caller);
+  return MESA_FORMAT_NONE;
+   }
+
+   return mesaFormat;
+}
+
+
+/**
+ * Convert user-specified clear value to the specified internal format.
+ *
+ * \param ctx GL context.
+ * \param internalformat  Format to which the data is converted.
+ * \param clearValue  Pointer, store converted data here.
+ * \param format  Format of the supplied data.
+ * \param typeType of the supplied data.
+ * \param dataData which is to be converted to internalformat
+ *
+ * \sa glClearBufferData, glClearBufferSubData
+ */
+static void
+convert_clear_buffer_data(struct gl_context *ctx,
+  gl_format internalformat,
+  GLubyte *clearValue, GLenum format, GLenum type,
+  const GLvoid *data)
+{
+   GLenum internalformatBase;
+
+   internalformatBase = _mesa_get_format_base_format(internalformat);
+
+
+   GLboolean success = _mesa_texstore(ctx, 1, internalformatBase,
+  internalformat, 0, &clearValue,
+  1, 1, 1,
+  format, type, data, &ctx->Unpack);
+   assert(success);
+}
+
+
+/**
  * Allocate and initialize a new buffer object.
  *
  * Default 

Re: [Mesa-dev] [PATCH] mesa: update glext.h to version 20131212

[Kenneth Graunke]

On 12/12/2013 01:56 PM, Brian Paul wrote:
> ---
>  include/GL/glext.h |   68 
> ++--
>  1 file changed, 61 insertions(+), 7 deletions(-)
> 
> diff --git a/include/GL/glext.h b/include/GL/glext.h
> index fea9e1f..7d6033e 100644
> --- a/include/GL/glext.h
> +++ b/include/GL/glext.h
> @@ -33,7 +33,7 @@ extern "C" {
>  ** used to make the header, and the header can be found at
>  **   http://www.opengl.org/registry/
>  **
> -** Khronos $Revision: 23422 $ on $Date: 2013-10-08 15:40:45 -0700 (Tue, 08 
> Oct 2013) $
> +** Khronos $Revision: 24502 $ on $Date: 2013-12-12 13:14:39 -0800 (Thu, 12 
> Dec 2013) $
>  */

Updating this sounds good to me, and a quick skim didn't throw up any
red flags...

Acked-by: Kenneth Graunke 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/10] i965: Introduce an OUT_RELOC64 macro.

[Daniel Vetter]

On Fri, Dec 13, 2013 at 10:04:53AM -0800, Kenneth Graunke wrote:
> On 12/13/2013 09:28 AM, Daniel Vetter wrote:
> > On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
> >> Broadwell uses 48-bit addresses.  The first DWord is the low 32 bits,
> >> and the second DWord is the high 16 bits.
> >>
> >> Since individual buffers shouldn't be larger than 4GB in size, any
> >> offsets into those buffers (buffer->offset + delta) should fit in the
> >> low 32 bits.  So I believe we can simply emit 0 for the high 16-bits,
> >> and drm_intel_bo_emit_reloc() should patch it up.
> >>
> >> Signed-off-by: Kenneth Graunke 
> >> ---
> >>  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h 
> >> b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> >> index 159f928..128eed9 100644
> >> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> >> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> >> @@ -178,6 +178,11 @@ void intel_batchbuffer_cached_advance(struct 
> >> brw_context *brw);
> >>read_domains, write_domain, delta); \
> >>  } while (0)
> >>  
> >> +/* Handle 48-bit address relocations for Gen8+ */
> >> +#define OUT_RELOC64(buf, read_domains, write_domain, delta) \
> >> +   OUT_RELOC(buf, read_domains, write_domain, delta);   \
> >> +   OUT_BATCH(0);
> > 
> > Please not. The presumed_offset that libdrm uses is 64bits, and you need
> > to emit the full presumed address (and correctly shifted). Atm the kernel
> > never gives you a presumed reloc offset with the high bits set so it
> > doesn't matter. But I'd prefer if we don't need to make this opt-in
> > behaviour once we enable address spaces with more than 4G.
> > 
> > i-g-t gets away with the cheap hack since we're allowed to break igt.
> > Let me check ddx and libva whether I've lost this fight already ...
> > -Daniel
> 
> I'm more than happy to do the right thing, I just don't know what that
> is.  I don't see any uint64_t values in the interface we use at all:
> 
> OUT_RELOC becomes
>ret = drm_intel_bo_emit_reloc(brw->batch.bo, 4*brw->batch.used,
>  buffer, delta,
>  read_domains, write_domain);

This function here only adds the relocation entry to the batch buffer, so
that the kernel can fix stuff up in case anything moved. But you still
need to write the 64bit value into the batch itself, under the assumption
that the target buffer has not moved. For that the kernel tells you the
last offset in target_bo->presumed_offset. Of course you also need to add
the delta and all that.

On a very quick read (it's getting late here, please double check) you
need to add an OUT_RELOC64 and intel_batchbuffer_emit_reloc64. The call to
drm_intel_bo_emit_reloc stays the same, but you then need a new variant of
the function which writes the presumed reloc stuff into the batch, so a
new intel_batchbuffer_emit_qword which writes the 2 dwords for the reloc
entry.

> 
> which is:
> 
> static int
> drm_intel_gem_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
> drm_intel_bo *target_bo, uint32_t target_offset,
> uint32_t read_domains, uint32_t write_domain)
> 
> ...all 32-bit values.  It sounds like you're thinking we use Chris's
> "let's presume it hasn't moved since last time" relocation stuff?  We
> don't (at least not yet)...

The presumed_offset handling is all in libdrm and the above mentioned
stuff in OUT_RELOC. So I'm pretty sure you're using it ;-)

SNA on top uses a slightly different layout of the actual relocations
entries submitted to the kernel. The upshot of that is that the fastpath
can get a bit better (the kernel essentially ends up doing nothing besides
checking that all the objects are still at the same spot), the downside is
that userspace needs to follow stricter rules around emitting relocs and
reusing buffers. Last time I've chatted with Eric he said it's not worth
the trouble for mesa. Anyway, completely different topic.
 
> I'm more than happy to take suggestions.

Hope this helps.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

[Kenneth Graunke]

On 11/21/2013 08:12 PM, Keith Packard wrote:
> The __DRIimage createImageFromFds function takes a fourcc code, but there was
> no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
> that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
> __DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
> __IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.
> 
> I'll refrain from comments on whether I think having two separate sets of
> format defines in dri_interface.h is a good idea or not...
> 
> Signed-off-by: Keith Packard 
> ---
> 
> This gets iceweasel running with the GL compositor enabled.

I see a huge discussion about this patch, but it's not obvious to me
whether there were actual concerns or just people asking questions.

I see that Eric reviewed it, and that it has not landed.  Are there any
objections to merging it?

--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] dri3: Clean up struct dri3_drawable

[Kenneth Graunke]

On 11/25/2013 09:35 PM, Keith Packard wrote:
> Move the depth field up with width and height.
> 
> Remove unused previous_time and frames fields.
> 
> Signed-off-by: Keith Packard 
> ---
>  src/glx/dri3_priv.h | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
> index 05f66cf..34c67a6 100644
> --- a/src/glx/dri3_priv.h
> +++ b/src/glx/dri3_priv.h
> @@ -177,7 +177,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
>  struct dri3_drawable {
> __GLXDRIdrawable base;
> __DRIdrawable *driDrawable;
> -   int width, height;
> +   int width, height, depth;
> int swap_interval;
> uint8_t have_back;
> uint8_t have_fake_front;
> @@ -193,13 +193,9 @@ struct dri3_drawable {
> /* For WaitMSC */
> uint32_t present_msc_request_serial;
> uint32_t present_msc_event_serial;
> -   
> -   uint64_t previous_time;
> -   unsigned frames;
>  
> struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
> int cur_back;
> -   int depth;
>  
> uint32_t *stamp;
>  
> 

This one is easy.
Reviewed-by: Kenneth Graunke 

I plan to push it - hopefully today.  I don't feel qualified to review
the SBC and swap event handling patches, so hopefully someone else can
take a look...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] swrast: silence driContextSetFlags() parameter type warning

[Brian Paul]

---
 src/mesa/drivers/dri/swrast/swrast.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
b/src/mesa/drivers/dri/swrast/swrast.c
index cfa9316..79a2740 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -705,7 +705,7 @@ dri_create_context(gl_api api,
goto context_fail;
 }
 
-driContextSetFlags(ctx, flags);
+driContextSetFlags(mesaCtx, flags);
 
 /* do bounds checking to prevent segfaults and server crashes! */
 mesaCtx->Const.CheckArrayBounds = GL_TRUE;
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] st/dri: fix compiler warning for driCopySubBufferExtension

[Brian Paul]

---
 src/gallium/state_trackers/dri/sw/drisw.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/dri/sw/drisw.c 
b/src/gallium/state_trackers/dri/sw/drisw.c
index 64a64af..6f50b05 100644
--- a/src/gallium/state_trackers/dri/sw/drisw.c
+++ b/src/gallium/state_trackers/dri/sw/drisw.c
@@ -414,7 +414,7 @@ const struct __DriverAPIRec driDriverAPI = {
 PUBLIC const __DRIextension *__driDriverExtensions[] = {
 &driCoreExtension.base,
 &driSWRastExtension.base,
-&driCopySubBufferExtension,
+&driCopySubBufferExtension.base,
 &gallium_config_options.base,
 NULL
 };
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 07/10] mesa: Implement functions for clear_buffer_object extensions

[Brian Paul]

On 12/13/2013 03:17 PM, Pi Tabred wrote:

I tried to tackle this issue:

There is still the issue regarding the following:
According to the spec, it should be possible to clear some part of a
buffer, even if a different, non-overlapping part is mapped, this is
currently not possible. It was suggested to implement ClearBufferSubData
using MapBufferRange. However, this does not work if a part of the
buffer is already mapped.
I am not sure how to handle this. Maybe that's something that has to be
done inside the different drivers?


I used BufferSubData to transfer the data, however according to the spec
BufferSubData is only guaranteed to work if the complete buffer is
unmapped.


OK, that's probably as good as we can do for now.


  - _mesa_buffer_clear_subdata: default callback for dd function table
  - _mesa_ClearBufferData: API function
  - _mesa_ClearBufferSubData: API function
  - validate_clear_buffer_format: helper function, check if the
internalformat,
format and type parameter are legal
  - convert_clear_buffer_data: helper function, convert the supplied data
to the desired internalformat.


I don't think you need to list the functions in the commit message, but 
not a big deal.




---
  src/mesa/main/bufferobj.c | 259
++
  src/mesa/main/bufferobj.h |   4 +
  2 files changed, 263 insertions(+)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 1219891..fb09aa9 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -41,6 +41,9 @@
  #include "fbobject.h"
  #include "mtypes.h"
  #include "texobj.h"
+#include "teximage.h"
+#include "glformats.h"
+#include "texstore.h"
  #include "transformfeedback.h"
  #include "dispatch.h"

@@ -283,6 +286,96 @@ buffer_object_subdata_range_good(struct gl_context
* ctx, GLenum target,


  /**
+ * Test the format and type parameters and set the GL error code for
+ * \c glClearBufferData and \c glClearBufferSubData.
+ *
+ * \param ctx GL context.
+ * \param internalformat  Format to which the data is to be converted.
+ * \param format  Format of the supplied data.
+ * \param typeType of the supplied data.
+ * \param caller  Name of calling function for recording errors.
+ * \return   If internalformat, format and type are legal the gl_format
+ *   corresponding to internalformat, otherwise MESA_FORMAT_NONE.
+ *
+ * \sa glClearBufferData and glClearBufferSubData
+ */
+static gl_format
+validate_clear_buffer_format(struct gl_context *ctx,
+ GLenum internalformat,
+ GLenum format, GLenum type,
+ const char* caller)


"const char *caller"



+{
+   gl_format mesaFormat;
+   GLenum errorFormatType;
+
+   mesaFormat = _mesa_validate_texbuffer_format(ctx, internalformat);
+   if (mesaFormat == MESA_FORMAT_NONE) {
+  _mesa_error(ctx, GL_INVALID_ENUM,
+  "%s(invalid internalformat)", caller);
+  return MESA_FORMAT_NONE;
+   }
+
+   /* NOTE: not mentioned in ARB_clear_buffer_object but according to
+* EXT_texture_integer there is no conversion between integer and
+* non-integer formats
+   */
+   if (_mesa_is_enum_format_signed_int(format) !=
+   _mesa_is_format_integer_color(mesaFormat)) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "%s(integer vs non-integer)", caller);
+  return MESA_FORMAT_NONE;
+   }
+
+   if (!_mesa_is_color_format(format)) {
+  _mesa_error(ctx, GL_INVALID_ENUM,
+  "%s(format is not a color format)", caller);
+  return MESA_FORMAT_NONE;
+   }
+
+   errorFormatType = _mesa_error_check_format_and_type(ctx, format,
+   type);
+   if (errorFormatType != GL_NO_ERROR) {
+  _mesa_error(ctx, GL_INVALID_ENUM,
+  "%s(invalid format or type)", caller);
+  return MESA_FORMAT_NONE;
+   }
+
+   return mesaFormat;
+}
+
+
+/**
+ * Convert user-specified clear value to the specified internal format.
+ *
+ * \param ctx GL context.
+ * \param internalformat  Format to which the data is converted.
+ * \param clearValue  Pointer, store converted data here.
+ * \param format  Format of the supplied data.
+ * \param typeType of the supplied data.
+ * \param dataData which is to be converted to internalformat
+ *
+ * \sa glClearBufferData, glClearBufferSubData
+ */
+static void
+convert_clear_buffer_data(struct gl_context *ctx,
+  gl_format internalformat,
+  GLubyte *clearValue, GLenum format, GLenum type,
+  const GLvoid *data)
+{
+   GLenum internalformatBase;
+
+   internalformatBase = _mesa_get_format_base_format(internalformat);
+
+
+   GLboolean success = _mesa_texstore(ctx, 1, internalformatBase,


This variable needs to be declared at the top of the function.



+   

Re: [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

[Keith Packard]

Kenneth Graunke  writes:

> I see that Eric reviewed it, and that it has not landed.  Are there any
> objections to merging it?

They're on top of a series of DRI3/Present patches, not all of which
have seen review. I was hoping the rest of that series would get
reviewed so that I could merge it all at the same time.

Eric also suggested that we change the switch statements using these
defines to catch unknown values and provide some better indication than
the silent failure I was experiencing.

-- 
keith.pack...@intel.com


pgphTFkN0Tfov.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 02/18] dri/swrast: Passing dri_context * instead of gl_context* to driContextSetFlags

[Keith Packard]

These are the same address, but different types and driContextSetFlags wants
a gl_context pointer.

Signed-off-by: Keith Packard 
---
 src/mesa/drivers/dri/swrast/swrast.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
b/src/mesa/drivers/dri/swrast/swrast.c
index cfa9316..79a2740 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -705,7 +705,7 @@ dri_create_context(gl_api api,
goto context_fail;
 }
 
-driContextSetFlags(ctx, flags);
+driContextSetFlags(mesaCtx, flags);
 
 /* do bounds checking to prevent segfaults and server crashes! */
 mesaCtx->Const.CheckArrayBounds = GL_TRUE;
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 01/18] Remove glBlendColor and glBlendEquations decls from glext.h

[Keith Packard]

These are duplicates from gl.h; I'm not sure which file they belong in, but
you don't get to have them in both places.

Signed-off-by: Keith Packard 
---
 include/GL/glext.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/GL/glext.h b/include/GL/glext.h
index 7d6033e..b432d2e 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -457,8 +457,6 @@ GLAPI void APIENTRY glWindowPos3i (GLint x, GLint y, GLint 
z);
 GLAPI void APIENTRY glWindowPos3iv (const GLint *v);
 GLAPI void APIENTRY glWindowPos3s (GLshort x, GLshort y, GLshort z);
 GLAPI void APIENTRY glWindowPos3sv (const GLshort *v);
-GLAPI void APIENTRY glBlendColor (GLfloat red, GLfloat green, GLfloat blue, 
GLfloat alpha);
-GLAPI void APIENTRY glBlendEquation (GLenum mode);
 #endif
 #endif /* GL_VERSION_1_4 */
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 12/18] dri3: Rename DRI3_MAX_BACK to DRI3_NUM_BACK

[Keith Packard]

It is the maximum number of back buffers, but the name is confusing and is
easily read as the maximum back buffer index. Chage to DRI3_NUM_BACK to make
the intended usage a bit clearer.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  |  4 ++--
 src/glx/dri3_priv.h | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index ea20138..c26d6e5 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1065,7 +1065,7 @@ dri3_find_back(xcb_connection_t *c, struct dri3_drawable 
*priv)
 
for (;;) {
 
-  for (b = 0; b < DRI3_MAX_BACK; b++) {
+  for (b = 0; b < DRI3_NUM_BACK; b++) {
  intid = DRI3_BACK_ID(b);
  struct dri3_buffer*buffer = priv->buffers[id];
 
@@ -1181,7 +1181,7 @@ dri3_free_buffers(__DRIdrawable *driDrawable,
switch (buffer_type) {
case dri3_buffer_back:
   first_id = DRI3_BACK_ID(0);
-  n_id = DRI3_MAX_BACK;
+  n_id = DRI3_NUM_BACK;
   break;
case dri3_buffer_front:
   first_id = DRI3_FRONT_ID;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 4c5579e..49a13ba 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -143,14 +143,14 @@ struct dri3_context
__DRIcontext *driContext;
 };
 
-#define DRI3_MAX_BACK   2
+#define DRI3_NUM_BACK   2
 #define DRI3_BACK_ID(i) (i)
-#define DRI3_FRONT_ID   (DRI3_MAX_BACK)
+#define DRI3_FRONT_ID   (DRI3_NUM_BACK)
 
 static inline int
 dri3_buf_id_next(int buf_id)
 {
-   if (buf_id == DRI3_MAX_BACK - 1)
+   if (buf_id == DRI3_NUM_BACK - 1)
   return 0;
return buf_id + 1;
 }
@@ -159,7 +159,7 @@ static inline int
 dri3_buf_id_prev(int buf_id)
 {
if (buf_id == 0)
-  return DRI3_MAX_BACK - 1;
+  return DRI3_NUM_BACK - 1;
return buf_id - 1;
 }
 
@@ -172,7 +172,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
   return DRI3_FRONT_ID;
 }
 
-#define DRI3_NUM_BUFFERS(1 + DRI3_MAX_BACK)
+#define DRI3_NUM_BUFFERS(1 + DRI3_NUM_BACK)
 
 struct dri3_drawable {
__GLXDRIdrawable base;
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 00/18] dri3+gallium patch series

[Keith Packard]

This series has a bunch of DRI3 cleanups and fixes followed by a few patches
that finish up DRI3 support in gallium.

The first two patches have nothing to do with DRI3, just some warning fixes:

 [PATCH 01/18] Remove glBlendColor and glBlendEquations decls from
 [PATCH 02/18] dri/swrast: Passing dri_context * instead of

DRI3 cleanups

 [PATCH 03/18] Don't use libudev for glx/dri3
 [PATCH 04/18] dri3: Switch to libxshmfence version 1.1
 [PATCH 05/18] dri3: Free resources when drawable is destroyed.
 [PATCH 06/18] dri3: Clean up struct dri3_drawable
 [PATCH 07/18] dri3: Track full 64-bit SBC numbers, instead of just
 [PATCH 08/18] dri3: Fix dri3_wait_for_sbc to wait for completion of
 [PATCH 09/18] dri3: Enable GLX_INTEL_swap_event
 [PATCH 10/18] i965: Correct check for re-bound buffer in
 [PATCH 11/18] i965: Set fast color clear mcs_state on newly allocated
 [PATCH 12/18] dri3: Rename DRI3_MAX_BACK to DRI3_NUM_BACK
 [PATCH 13/18] dri3: Flush XCB before blocking for special events
 [PATCH 14/18] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB

And the gallium patches: The middle two are from Ben Skeggs, but haven't been
reviewed and not in an area of the code I feel comfortable reviewing.

 [PATCH 15/18] gallium: Add __DRIimageDriverExtension support to
 [PATCH 16/18] gallium/dri: fix unsetting of format when encountering
 [PATCH 17/18] nvc0: fix segfault if nv50_miptree_from_handle() fails
 [PATCH 18/18] gallium: Use base.stamp for all drawable invalidation
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 07/18] dri3: Track full 64-bit SBC numbers, instead of just 32-bits

[Keith Packard]

Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number that
we use to pass the SBC value from request to event.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  | 34 +-
 src/glx/dri3_priv.h | 16 +---
 2 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 4c0dc29..b9a786f 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -364,10 +364,17 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
xcb_present_generic_event_
case XCB_PRESENT_COMPLETE_NOTIFY: {
   xcb_present_complete_notify_event_t *ce = (void *) ge;
 
-  if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP)
- priv->present_event_serial = ce->serial;
-  else
- priv->present_msc_event_serial = ce->serial;
+  /* Compute the processed SBC number from the received 32-bit serial 
number merged
+   * with the upper 32-bits of the sent 64-bit serial number while 
checking for
+   * wrap
+   */
+  if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
+ priv->recv_sbc = (priv->send_sbc & 0xLL) | ce->serial;
+ if (priv->recv_sbc > priv->send_sbc)
+priv->recv_sbc -= 0x1;
+  } else {
+ priv->recv_msc_serial = ce->serial;
+  }
   priv->ust = ce->ust;
   priv->msc = ce->msc;
   break;
@@ -398,12 +405,13 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
+   uint32_t msc_serial;
 
/* Ask for the an event for the target MSC */
-   ++priv->present_msc_request_serial;
+   msc_serial = ++priv->send_msc_serial;
xcb_present_notify_msc(c,
   priv->base.xDrawable,
-  priv->present_msc_request_serial,
+  msc_serial,
   target_msc,
   divisor,
   remainder);
@@ -412,7 +420,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 
/* Wait for the event */
if (priv->special_event) {
-  while (priv->present_msc_request_serial != 
priv->present_msc_event_serial) {
+  while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
  ev = xcb_wait_for_special_event(c, priv->special_event);
  if (!ev)
 break;
@@ -423,7 +431,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 
*ust = priv->ust;
*msc = priv->msc;
-   *sbc = priv->sbc;
+   *sbc = priv->recv_sbc;
 
return 1;
 }
@@ -450,7 +458,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
 
-   while (priv->sbc < target_sbc) {
+   while (priv->send_sbc < target_sbc) {
   sleep(1);
}
return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
@@ -1281,15 +1289,15 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
   /* Compute when we want the frame shown by taking the last known 
successful
* MSC and adding in a swap interval for each outstanding swap request
*/
-  ++priv->present_request_serial;
+  ++priv->send_sbc;
   if (target_msc == 0)
- target_msc = priv->msc + priv->swap_interval * 
(priv->present_request_serial - priv->present_event_serial);
+ target_msc = priv->msc + priv->swap_interval * (priv->send_sbc - 
priv->recv_sbc);
 
   priv->buffers[buf_id]->busy = 1;
   xcb_present_pixmap(c,
  priv->base.xDrawable,
  priv->buffers[buf_id]->pixmap,
- priv->present_request_serial,
+ (uint32_t) priv->send_sbc,
  0,/* valid */
  0,/* update */
  0,/* x_off */
@@ -1301,7 +1309,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
  target_msc,
  divisor,
  remainder, 0, NULL);
-  ret = ++priv->sbc;
+  ret = (int64_t) priv->send_sbc;
 
   /* If there's a fake front, then copy the source back buffer
* to the fake front to keep it up to date. This needs
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 4adef50..4c5579e 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -183,16 +183,18 @@ struct dri3_drawable {
uint8_t have_fake_front;
uint8_t is_pixmap;
 
-   uint32_t present_request_serial;
- 

[Mesa-dev] [PATCH 03/18] Don't use libudev for glx/dri3

[Keith Packard]

libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.

Signed-off-by: Keith Packard 
---
 configure.ac  |  8 -
 src/glx/dri3_common.c | 85 ++-
 2 files changed, 50 insertions(+), 43 deletions(-)

diff --git a/configure.ac b/configure.ac
index c14d39a..1193cff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -824,9 +824,6 @@ xyesno)
 PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
 GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
 if test x"$enable_dri3" = xyes; then
-if test x"$have_libudev" != xyes; then
-  AC_MSG_ERROR([DRI3 requires libudev >= $LIBUDEV_REQUIRED])
-fi
 PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
 PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >= 
$PRESENTPROTO_REQUIRED])
 fi
@@ -850,11 +847,6 @@ xyesno)
 X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
 GL_LIB_DEPS="$DRIGL_LIBS"
 
-if test x"$enable_dri3$have_libudev" = xyesyes; then
-X11_INCLUDES="$X11_INCLUDES $LIBUDEV_CFLAGS"
-GL_LIB_DEPS="$GL_LIB_DEPS $LIBUDEV_LIBS"
-fi
-
 # need DRM libs, $PTHREAD_LIBS, etc.
 GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
 GL_PC_LIB_PRIV="-lm $PTHREAD_LIBS $DLOPEN_LIBS"
diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
index c758f96..511fbc8 100644
--- a/src/glx/dri3_common.c
+++ b/src/glx/dri3_common.c
@@ -23,7 +23,7 @@
 /*
  * This code is derived from src/egl/drivers/dri2/common.c which
  * carries the following copyright:
- * 
+ *
  * Copyright ?? 2011 Intel Corporation
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -67,62 +67,80 @@
 #include 
 #include 
 #include 
+#include 
 #include "xf86drm.h"
 #include "dri_common.h"
 #include "dri3_priv.h"
 
 #define DRIVER_MAP_DRI3_ONLY
-#include "pci_ids/pci_id_driver_map.h"
 
-#include 
+#include "pci_ids/pci_id_driver_map.h"
 
-static struct udev_device *
-dri3_udev_device_new_from_fd(struct udev *udev, int fd)
+static dev_t
+dri3_rdev_from_fd(int fd)
 {
-   struct udev_device *device;
struct stat buf;
 
if (fstat(fd, &buf) < 0) {
   ErrorMessageF("DRI3: failed to stat fd %d", fd);
-  return NULL;
+  return 0;
}
+   return buf.st_rdev;
+}
 
-   device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
-   if (device == NULL) {
-  ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
-  return NULL;
-   }
+/*
+ * There are multiple udev library versions, and they aren't polite about
+ * symbols, so just avoid using it until some glorious future when the udev
+ * developers figure out how to not break things
+ */
 
-   return device;
+#define SYS_PATH_MAX256
+
+static bool
+dri3_read_hex(dev_t rdev, char *entry, int *value)
+{
+   char path[SYS_PATH_MAX];
+   FILE *f;
+   int  r;
+
+   snprintf(path, sizeof (path), "/sys/dev/char/%u:%u/device/%s",
+major(rdev), minor(rdev), entry);
+
+   f = fopen(path,"r");
+   if (f == NULL)
+  return false;
+
+   r = fscanf(f, "0x%x\n", value);
+   fclose(f);
+   if (r != 1)
+  return false;
+   return true;
+}
+
+static bool
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
+{
+   dev_trdev = dri3_rdev_from_fd(fd);
+
+   if (!rdev)
+  return false;
+
+   if (!dri3_read_hex(rdev, "vendor", vendorp))
+  return false;
+   if (!dri3_read_hex(rdev, "device", chipp))
+  return false;
+   return true;
 }
 
 char *
 dri3_get_driver_for_fd(int fd)
 {
-   struct udev *udev;
-   struct udev_device *device, *parent;
-   const char *pci_id;
char *driver = NULL;
int vendor_id, chip_id, i, j;
 
-   udev = udev_new();
-   device = dri3_udev_device_new_from_fd(udev, fd);
-   if (device == NULL)
+   if (!dri3_get_pci_id_from_fd(fd, &vendor_id, &chip_id))
   return NULL;
 
-   parent = udev_device_get_parent(device);
-   if (parent == NULL) {
-  ErrorMessageF("DRI3: could not get parent device");
-  goto out;
-   }
-
-   pci_id = udev_device_get_property_value(parent, "PCI_ID");
-   if (pci_id == NULL ||
-   sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
-  ErrorMessageF("DRI3: malformed or no PCI ID");
-  goto out;
-   }
-
for (i = 0; driver_map[i].driver; i++) {
   if (vendor_id != driver_map[i].vendor_id)
  continue;
@@ -139,8 +157,5 @@ dri3_get_driver_for_fd(int fd)
}
 
 out:
-   udev_device_unref(device);
-   udev_unref(udev);
-
return driver;
 }
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 09/18] dri3: Enable GLX_INTEL_swap_event

[Keith Packard]

Now that we're tracking SBC values correctly, and the X server has the ability
to send the GLX swap events from a PresentPixmap request, enable this extension.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index d2b9d0e..ea20138 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1524,23 +1524,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct 
glx_display * priv,
__glXEnableDirectExtension(&psc->base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_SGI_make_current_read");
-
-   /*
-* GLX_INTEL_swap_event is broken on the server side, where it's
-* currently unconditionally enabled. This completely breaks
-* systems running on drivers which don't support that extension.
-* There's no way to test for its presence on this side, so instead
-* of disabling it unconditionally, just disable it for drivers
-* which are known to not support it, or for DDX drivers supporting
-* only an older (pre-ScheduleSwap) version of DRI2.
-*
-* This is a hack which is required until:
-* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
-* is merged and updated xserver makes it's way into distros:
-*/
-//   if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) {
-//  __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
-//   }
+   __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
 
mask = psc->image_driver->getAPIMask(psc->driScreen);
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 13/18] dri3: Flush XCB before blocking for special events

[Keith Packard]

XCB doesn't flush the output buffer automatically, so we have to call
xcb_flush ourselves before waiting.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index c26d6e5..7982f6b 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -405,6 +405,7 @@ dri3_wait_for_event(__GLXDRIdrawable *pdraw)
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
 
+   xcb_flush(c);
ev = xcb_wait_for_special_event(c, priv->special_event);
if (!ev)
   return false;
@@ -1074,6 +1075,7 @@ dri3_find_back(xcb_connection_t *c, struct dri3_drawable 
*priv)
  if (!buffer->busy)
 return b;
   }
+  xcb_flush(c);
   ev = xcb_wait_for_special_event(c, priv->special_event);
   if (!ev)
  return -1;
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 06/18] dri3: Clean up struct dri3_drawable

[Keith Packard]

Move the depth field up with width and height.

Remove unused previous_time and frames fields.

Signed-off-by: Keith Packard 
Reviewed-by: Kenneth Graunke 
---
 src/glx/dri3_priv.h | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 2990c4f..4adef50 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -177,7 +177,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
 struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
-   int width, height;
+   int width, height, depth;
int swap_interval;
uint8_t have_back;
uint8_t have_fake_front;
@@ -193,13 +193,9 @@ struct dri3_drawable {
/* For WaitMSC */
uint32_t present_msc_request_serial;
uint32_t present_msc_event_serial;
-   
-   uint64_t previous_time;
-   unsigned frames;
 
struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
-   int depth;
 
uint32_t *stamp;
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 11/18] i965: Set fast color clear mcs_state on newly allocated image miptrees

[Keith Packard]

Just copying code from the dri2 path to set up the fast color clear state.

This also removes a couple of bogus intel_region_reference calls.

Signed-off-by: Keith Packard 
Reviewed-by: Eric Anholt 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index a96c7ea..de47143 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -771,7 +771,13 @@ intel_miptree_create_for_image_buffer(struct brw_context 
*intel,
if (!singlesample_mt)
   return NULL;
 
-   intel_region_reference(&singlesample_mt->region, region);
+   /* If this miptree is capable of supporting fast color clears, set
+* mcs_state appropriately to ensure that fast clears will occur.
+* Allocation of the MCS miptree will be deferred until the first fast
+* clear actually occurs.
+*/
+   if (intel_is_non_msrt_mcs_buffer_supported(intel, singlesample_mt))
+  singlesample_mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_RESOLVED;
 
if (num_samples == 0)
   return singlesample_mt;
@@ -789,8 +795,6 @@ intel_miptree_create_for_image_buffer(struct brw_context 
*intel,
multisample_mt->singlesample_mt = singlesample_mt;
multisample_mt->need_downsample = false;
 
-   intel_region_reference(&multisample_mt->region, region);
-
if (intel->is_front_buffer_rendering && buffer_type == 
__DRI_IMAGE_BUFFER_FRONT) {
   intel_miptree_upsample(intel, multisample_mt);
}
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 08/18] dri3: Fix dri3_wait_for_sbc to wait for completion of requested SBC

[Keith Packard]

Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC
had been completed, which means to wait until the PresentCompleteNotify event
for that SBC had been received.

This replaces the simple sleep(1) loop (which was bogus) with a loop that just
checks to see if we've seen the specified SBC value come back in a
PresentCompleteNotify event yet.

The change is a bit larger than that as I've broken out a piece of common code
to wait for and process a single Present event for the target drawable.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 55 ++
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b9a786f..d2b9d0e 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -397,14 +397,33 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
xcb_present_generic_event_
free(ge);
 }
 
+static bool
+dri3_wait_for_event(__GLXDRIdrawable *pdraw)
+{
+   xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
+   struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+   xcb_generic_event_t *ev;
+   xcb_present_generic_event_t *ge;
+
+   ev = xcb_wait_for_special_event(c, priv->special_event);
+   if (!ev)
+  return false;
+   ge = (void *) ev;
+   dri3_handle_present_event(priv, ge);
+   return true;
+}
+
+/** dri3_wait_for_msc
+ *
+ * Get the X server to send an event when the target msc/divisor/remainder is
+ * reached.
+ */
 static int
 dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
   int64_t remainder, int64_t *ust, int64_t *msc, int64_t *sbc)
 {
xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
-   xcb_generic_event_t *ev;
-   xcb_present_generic_event_t *ge;
uint32_t msc_serial;
 
/* Ask for the an event for the target MSC */
@@ -421,11 +440,8 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
/* Wait for the event */
if (priv->special_event) {
   while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
- ev = xcb_wait_for_special_event(c, priv->special_event);
- if (!ev)
-break;
- ge = (void *) ev;
- dri3_handle_present_event(priv, ge);
+ if (!dri3_wait_for_event(pdraw))
+return 0;
   }
}
 
@@ -436,6 +452,11 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
return 1;
 }
 
+/** dri3_drawable_get_msc
+ *
+ * Return the current UST/MSC/SBC triplet by asking the server
+ * for an event
+ */
 static int
 dri3_drawable_get_msc(struct glx_screen *psc, __GLXDRIdrawable *pdraw,
   int64_t *ust, int64_t *msc, int64_t *sbc)
@@ -445,12 +466,9 @@ dri3_drawable_get_msc(struct glx_screen *psc, 
__GLXDRIdrawable *pdraw,
 
 /** dri3_wait_for_sbc
  *
- * Wait for the swap buffer count to increase. The only way this
- * can happen is if some other thread is doing swap buffers as
- * we no longer share swap buffer counts with other processes.
- *
- * I'm not sure this is actually useful as such, and so this
- * implementation is a kludge that just polls once a second
+ * Wait for the completed swap buffer count to reach the specified
+ * target. Presumably the application knows that this will be reached with
+ * outstanding complete events, or we're going to be here awhile.
  */
 static int
 dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t target_sbc, int64_t *ust,
@@ -458,10 +476,15 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
 
-   while (priv->send_sbc < target_sbc) {
-  sleep(1);
+   while (priv->recv_sbc < target_sbc) {
+  if (!dri3_wait_for_event(pdraw))
+ return 0;
}
-   return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
+
+   *ust = priv->ust;
+   *msc = priv->msc;
+   *sbc = priv->recv_sbc;
+   return 1;
 }
 
 /**
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 14/18] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

[Keith Packard]

The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
__IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.

I'll refrain from comments on whether I think having two separate sets of
format defines in dri_interface.h is a good idea or not...

Signed-off-by: Keith Packard 
Reviewed-by: Eric Anholt 
---
 include/GL/internal/dri_interface.h  | 1 +
 src/glx/dri3_glx.c   | 1 +
 src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
 src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
 4 files changed, 8 insertions(+)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 81f7e60..9e82904 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1041,6 +1041,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_FOURCC_XRGB0x34325258
 #define __DRI_IMAGE_FOURCC_ABGR0x34324241
 #define __DRI_IMAGE_FOURCC_XBGR0x34324258
+#define __DRI_IMAGE_FOURCC_SARGB0x83324258
 #define __DRI_IMAGE_FOURCC_YUV410  0x39565559
 #define __DRI_IMAGE_FOURCC_YUV411  0x31315559
 #define __DRI_IMAGE_FOURCC_YUV420  0x32315559
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 7982f6b..ad6de65 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -936,6 +936,7 @@ image_format_to_fourcc(int format)
 
/* Convert from __DRI_IMAGE_FORMAT to __DRI_IMAGE_FOURCC (sigh) */
switch (format) {
+   case __DRI_IMAGE_FORMAT_SARGB8: return __DRI_IMAGE_FOURCC_SARGB;
case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index d607f47..d442eab 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -184,6 +184,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
+   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 4373685..9a5bf5c 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -220,6 +220,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
+   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 17/18] nvc0: fix segfault if nv50_miptree_from_handle() fails

[Keith Packard]

From: Ben Skeggs 

Signed-off-by: Ben Skeggs 
Signed-off-by: Keith Packard 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c
index 4e70903..7fbc6e1 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c
@@ -26,7 +26,8 @@ nvc0_resource_from_handle(struct pipe_screen * screen,
} else {
   struct pipe_resource *res = nv50_miptree_from_handle(screen,
templ, whandle);
-  nv04_resource(res)->vtbl = &nvc0_miptree_vtbl;
+  if (res)
+ nv04_resource(res)->vtbl = &nvc0_miptree_vtbl;
   return res;
}
 }
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 16/18] gallium/dri: fix unsetting of format when encountering depth/stencil

[Keith Packard]

From: Ben Skeggs 

Signed-off-by: Ben Skeggs 
Signed-off-by: Keith Packard 
---
 src/gallium/state_trackers/dri/drm/dri2.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 03b93ae..a9d6a10 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -517,6 +517,17 @@ dri_image_allocate_textures(struct dri_context *ctx,
   if (pf == PIPE_FORMAT_NONE)
  continue;
 
+  switch (statts[i]) {
+  case ST_ATTACHMENT_FRONT_LEFT:
+ buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;
+ break;
+  case ST_ATTACHMENT_BACK_LEFT:
+ buffer_mask |= __DRI_IMAGE_BUFFER_BACK;
+ break;
+  default:
+ continue;
+  }
+
   switch (pf) {
   case PIPE_FORMAT_B5G6R5_UNORM:
  image_format = __DRI_IMAGE_FORMAT_RGB565;
@@ -534,17 +545,6 @@ dri_image_allocate_textures(struct dri_context *ctx,
  image_format = __DRI_IMAGE_FORMAT_NONE;
  break;
   }
-
-  switch (statts[i]) {
-  case ST_ATTACHMENT_FRONT_LEFT:
- buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;
- break;
-  case ST_ATTACHMENT_BACK_LEFT:
- buffer_mask |= __DRI_IMAGE_BUFFER_BACK;
- break;
-  default:
- continue;
-  }
}
 
(*sPriv->image.loader->getBuffers) (dPriv,
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 18/18] gallium: Use base.stamp for all drawable invalidation checks.

[Keith Packard]

Upper levels of the stack use base.stamp to tell when a drawable needs to be
revalidated, but the dri state tracker was using dPriv->lastStamp. Those two,
along with dri2.stamp, all get simultaneously incremented when a dri2
invalidate event was delivered, and so end up containing precisely the same
value.

This patch doesn't change the fact that there are three variables, rather it
switches all of the tests to use only base.stamp, which is functionally
equivalent to the previous code.

Then, it passes base.stamp to the image loader getBuffers function so that the
one which is checked will get updated by the XCB special event queue used by 
DRI3.

Signed-off-by: Keith Packard 
Reviewed-by: Marek Olšák 
---
 src/gallium/state_trackers/dri/common/dri_drawable.c | 4 ++--
 src/gallium/state_trackers/dri/drm/dri2.c| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c 
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index f255108..734bca2 100644
--- a/src/gallium/state_trackers/dri/common/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
@@ -73,7 +73,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
 * checked.
 */
do {
-  lastStamp = drawable->dPriv->lastStamp;
+  lastStamp = drawable->base.stamp;
   new_stamp = (drawable->texture_stamp != lastStamp);
 
   if (new_stamp || new_mask || screen->broken_invalidate) {
@@ -91,7 +91,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
  drawable->texture_stamp = lastStamp;
  drawable->texture_mask = statt_mask;
   }
-   } while (lastStamp != drawable->dPriv->lastStamp);
+   } while (lastStamp != drawable->base.stamp);
 
if (!out)
   return TRUE;
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index a9d6a10..9bdb775 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -549,7 +549,7 @@ dri_image_allocate_textures(struct dri_context *ctx,
 
(*sPriv->image.loader->getBuffers) (dPriv,
image_format,
-   &dPriv->dri2.stamp,
+   (uint32_t *) &drawable->base.stamp,
dPriv->loaderPrivate,
buffer_mask,
&images);
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 04/18] dri3: Switch to libxshmfence version 1.1

[Keith Packard]

libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
works when the fence is a linux futex. However, version 1.1
changes the exported datatype to 'struct xshmfence *'

Require libxshmfence version 1.1 and switch the API around.

Signed-off-by: Keith Packard 
---
 configure.ac| 2 +-
 src/glx/dri3_glx.c  | 4 ++--
 src/glx/dri3_priv.h | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1193cff..db0debc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -833,7 +833,7 @@ xyesno)
 dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 
1.8"
 
 if test x"$enable_dri3" = xyes; then
-dri_modules="$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence"
+dri_modules="$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence >= 
1.1"
 fi
 
 # add xf86vidmode if available
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b047cc8..1834c6d 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -676,7 +676,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
xcb_connection_t *c = XGetXCBConnection(dpy);
xcb_pixmap_t pixmap;
xcb_sync_fence_t sync_fence;
-   int32_t *shm_fence;
+   struct xshmfence *shm_fence;
int buffer_fd, fence_fd;
int stride;
 
@@ -921,7 +921,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
struct dri3_screen   *psc;
xcb_connection_t *c;
xcb_sync_fence_t sync_fence;
-   int32_t  *shm_fence;
+   struct xshmfence *shm_fence;
int  fence_fd;
__DRIimage   *image_planar;
int  stride, offset;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index c892800..4bffeb7 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -87,7 +87,7 @@ struct dri3_buffer {
 */
 
uint32_t sync_fence; /* XID of X SyncFence object */
-   int32_t  *shm_fence; /* pointer to xshmfence object */
+   struct xshmfence *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
void *driverPrivate;
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 05/18] dri3: Free resources when drawable is destroyed.

[Keith Packard]

Always nice to clean up after ourselves.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  | 17 -
 src/glx/dri3_priv.h |  5 -
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 1834c6d..4c0dc29 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -266,13 +266,25 @@ dri3_create_context(struct glx_screen *base,
 }
 
 static void
+dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer 
*buffer);
+
+static void
 dri3_destroy_drawable(__GLXDRIdrawable *base)
 {
struct dri3_screen *psc = (struct dri3_screen *) base->psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
+   xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+   int i;
 
(*psc->core->destroyDrawable) (pdraw->driDrawable);
 
+   for (i = 0; i < DRI3_NUM_BUFFERS; i++) {
+  if (pdraw->buffers[i])
+ dri3_free_render_buffer(pdraw, pdraw->buffers[i]);
+   }
+
+   if (pdraw->special_event)
+  xcb_unregister_for_special_event(c, pdraw->special_event);
free(pdraw);
 }
 
@@ -736,6 +748,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   fence_fd);
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = true;
buffer->sync_fence = sync_fence;
buffer->shm_fence = shm_fence;
buffer->width = width;
@@ -769,7 +782,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw, struct 
dri3_buffer *buffer)
struct dri3_screen   *psc = (struct dri3_screen *) pdraw->base.psc;
xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
 
-   xcb_free_pixmap(c, buffer->pixmap);
+   if (buffer->own_pixmap)
+  xcb_free_pixmap(c, buffer->pixmap);
xcb_sync_destroy_fence(c, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
(*psc->image->destroyImage)(buffer->image);
@@ -987,6 +1001,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
   goto no_image;
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = false;
buffer->width = bp_reply->width;
buffer->height = bp_reply->height;
buffer->buffer_type = buffer_type;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 4bffeb7..2990c4f 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -89,6 +89,7 @@ struct dri3_buffer {
uint32_t sync_fence; /* XID of X SyncFence object */
struct xshmfence *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
+   GLbooleanown_pixmap; /* We allocated the pixmap ID, free on destroy 
*/
void *driverPrivate;
 
uint32_t size;
@@ -171,6 +172,8 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
   return DRI3_FRONT_ID;
 }
 
+#define DRI3_NUM_BUFFERS(1 + DRI3_MAX_BACK)
+
 struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
@@ -194,7 +197,7 @@ struct dri3_drawable {
uint64_t previous_time;
unsigned frames;
 
-   struct dri3_buffer *buffers[1 + DRI3_MAX_BACK];
+   struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
int depth;
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 10/18] i965: Correct check for re-bound buffer in intel_update_image_buffer

[Keith Packard]

The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.

Signed-off-by: Keith Packard 
Reviewed-by: Eric Anholt 
---
 src/mesa/drivers/dri/i965/brw_context.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 688091f..78c06fc 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1303,10 +1303,21 @@ intel_update_image_buffer(struct brw_context *intel,
 
unsigned num_samples = rb->Base.Base.NumSamples;
 
-   if (rb->mt &&
-   rb->mt->region &&
-   rb->mt->region == region)
-  return;
+   /* Check and see if we're already bound to the right
+* buffer object
+*/
+   if (num_samples == 0) {
+   if (rb->mt &&
+   rb->mt->region &&
+   rb->mt->region->bo == region->bo)
+  return;
+   } else {
+   if (rb->mt &&
+   rb->mt->singlesample_mt &&
+   rb->mt->singlesample_mt->region &&
+   rb->mt->singlesample_mt->region->bo == region->bo)
+  return;
+   }
 
intel_miptree_release(&rb->mt);
rb->mt = intel_miptree_create_for_image_buffer(intel,
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 15/18] gallium: Add __DRIimageDriverExtension support to gallium

[Keith Packard]

Provide the hook to pull textures out of __DRIimage structures and use them as
renderbuffers.

Signed-off-by: Keith Packard 
---
 src/gallium/state_trackers/dri/drm/dri2.c | 238 +-
 1 file changed, 230 insertions(+), 8 deletions(-)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 8ff77b3..03b93ae 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -457,6 +457,219 @@ dri2_release_buffer(__DRIscreen *sPriv, __DRIbuffer 
*bPriv)
FREE(buffer);
 }
 
+static void
+dri_image_allocate_textures(struct dri_context *ctx,
+   struct dri_drawable *drawable,
+   const enum st_attachment_type *statts,
+   unsigned statts_count)
+{
+   __DRIdrawable *dPriv = drawable->dPriv;
+   __DRIscreen *sPriv = drawable->sPriv;
+   struct dri_screen *screen = dri_screen(sPriv);
+   unsigned int image_format = __DRI_IMAGE_FORMAT_NONE;
+   uint32_t buffer_mask = 0;
+   struct __DRIimageList images;
+   boolean alloc_depthstencil = FALSE;
+   int i, j;
+   struct pipe_resource templ;
+
+   /* See if we need a depth-stencil buffer. */
+   for (i = 0; i < statts_count; i++) {
+  if (statts[i] == ST_ATTACHMENT_DEPTH_STENCIL) {
+ alloc_depthstencil = TRUE;
+ break;
+  }
+   }
+
+   /* Delete the resources we won't need. */
+   for (i = 0; i < ST_ATTACHMENT_COUNT; i++) {
+  /* Don't delete the depth-stencil buffer, we can reuse it. */
+  if (i == ST_ATTACHMENT_DEPTH_STENCIL && alloc_depthstencil)
+ continue;
+
+  pipe_resource_reference(&drawable->textures[i], NULL);
+   }
+
+   if (drawable->stvis.samples > 1) {
+  for (i = 0; i < ST_ATTACHMENT_COUNT; i++) {
+ boolean del = TRUE;
+
+ /* Don't delete MSAA resources for the attachments which are enabled,
+  * we can reuse them. */
+ for (j = 0; j < statts_count; j++) {
+if (i == statts[j]) {
+   del = FALSE;
+   break;
+}
+ }
+
+ if (del) {
+pipe_resource_reference(&drawable->msaa_textures[i], NULL);
+ }
+  }
+   }
+
+   for (i = 0; i < statts_count; i++) {
+  enum pipe_format pf;
+  unsigned bind;
+
+  dri_drawable_get_format(drawable, statts[i], &pf, &bind);
+  if (pf == PIPE_FORMAT_NONE)
+ continue;
+
+  switch (pf) {
+  case PIPE_FORMAT_B5G6R5_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_RGB565;
+ break;
+  case PIPE_FORMAT_B8G8R8X8_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_XRGB;
+ break;
+  case PIPE_FORMAT_B8G8R8A8_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_ARGB;
+ break;
+  case PIPE_FORMAT_R8G8B8A8_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_ABGR;
+ break;
+  default:
+ image_format = __DRI_IMAGE_FORMAT_NONE;
+ break;
+  }
+
+  switch (statts[i]) {
+  case ST_ATTACHMENT_FRONT_LEFT:
+ buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;
+ break;
+  case ST_ATTACHMENT_BACK_LEFT:
+ buffer_mask |= __DRI_IMAGE_BUFFER_BACK;
+ break;
+  default:
+ continue;
+  }
+   }
+
+   (*sPriv->image.loader->getBuffers) (dPriv,
+   image_format,
+   &dPriv->dri2.stamp,
+   dPriv->loaderPrivate,
+   buffer_mask,
+   &images);
+
+   if (images.image_mask & __DRI_IMAGE_BUFFER_FRONT) {
+  struct pipe_resource *texture = images.front->texture;
+
+  dPriv->w = texture->width0;
+  dPriv->h = texture->height0;
+
+  pipe_resource_reference(&drawable->textures[ST_ATTACHMENT_FRONT_LEFT], 
texture);
+   }
+
+   if (images.image_mask & __DRI_IMAGE_BUFFER_BACK) {
+  struct pipe_resource *texture = images.back->texture;
+
+  dPriv->w = images.back->texture->width0;
+  dPriv->h = images.back->texture->height0;
+
+  pipe_resource_reference(&drawable->textures[ST_ATTACHMENT_BACK_LEFT], 
texture);
+   }
+
+   memset(&templ, 0, sizeof(templ));
+   templ.target = screen->target;
+   templ.last_level = 0;
+   templ.width0 = dPriv->w;
+   templ.height0 = dPriv->h;
+   templ.depth0 = 1;
+   templ.array_size = 1;
+
+   /* Allocate private MSAA colorbuffers. */
+   if (drawable->stvis.samples > 1) {
+  for (i = 0; i < statts_count; i++) {
+ enum st_attachment_type att = statts[i];
+
+ if (att == ST_ATTACHMENT_DEPTH_STENCIL)
+continue;
+
+ if (drawable->textures[att]) {
+templ.format = drawable->textures[att]->format;
+templ.bind = drawable->textures[att]->bind;
+templ.nr_samples = drawable->stvis.samples;
+
+/* Try to reuse the resource.
+ * (the other resource parameters

Re: [Mesa-dev] [PATCH 01/18] Remove glBlendColor and glBlendEquations decls from glext.h

[Kenneth Graunke]

On 12/13/2013 05:25 PM, Keith Packard wrote:
> These are duplicates from gl.h; I'm not sure which file they belong in, but
> you don't get to have them in both places.
> 
> Signed-off-by: Keith Packard 
> ---
>  include/GL/glext.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/include/GL/glext.h b/include/GL/glext.h
> index 7d6033e..b432d2e 100644
> --- a/include/GL/glext.h
> +++ b/include/GL/glext.h
> @@ -457,8 +457,6 @@ GLAPI void APIENTRY glWindowPos3i (GLint x, GLint y, 
> GLint z);
>  GLAPI void APIENTRY glWindowPos3iv (const GLint *v);
>  GLAPI void APIENTRY glWindowPos3s (GLshort x, GLshort y, GLshort z);
>  GLAPI void APIENTRY glWindowPos3sv (const GLshort *v);
> -GLAPI void APIENTRY glBlendColor (GLfloat red, GLfloat green, GLfloat blue, 
> GLfloat alpha);
> -GLAPI void APIENTRY glBlendEquation (GLenum mode);
>  #endif
>  #endif /* GL_VERSION_1_4 */

NAK.  These headers come directly from Khronos; we need to somehow get
this fixed upstream and take their version.

--Ken

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3

[Kenneth Graunke]

On 11/18/2013 12:58 PM, Emil Velikov wrote:
> On 18/11/13 01:08, Keith Packard wrote:
>> libudev doesn't have a stable API/ABI, and if the application wants to use 
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard 
>> ---
>>
> Hi Keith,
> 
> Did you had the chance to look at src/gallium/targets/egl-static/egl.c?
> It has a different implementation of drm_fd_get_pci_id, whenever udev is
> not available.
> 
> AFAICS it goes back to the kernel via the relevant ioctl to retrieve the
> deviceid/chipid. Currently all but nouveau provide such information. I'm
> thinking that this approach might be more reasonable for those concerned
> with portability of the udev bits (think on *BSD).
> 
> I'm not nitpicking, just thought you might find this interesting.
> 
> Cheers,
> Emil

Possibly.  But looking at that code, it either:
1. Uses libudev
2. On Android only...strcmps the driver string to guess the family and
then uses kernel ioctls...
3. Fails.

The Android only nature makes me a bit wary.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/18] dri3: Switch to libxshmfence version 1.1

[Kenneth Graunke]

On 12/13/2013 05:25 PM, Keith Packard wrote:
> libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
> works when the fence is a linux futex. However, version 1.1
> changes the exported datatype to 'struct xshmfence *'
> 
> Require libxshmfence version 1.1 and switch the API around.
> 
> Signed-off-by: Keith Packard 
> ---
>  configure.ac| 2 +-
>  src/glx/dri3_glx.c  | 4 ++--
>  src/glx/dri3_priv.h | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 1193cff..db0debc 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -833,7 +833,7 @@ xyesno)
>  dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 
> >= 1.8"
>  
>  if test x"$enable_dri3" = xyes; then
> -dri_modules="$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence"
> +dri_modules="$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence >= 
> 1.1"
>  fi
>  
>  # add xf86vidmode if available
> diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
> index b047cc8..1834c6d 100644
> --- a/src/glx/dri3_glx.c
> +++ b/src/glx/dri3_glx.c
> @@ -676,7 +676,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
> Drawable draw,
> xcb_connection_t *c = XGetXCBConnection(dpy);
> xcb_pixmap_t pixmap;
> xcb_sync_fence_t sync_fence;
> -   int32_t *shm_fence;
> +   struct xshmfence *shm_fence;
> int buffer_fd, fence_fd;
> int stride;
>  
> @@ -921,7 +921,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
> struct dri3_screen   *psc;
> xcb_connection_t *c;
> xcb_sync_fence_t sync_fence;
> -   int32_t  *shm_fence;
> +   struct xshmfence *shm_fence;
> int  fence_fd;
> __DRIimage   *image_planar;
> int  stride, offset;
> diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
> index c892800..4bffeb7 100644
> --- a/src/glx/dri3_priv.h
> +++ b/src/glx/dri3_priv.h
> @@ -87,7 +87,7 @@ struct dri3_buffer {
>  */
>  
> uint32_t sync_fence; /* XID of X SyncFence object */
> -   int32_t  *shm_fence; /* pointer to xshmfence object */
> +   struct xshmfence *shm_fence; /* pointer to xshmfence object */

Would be great to line these comments up.  Patches 2 and 4-6 are:
Reviewed-by: Kenneth Graunke 

> GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
> void *driverPrivate;
>  
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: Pretend we don't support BRW_SURFACEFORMAT_R16G16B16_FLOAT for textures.

[Chris Forbes]

None of the other 3-component 16bpc formats are directly supported, so
they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
way makes texture views much more fiddly -- we don't want to have to do
crazy copying behind the scenes.

(with my other master + my experimental ARB_texture_view support) fixes
the piglit test: `spec/ARB_texture_view/view compare 48bit formats`

No regressions in gpu.tests on Haswell.

Signed-off-by: Chris Forbes 
---
 src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 90e43a7..f935e69 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -267,7 +267,7 @@ const struct surface_format_info surface_formats[] = {
SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, BRW_SURFACEFORMAT_R64G64B64_FLOAT)
SF( Y,  Y,  x,  x,  x,  x,  x,  x,  x, BRW_SURFACEFORMAT_BC4_SNORM)
SF( Y,  Y,  x,  x,  x,  x,  x,  x,  x, BRW_SURFACEFORMAT_BC5_SNORM)
-   SF(50, 50,  x,  x,  x,  x, 60,  x,  x, BRW_SURFACEFORMAT_R16G16B16_FLOAT)
+   SF( x,  x,  x,  x,  x,  x, 60,  x,  x, BRW_SURFACEFORMAT_R16G16B16_FLOAT)
SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, BRW_SURFACEFORMAT_R16G16B16_UNORM)
SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, BRW_SURFACEFORMAT_R16G16B16_SNORM)
SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, BRW_SURFACEFORMAT_R16G16B16_SSCALED)
-- 
1.8.5.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/18] Remove glBlendColor and glBlendEquations decls from glext.h

[Keith Packard]

Kenneth Graunke  writes:

> NAK.  These headers come directly from Khronos; we need to somehow get
> this fixed upstream and take their version.

Until they're fixed upstream, we should fix them when incorporating them
into the repository. Having broken headers in our code just because
they're broken upstream doesn't make any sense.

I can envision a fairly simple script that would fetch the current
version from khronos, apply a sequence of patches and then commit the
result to the mesa repository.

-- 
keith.pack...@intel.com


pgpFDeBYIjKkD.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 04/18] dri3: Switch to libxshmfence version 1.1

[Keith Packard]

Kenneth Graunke  writes:

> Would be great to line these comments up.

Fixed.

> Patches 2 and 4-6 are:
> Reviewed-by: Kenneth Graunke 

Review marked. Thanks much!

-- 
keith.pack...@intel.com


pgpkJlR4qfmew.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev