From: "Xiong, James"
The vma high heap's capacity and maximum address were pre-defined based
on 48bits ppgtt support, and the buffers allocated from the vma high heap
had invalid vma addresses to the ehl platform that only supports 36bits
ppgtt. As a result, KMD rejected all batchbuffers submitte
From: "Xiong, James"
UMDs such as modesetting can use legacy ADDFD which doesn't accept
Y-tiled buffer, ths patch sets the default tiling mode to X-tiled
for backward compatibility.
Signed-off-by: Xiong, James
---
src/gallium/drivers/iris/iris_resource.c | 3 ++-
1 file changed, 2 insertions(+
On Fri, 11 May 2018 16:57:22 +0100
Chris Wilson wrote:
> Quoting James Xiong (2018-05-11 16:35:04)
> > On Thu, 10 May 2018 13:56:12 -0700
> > Kenneth Graunke wrote:
> >
> > > On Friday, May 4, 2018 5:56:04 PM PDT James Xiong wrote:
> > > > From: &
On Thu, 10 May 2018 13:56:12 -0700
Kenneth Graunke wrote:
> On Friday, May 4, 2018 5:56:04 PM PDT James Xiong wrote:
> > From: "Xiong, James"
> >
> > Now that a bucket contains cached buffers with different sizes, go
> > through its list and search
On Sat, 5 May 2018 08:55:24 +0100
Chris Wilson wrote:
> Quoting James Xiong (2018-05-05 01:56:05)
> > From: "Xiong, James"
> >
> > When one of cached buffers is found to be evicted by kernel,
> > most likely the buffers freed earlier than this buffer ar
On Sat, 5 May 2018 09:11:28 +0100
Chris Wilson wrote:
> Quoting James Xiong (2018-05-05 01:56:01)
> > This series align the buffer size up to page instead of a bucket
> > size to improve memory allocation efficiency.
>
> It doesn't though. It still retrieves up to
From: "Xiong, James"
When one of cached buffers is found to be evicted by kernel,
most likely the buffers freed earlier than this buffer are
gone too, go through the cached list in the bucket and purge.
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 17 ++-
From: "Xiong, James"
With the current implementation, brw_bufmgr may round up a request
size to the next bucket size, result in 25% more memory allocated in
the worst senario. For example:
Request sizeActual size
32KB+1Byte 40KB
.
8MB+1Byte 10MB
.
96MB+1Byte 112MB
This series
From: "Xiong, James"
a buffer is now put in cached bucket #n when its size is between
bucket[n].size and bucket[n+1].size - 1
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/
From: "Xiong, James"
split bo_alloc_internal, and add a new function cached_bo_for_size
searches for a suitable cached buffer for a given size.
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 92 +-
1 file changed, 45 insertions(+), 47 d
From: "Xiong, James"
Now that a bucket contains cached buffers with different sizes, go
through its list and search for a cached buffer with enough size.
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 21 +++--
src/util/list.h|
On Wed, 2 May 2018 14:18:21 +0300
Eero Tamminen wrote:
> Hi,
>
> On 02.05.2018 02:25, James Xiong wrote:
> > From: "Xiong, James"
> >
> > With the current implementation, brw_bufmgr may round up a request
> > size to the next bucket size, result in
From: "Xiong, James"
split bo_alloc_internal, and add a new function cached_bo_for_size
searches for a suitable cached buffer for a given size.
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 92 +-
1 file changed, 45 insertions(+), 47 d
From: "Xiong, James"
Now that a bucket contains cached buffers with different sizes, go
through its list and search for a cached buffer with enough size.
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 21 +++--
src/util/list.h|
From: "Xiong, James"
With the current implementation, brw_bufmgr may round up a request
size to the next bucket size, result in 25% more memory allocated in
the worst senario. For example:
Request sizeActual size
32KB+1Byte 40KB
.
8MB+1Byte 10MB
.
96MB+1Byte 112MB
This series
From: "Xiong, James"
a buffer is now put in cached bucket #n when its size is between
bucket[n].size and bucket[n+1].size - 1
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/
From: "Xiong, James"
When one of cached buffers is found to be evicted by kernel,
most likely the buffers freed earlier than this buffer are
gone too, go through the cached list in the bucket and purge.
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 17 ++-
From: "Xiong, James"
Signed-off-by: Xiong, James
---
src/mesa/main/texstorage.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index 44edba3..9cb8b90 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -445,6 +
On Fri, 27 Apr 2018 12:32:09 +1000
Timothy Arceri wrote:
> Reviewed-by: Timothy Arceri
>
> It would also be nice to have a piglit test for this case. I assume
> mesa probably crashes without this patch?
Thanks for the review. Yes there was a segmentation fault.
>
> On 27/
From: "Xiong, James"
Signed-off-by: Xiong, James
---
src/mesa/main/shaderapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 44b18af..caa4254 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
On Fri, 13 Apr 2018 14:33:09 -0700
Kenneth Graunke wrote:
> On Friday, April 13, 2018 2:08:40 PM PDT James Xiong wrote:
> > On Fri, 13 Apr 2018 13:51:02 -0700
> > Kenneth Graunke wrote:
> >
> > > On Friday, April 13, 2018 1:35:45 PM PDT Kenneth Graunke wrote
On Fri, 13 Apr 2018 13:51:02 -0700
Kenneth Graunke wrote:
> On Friday, April 13, 2018 1:35:45 PM PDT Kenneth Graunke wrote:
> > On Monday, April 9, 2018 4:06:16 PM PDT James Xiong wrote:
> > > From: "Xiong, James"
> > >
> > > On non-LLC p
From: "Xiong, James"
On non-LLC platforms, we malloc shadow batch/state buffers
of the same sizes as our batch/state buffers' GEM allocations.
However the buffer allocator reuses similar-sized gem objects,
it returns a buffer larger than we asked for in some cases
and we end up with smaller shado
From: "Xiong, James"
When creating a image from a texture, the image's dri_format is
set to the first plane's format, and used to look up for the
fourcc. e.g. for FOURCC_NV12 texture, the dri_format is set to
__DRI_IMAGE_FORMAT_R8, we end up with a wrong entry in function
intel_lookup_fourcc():
On Thu, 5 Apr 2018 20:57:46 +0300
Tapani Pälli wrote:
> On 05.04.2018 18:43, James Xiong wrote:
> > On Thu, 5 Apr 2018 14:30:02 +0300
> > Tapani Pälli wrote:
> >
> >> On 04/05/2018 02:51 AM, James Xiong wrote:
> >>> From: "Xiong, James"
On Thu, 5 Apr 2018 08:56:54 -0700
Jason Ekstrand wrote:
> On Thu, Apr 5, 2018 at 8:45 AM, James Xiong
> wrote:
>
> > On Thu, 5 Apr 2018 08:24:27 -0700
> > Jason Ekstrand wrote:
> >
> > > Does this fix a bug? If so, what?
> > Jason, yes. I am sorr
On Thu, 5 Apr 2018 08:24:27 -0700
Jason Ekstrand wrote:
> Does this fix a bug? If so, what?
Jason, yes. I am sorry for the confusion, please see my earlier reply
to Tapani.
>
> On April 4, 2018 16:57:21 James Xiong wrote:
>
> > From: "Xiong, James"
> >
On Thu, 5 Apr 2018 14:30:02 +0300
Tapani Pälli wrote:
> On 04/05/2018 02:51 AM, James Xiong wrote:
> > From: "Xiong, James"
> >
> > The planar_format in __DRIimage contains the original fourcc
> > used to create the image, if it's set, return the save
On Thu, 5 Apr 2018 15:05:26 +0300
Tapani Pälli wrote:
> Hi;
>
> On 04/05/2018 02:51 AM, James Xiong wrote:
> > From: "Xiong, James"
> >
> > The importer creates an image out of the imported FOURCC_NV12
> > texture, the image's dri_format i
From: "Xiong, James"
When creating a image from a texture, initialize the image's planar_format
with the texture's.
Signed-off-by: Xiong, James
---
src/mesa/drivers/dri/i965/intel_screen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/
From: "Xiong, James"
The importer creates an image out of the imported FOURCC_NV12 texture,
the image's dri_format is set to R8(same as the first plane's format),
when it queries the image's fourcc, mesa goes through intel_image_format
table and returns FOURCC_R8.
The solution is to 1) set the i
From: "Xiong, James"
The planar_format in __DRIimage contains the original fourcc
used to create the image, if it's set, return the saved fourcc
directly; Otherwise fall back to the old way.
Also we should validate the input parameter "value" first as it
might be NULL based on the SPEC.
v2: fal
32 matches
Mail list logo
