-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
copy I915 header file directly #1
base: i915_cleanup
Are you sure you want to change the base?
Conversation
This change moves vdbox balancing under MEDIA_EXT define. Configure driver build as follows to get support of this feature: cmake -DMEDIA_EXT=ON /path/to/media-driver By default it is disabled Change-Id: Ia89e4beb1d3bdf681efbf40d9fb5159fe3663be3 Signed-off-by: Dmitry Rogozhkin <[email protected]>
This change moves sseu under MEDIA_EXT define. Configure driver build as follows to get support of this feature: cmake -DMEDIA_EXT=ON /path/to/media-driver By default it is disabled. Change-Id: Ifdba7d12207a075fad11722fce4e7bc547b9b227 Signed-off-by: Dmitry Rogozhkin <[email protected]>
Change-Id: Ic9d70835e3c51a79b1f0404e13f861d920c8f7ea Signed-off-by: Dmitry Rogozhkin <[email protected]>
This patch removes all Android customizations except pad_to_size support which actually landed upstream. It will be enabled in one of the next patches. Change-Id: Ib7c8b190e35ee839c95de21863e4ff58a827d75e Signed-off-by: Dmitry Rogozhkin <[email protected]>
i915 driver got DRM_I915_PERF_* ioctls support. Custom DRM_I915_PERFMON should no longer be needed. Change-Id: I2c1538c84b4565eacfcc94ee5c85c8c267f393f2 Signed-off-by: Dmitry Rogozhkin <[email protected]>
These ioctls seems not being used anywhere in media driver: * DRM_I915_GEM_ACCESS_USERDATA * define DRM_I915_CMD_PARSER_APPEND * define DRM_I915_EXT_IOCTL Change-Id: I729404ac854fe6510c719a1fd0dfef577800d960 Signed-off-by: Dmitry Rogozhkin <[email protected]>
Upstream i915 driver got support for pad_to_size. WARNING: this patch changes definition of EXEC_OBJECT_PAD_TO_SIZE from (custom): #define EXEC_OBJECT_PAD_TO_SIZE (1<<4) to (upstream): #define EXEC_OBJECT_PAD_TO_SIZE (1<<5) It is required for Android kernels to be adjusted correspondingly, i.e. aligned with the afficial upstream version. Change-Id: Ibf4c06b792cda2d4a117aa46411c0db9f6afdbfd Signed-off-by: Dmitry Rogozhkin <[email protected]>
After this change: * i915_drm_mock.h - fully synced with upstream * i915_drm.h - still contains few Android customizations Change-Id: I6fba9ce1691b362128ea5deedaf63737f69ed9bb Signed-off-by: Dmitry Rogozhkin <[email protected]>
5c552fc
to
1e802fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe there were other places in i915 API implementation which we would like to cleanup (Android customizations).
#ifndef _I915_HEADER_H_ | ||
#define _I915_HEADER_H_ | ||
#ifndef __user | ||
#define __user |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of the __user? And what's the purpose of i915_header.h?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we want the i915_drm.h is bitmatch with upstreamed drm_tip. but in the header , there are key word "__user" right? , instead of removing it, I prefer to add a define, it will delete it automatically.
hi @dvrogozh , long term target is remove all #ifdef ANDROID in whole driver (DDI, HAL, OS etc.) |
Signed-off-by: XinfengZhang <[email protected]>
i915_drm.h is from drm_tip/include/uapi/drm/i915_drm.h commit id is cd956bfcd0f58d20485ac0a785415f7d9327a95f Signed-off-by: XinfengZhang <[email protected]>
directly refer the header file in mos folder Signed-off-by: XinfengZhang <[email protected]>
__u32 pad; | ||
__u32 flags; | ||
#define I915_CREATE_PLACEMENT_NORMAL 0 /* standard swappable bo */ | ||
#define I915_CREATE_PLACEMENT_STOLEN 1 /* Cannot use CPU mmaps */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought you said that STOLEN is not used at the moment? Does that mean we can entirely remove __flags
right now?
I believe that answer is probably "Yes". Here is some grep results:
[dvrogozh@dvrscl media-driver]$ fgrep -rsn I915_CREATE_PLACEMENT_NORMAL media_driver/
media_driver/linux/common/os/libdrm/include/i915_drm.h:654:#define I915_CREATE_PLACEMENT_NORMAL 0 /* standard swappable bo */
[dvrogozh@dvrscl media-driver]$ fgrep -rsn I915_CREATE_PLACEMENT_STOLEN media_driver/
media_driver/linux/common/os/libdrm/include/i915_drm.h:655:#define I915_CREATE_PLACEMENT_STOLEN 1 /* Cannot use CPU mmaps */
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1012: create.flags |= I915_CREATE_PLACEMENT_STOLEN;
[dvrogozh@dvrscl media-driver]$ fgrep -rsn I915_CREATE_PLACEMENT_MASK media_driver/
media_driver/linux/common/os/libdrm/include/i915_drm.h:656:#define I915_CREATE_PLACEMENT_MASK 0xff
[dvrogozh@dvrscl media-driver]$ fgrep -rsn I915_CREATE_POPULATE media_driver/
media_driver/linux/common/os/libdrm/include/i915_drm.h:657:#define I915_CREATE_POPULATE (1<<8) /* Pre-populate object pages */
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1015: create.flags |= I915_CREATE_POPULATE;
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1040: create.flags |= I915_CREATE_POPULATE;
[dvrogozh@dvrscl media-driver]$ fgrep -rsn I915_CREATE_FLUSH media_driver/
media_driver/linux/common/os/libdrm/include/i915_drm.h:658:#define I915_CREATE_FLUSH (1<<9) /* Clflush prepopulated pages */
media_driver/linux/common/os/libdrm/include/i915_drm.h:659:#define __I915_CREATE_UNKNOWN_FLAGS -(I915_CREATE_FLUSH << 1)
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1018: create.flags |= I915_CREATE_FLUSH;
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1043: create.flags |= I915_CREATE_FLUSH;
[dvrogozh@dvrscl media-driver]$ fgrep -rsn BO_ALLOC_STOLEN media_driver/
media_driver/linux/common/ddi/media_libva_util.cpp:532: bo = mos_bo_alloc_tiled(mediaDrvCtx->pDrmBufMgr, "MEDIA", gmmPitch, gmmSize/gmmPitch, 1, &tileformat, (unsigned long *)&ulPitch, BO_ALLOC_STOLEN);
media_driver/linux/common/os/libdrm/include/mos_bufmgr.h:133:#define BO_ALLOC_STOLEN (1<<1)
media_driver/linux/common/os/libdrm/mos_bufmgr.c:916: if (flags & BO_ALLOC_STOLEN) {
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1011: if (flags & BO_ALLOC_STOLEN)
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1025: if (flags & BO_ALLOC_STOLEN) {
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1083: if (flags & BO_ALLOC_STOLEN)
media_driver/linux/common/os/mos_graphicsresource_specific.cpp:281: &tileFormatLinux, &linuxPitch, BO_ALLOC_STOLEN);
media_driver/linux/common/os/mos_os_specific.c:2087: &tileformat_linux, &ulPitch, BO_ALLOC_STOLEN);
[dvrogozh@dvrscl media-driver]$ fgrep -rsn BO_ALLOC_POPULATE media_driver/
media_driver/linux/common/os/libdrm/include/mos_bufmgr.h:134:#define BO_ALLOC_POPULATE (1<<2)
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1014: if (flags & BO_ALLOC_POPULATE)
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1039: if (flags & BO_ALLOC_POPULATE)
[dvrogozh@dvrscl media-driver]$ fgrep -rsn BO_ALLOC_FLUSH media_driver/
media_driver/linux/common/os/libdrm/include/mos_bufmgr.h:135:#define BO_ALLOC_FLUSH (1<<3)
media_driver/linux/common/os/libdrm/mos_bufmgr.c:994: if (alloc_from_cache && (flags & BO_ALLOC_FLUSH))
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1017: if (flags & BO_ALLOC_FLUSH)
media_driver/linux/common/os/libdrm/mos_bufmgr.c:1042: if (flags & BO_ALLOC_FLUSH)
So, the only usage is for BO_ALLOC_STOLEN, but if you will take a look to the code:
&tileformat_linux, &ulPitch, BO_ALLOC_STOLEN); |
and
&tileFormatLinux, &linuxPitch, BO_ALLOC_STOLEN); |
you will see that it is covered by I915_PARAM_CREATE_VERSION and I don't see that it is defined anywhere in the driver:
[dvrogozh@dvrscl media-driver]$ fgrep -rsn I915_PARAM_CREATE_VERSION
media_driver/linux/common/ddi/media_libva_util.cpp:522:#if defined(I915_PARAM_CREATE_VERSION)
media_driver/linux/common/ddi/media_libva_util.cpp:528: gp.param = I915_PARAM_CREATE_VERSION;
media_driver/linux/common/os/mos_graphicsresource_specific.cpp:266:#if defined(I915_PARAM_CREATE_VERSION)
media_driver/linux/common/os/mos_graphicsresource_specific.cpp:274: gp.param = I915_PARAM_CREATE_VERSION;
media_driver/linux/common/os/mos_os_specific.c:2073:#if defined(I915_PARAM_CREATE_VERSION)
media_driver/linux/common/os/mos_os_specific.c:2081: gp.param = I915_PARAM_CREATE_VERSION;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I suggest to attempt to simply remove __flags and related code. How do you think?
The problem here is that mos_gem_bo_bucket_for_size() implementations diverged between Linux/Android. I am not sure how safe we would be to reuse Linux variant on Android. We should, but...
3d4c1b9
to
eb0fcf4
Compare
eb0fcf4
to
8fe32e6
Compare
8fe32e6
to
7692e41
Compare
Two concurrent DdiMedia_SyncSurface function calls read and write the same data when the second frame uses the first frame as a reference frame. Enqueue frames order: Frame #0 Frame #1 (uses #0 as a reference) Threads release order: Thread #1 (waits for Frame #1) Thread #0 (waits for Frame #0) Resolution is lock with the mutex the problem source code (read and update StatusReport), so only one thread writes the data, the second thread is waiting.
Change-Id: Ibaffb10cfc10ca7128e241804f2281323202fe13
mhw changes #1 Change-Id: I5c6243ee48aa608531b2c1e966308868747dad88
SVN Backmerge - Encoder codechal changes #1 Change-Id: I67188ff41e483925c630f414eeb2dd23078dd7ce
No description provided.