date:20170330

Re: [Mesa-dev] [PATCH] i965: Fix GLX_MESA_query_renderer video memory on 32-bit.

2017-03-30 Thread Kenneth Graunke

On Thursday, March 30, 2017 6:48:38 PM PDT Kenneth Graunke wrote:
> On Thursday, March 30, 2017 4:38:14 PM PDT Chris Wilson wrote:
> > On Thu, Mar 30, 2017 at 04:28:19PM -0700, Kenneth Graunke wrote:
> > > On modern systems with 4GB apertures, the size in bytes is 4294967296,
> > > or (1ull << 32).  The kernel gives us the aperture size as a __u64,
> > > which works out great.
> > > 
> > > Unfortunately, libdrm "helpfully" returns the data as a size_t, which
> > > on 32-bit systems means it truncates the aperture size to 0 bytes.
> > > We've happily reported this value as 0 MB of video memory via
> > > GLX_MESA_query_renderer since it was originally exposed.
> > > 
> > > This patch bypasses libdrm and calls the ioctl ourselves so we can
> > > use a proper uint64_t, avoiding the 32-bit integer overflow.  We now
> > > report a proper video memory size on 32-bit systems.
> > > ---
> > >  src/mesa/drivers/dri/i965/intel_screen.c | 16 
> > >  1 file changed, 12 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> > > b/src/mesa/drivers/dri/i965/intel_screen.c
> > > index 811a9c5a867..f94e8a77c10 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > > @@ -950,6 +950,17 @@ static const __DRIimageExtension intelImageExtension 
> > > = {
> > >  .createImageWithModifiers   = 
> > > intel_create_image_with_modifiers,
> > >  };
> > >  
> > > +static uint64_t
> > > +get_aperture_size(int fd)
> > > +{
> > > +   struct drm_i915_gem_get_aperture aperture;
> > > +
> > > +   if (drmIoctl(fd, DRM_IOCTL_I915_GEM_GET_APERTURE, ) != 0)
> > > +  return 0;
> > 
> > The aperture is nothing to do with the video memory limits... You want
> > to query the context for the size of the GTT, e.g.
> > https://patchwork.freedesktop.org/patch/62189/
> > 
> > i.e.
> > static uint64_t get_gtt_size(int fd)
> > {
> >struct drm_i915_gem_context_param p;
> >size_t mappable_size, aper_size;
> > 
> >memset(, 0, sizeof(p));
> >p.param = I915_CONTEXT_PARAM_GTT_SIZE;
> >if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0)
> >   return p.value;
> > 
> >/* do sometheing useful for old kernels */
> > 
> >drm_intel_get_aperture_sizes(fd, _size, _size);
> > 
> >return aper_size;
> > }
> 
> It's somewhat debatable what a unified memory GPU should return for a
> "Number of megabytes of video memory available to the renderer" query,
> as there really isn't a concept of video RAM.
> 
> When Ian implemented this, he chose to pick the amount of memory that
> a single batch can reference, which is 3/4 of the aperture.  This may
> be too small - applications can certainly use more memory than that.
> However, their working set for a draw had better fit within this limit,
> or else there will be a performance penalty.  I think it's pretty
> reasonable for what applications want.  They're trying to gauge how
> high-res their textures can be without incurring penalties.
> 
> I know Ian also spoke with a number of game vendors when drafting
> and implementing this extension, so I'm inclined to trust his
> interpretation.
> 
> I don't think exposing GTT_SIZE is useful.  With 48-bit addressing
> and PPGTT, the result of that query will be (1ull << 48) aka 256
> terabytes.  There is no way in hell that an application can use
> that much RAM.  We could restrict it to the total system RAM, but
> even then, it would not be performant to try and use all of RAM.

Okay, I missed that right below, we limit it to the amount of system
RAM.  So it'll never be 256 terabytes.  That's more reasonable.

Still not sure whether it's the right thing to do, though.

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] egl/android: Dequeue buffers inside EGL calls

2017-03-30 Thread Rob Clark

On Fri, Mar 31, 2017 at 12:22 AM, Tapani Pälli  wrote:
>
>
> On 03/30/2017 05:57 PM, Emil Velikov wrote:
>>
>> On 30 March 2017 at 15:30, Tomasz Figa  wrote:
>>>
>>> On Thu, Mar 30, 2017 at 11:17 PM, Emil Velikov 
>>> wrote:


 On 30 March 2017 at 11:55, Tomasz Figa  wrote:
>
> Android buffer queues can be abandoned, which results in failing to
> dequeue next buffer. Currently this would fail somewhere deep within
> the DRI stack calling loader's getBuffers*(), without any error
> reporting to the client app. However Android framework code relies on
> proper signaling of this event, so we move buffer dequeue to
> createWindowSurface() and swapBuffers() call, which can generate proper
> EGL errors. To keep the performance benefits of delayed buffer
> handling,
> if any, fence wait and DRI image creation is kept delayed until
> getBuffers*() is called by the DRI driver.
>
 Thank you Tomasz.

 I'm fairly confident that this should resolve the crash [in
 swap_buffers] that Mauro was seeing.
 Mauro can you give it a test ?
