On Son, 2014-04-06 at 15:26 +0300, Lauri Kasanen wrote:
> Hi,
>
> Obviously old userspace + new kernel combo needs to be supported. But
> I'm not so sure about a mixed case, does old userspace + new userspace
> need to be supported to run at the same time?
>
> For example, a new 64-bit
On Sun, 6 Apr 2014 19:58:48 +0200
Daniel Vetter wrote:
> On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen wrote:
> > This is related to my memory management work. As the VRAM queue is
> > global, it cannot be determined on a per-app basis. If at least one
> > client is running old userspace, the
On Sun, 6 Apr 2014 10:53:58 -0400
Rob Clark wrote:
> On Sun, Apr 6, 2014 at 8:26 AM, Lauri Kasanen wrote:
> > Hi,
> >
> > Obviously old userspace + new kernel combo needs to be supported. But
> > I'm not so sure about a mixed case, does old userspace + new userspace
> > need to be supported to
On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen wrote:
>> Maybe you can give a better description of what you are wanting to do?
>> Could you decide on 32b vs 64b userspace on a per 'struct drm_file'
>> basis (ie. each time /dev/dri/cardN is opened)?
>
> This is related to my memory management
Hi,
Obviously old userspace + new kernel combo needs to be supported. But
I'm not so sure about a mixed case, does old userspace + new userspace
need to be supported to run at the same time?
For example, a new 64-bit mesa+libdrm and a 32-bit old set, both
running apps at the same time.
Or is it
On Sun, Apr 6, 2014 at 8:26 AM, Lauri Kasanen wrote:
> Hi,
>
> Obviously old userspace + new kernel combo needs to be supported. But
> I'm not so sure about a mixed case, does old userspace + new userspace
> need to be supported to run at the same time?
>
> For example, a new 64-bit mesa+libdrm