>>>
>>>
>>> Ah, I actually noticed a problem with existing code, supposedly fixed
>>> by [1], but I'm afraid it's still wrong.
>>>
>>> Current swap_buffers calls get_back_bo(), but doesn't call
>>> update_buffers(), which is the function that should be called before
>>> to actually dequeue a buffer from Android's buffer queue. Given that,
>>> get_back_bo() would simply fail with !dri2_surf->buffer, because no
>>> buffer was dequeued.
>>>
>> Right - I was wondering why we don't hit that on EGL/GBM or EGL/Wayland.
>> From a quick look - may be because EGL/Android drops the dpy mutex in
>> droid_window_enqueue_buffer().
>>
>>> My patch removes update_buffers() and changes the buffer management so
>>> that there is always a buffer dequeued, starting from surface
>>> creation, unless there was an error somewhere.
>>>
>> Of the top of your head - is there something stopping us from using
>> the same method on $other platforms?
>>
>>> [1]
>>> https://cgit.freedesktop.org/mesa/mesa/commit/src/egl/drivers/dri2/platform_android.c?id=4d4558411db166d2d66f8cec9cb581149dbe1597
>>>


 Not that huge of an expert on the Android specifics, so just a humble
 request:
 Can we seek the code resuffle (droid_{alloc,free}_local_buffer,
>>
>> Oops silly typo - s/seek/split/.
>>
 other?) separate from the functionality changes ?
>>>
>>>
>>> Sure. Thanks for suggestion.
>>>
>> Please give it a day or two for others to comment.
>
>
> I'm trying to debug why this causes our homescreen (wallpaper) to be black.
> Otherwise I haven't seen any issues with these changes.
>

wallpaper seems to be a special sorta hell..  I wonder if there is
somehow some sort of interaction with what I fixed / worked-around in
a5e733c6b52e93de3000647d075f5ca2f55fcb71 ??

Maybe at least try commenting out the temp-pbuffer thing to get max
texture size, and see if that "fixes" things

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] gm107/ir: Emit SV_CLOCK system value

2017-03-30 Thread Boyan Ding

2017-03-31 11:21 GMT+08:00 Ilia Mirkin :
> Did you check what the blob does? There's clocklo/hi and
> globaltimerlo/hi. Without additional documentation, it's a bit hard to
> tell the difference... Note that envydis's gf100.c/gk110.c disagree on
> which is which. Probably not due to any architectural reasons, but due
> to RE methodology. (From before nvdisasm was
> available/trusted/used/whatever.)

(replying to your concern in 1 and 2 at the same time)

I have checked against the blob and nvidisasm before, and gk110.c in
envydis was actually wrong. I made a PR for that [1].

This is what I get when using clockARB() on GK208:
281c0006 8640 mov b32 $r1 $sr80
289c0002 8640 mov b32 $r0 $sr81
(note $r1 <- $sr80, $r0 <- $sr81, and they are called SR_CLOCKLO and
SR_CLOCKHI in nvdisasm respectively)

I haven't really checked with maxwell+, just believing in the
correctness in envydis and uniformity between architectures. But I
will check when I reach my pascal machine later.

Cheers.
Boyan Ding

[1] https://github.com/envytools/envytools/pull/84

>
> On Thu, Mar 30, 2017 at 10:33 PM, Boyan Ding  wrote:
>> Signed-off-by: Boyan Ding 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
>> index 6de3f396e3..ab9c94b4d0 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
>> @@ -269,6 +269,7 @@ CodeEmitterGM107::emitSYS(int pos, const Value *val)
>> case SV_INVOCATION_INFO: id = 0x1d; break;
>> case SV_TID: id = 0x21 + val->reg.data.sv.index; break;
>> case SV_CTAID  : id = 0x25 + val->reg.data.sv.index; break;
>> +   case SV_CLOCK  : id = 0x50 + val->reg.data.sv.index; break;
>> default:
>>assert(!"invalid system value");
>>id = 0;
>> --
>> 2.12.0
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] egl/android: Dequeue buffers inside EGL calls

2017-03-30 Thread Tapani Pälli

On 03/30/2017 05:57 PM, Emil Velikov wrote:

On 30 March 2017 at 15:30, Tomasz Figa wrote:

On Thu, Mar 30, 2017 at 11:17 PM, Emil Velikov wrote:

On 30 March 2017 at 11:55, Tomasz Figa wrote:

Android buffer queues can be abandoned, which results in failing to
dequeue next buffer. Currently this would fail somewhere deep within
the DRI stack calling loader's getBuffers*(), without any error
reporting to the client app. However Android framework code relies on
proper signaling of this event, so we move buffer dequeue to
createWindowSurface() and swapBuffers() call, which can generate proper
EGL errors. To keep the performance benefits of delayed buffer handling,
if any, fence wait and DRI image creation is kept delayed until
getBuffers*() is called by the DRI driver.

Thank you Tomasz.

I'm fairly confident that this should resolve the crash [in
swap_buffers] that Mauro was seeing.
Mauro can you give it a test ?

Ah, I actually noticed a problem with existing code, supposedly fixed
by [1], but I'm afraid it's still wrong.

Current swap_buffers calls get_back_bo(), but doesn't call
update_buffers(), which is the function that should be called before
to actually dequeue a buffer from Android's buffer queue. Given that,
get_back_bo() would simply fail with !dri2_surf->buffer, because no
buffer was dequeued.

Right - I was wondering why we don't hit that on EGL/GBM or EGL/Wayland.
From a quick look - may be because EGL/Android drops the dpy mutex in
droid_window_enqueue_buffer().

My patch removes update_buffers() and changes the buffer management so
that there is always a buffer dequeued, starting from surface
creation, unless there was an error somewhere.

1 2 3 >

1 - 100 of 231 matches

Mail list logo