Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
"Matias N. Goldberg" writes: > I read your article. Thanks! > What I feel are missing are just minor pesky details: Yes, it's definitely a rough draft at best. Figuring out the right words to make it do precisely what we want is hard, and I'm hoping we can first figure out what we want, then figure out how to say that precisely. > 1. Written as is, the frame being submitted is rounded up to display > timing, delaying *future* frames.But there is no way to delay the > *currently displaying frame* (i.e. the 'previous' frame). Correct. The period provided controls how long the specified frame will be shown to the user (at a minimum). Future frames will be delayed by at least that long. > Right now if frame N was submitted without VkPresentTimeMESA but frame > N+1 is, then frame N+1 will be presented to screen ASAP. Correct. > What I'm saying is that if frame N was submitted without > VkPresentTimeMESA, then at frame N+1 I should be able to tell 'keep > frame N displayed for at least P nanoseconds since it was displayed, > and *then* present frame N+1, which is the frame I am now submitting' That's not what this extension does; if you wanted frame 'N' to be displayed for 'P' nanoseconds, then you would specify 'P' when queuing frame 'N'. > The API needs to be expanded further to explain Vulkan what a 'frame' > is.Is it the monitor's refresh rate? KHR_swapchain and EXT_display_surface_counter both mention 'vertical blanking periods'. GOOGLE_display_timing has vkGetRefreshCycleDurationGOOGLE which returns 'refreshDuration'. 'frame' is also used throughout Vulkan and seems to describe one of a sequence of images displayed to the user. Coming up with language which ties back into all of these would be helpful. > Or is it an arbitrary elapsed time defined in the form numerator and > denominator? (e.g. 60hz is numerator = 1, denominator = 60; 59.94hz is > numerator = 1001 denominator = 6000)By specifying arbitrary > definitions of a frame, it is possible to be compatible with variable > refresh rates e.g. for VRR monitors, applications may define > denominator = 240 or denominator = 120 When I talked about 'frames' in my informal description, I could have clarified that by referring to the GOOGLE_display_timing 'refreshDuration' value. I think that variable refresh rate monitors would be expected to set that to a useful value, possibly based on the nominal display period, but I don't know. I think that we'll need some more Vulkan extensions designed to expose the capabilities and limits of variable refresh rate monitors. Do we need to do that in conjunction with this extension, or can we define this extension in such a way that it should work with whatever we end up with in the future? -- -keith signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
Michel Dänzer writes: > Instead of rounding to the nearest upcoming frame, should it round to > the earliest frame after the specified period has passed? As written, it > seems to contradict the next paragraph below: Sorry for the poor wording; let me describe what I want informally here. For nanosecond periods to be easy to use on fixed-refresh-rate monitors, I want the näive computation to "just work". For a given refresh period, 'r', I want to select a period of 'n' frames using: computed_period = n * r Because of clock skew and rounding problems, it's quite possible that the period could easily end up being just slightly smaller than that: actual_period = n * r - ε When I said 'nearest', what I intended to describe was that the target frame would be as close as possible to the specified time. > (I'm not ruling out that rounding to nearest might be better, but there > should be a rationale for it, which also justifies being inconsistent > with GOOGLE_display_timing) Yes, this is intentionally inconsistent with GOOGLE_display_timing, which I believe is hard to use correctly. By specifying not before semantics, GOOGLE_display_timing requires applications compute a fake time guaranteed to be not after the actual target frame time. This really messes things up when you might have variable refresh rate monitors. I just went and read the time-based stuff from the X Present extension. That uses 'nearest' semantics too, when supported by the driver. When not supported, the server gets to do whatever it likes (oops!). > I like this extension in general. Thanks! I've been trying to get this posted for a few months now. > However, I think allowing the period to be specified in frames might be > a mistake, because it won't work well with variable refresh rate. But > it'll be tempting for application / toolkit developers not to bother > with proper time calculations but to just use frames instead. (It would > be good to seek feedback on this from AMD DC developers and the larger > DRM kernel driver community as well) Yeah, given that the application will need the refresh period to know what to display, it certainly doesn't provide much technical benefit here. I stuck it in to make the extension feel like GL's swap interval stuff (although it isn't the same), and because it seemed like a 'nice' thing to offer applications. > P.S. It would be good to create a WIP merge request for this in the main > Mesa project, to have a central place for gathering feedback and > tracking progress. Done, thanks for the suggestion. -- -keith signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
Hi! I read your article. What I feel are missing are just minor pesky details: 1. Written as is, the frame being submitted is rounded up to display timing, delaying *future* frames.But there is no way to delay the *currently displaying frame* (i.e. the 'previous' frame). Right now if frame N was submitted without VkPresentTimeMESA but frame N+1 is, then frame N+1 will be presented to screen ASAP. What I'm saying is that if frame N was submitted without VkPresentTimeMESA, then at frame N+1 I should be able to tell 'keep frame N displayed for at least P nanoseconds since it was displayed, and *then* present frame N+1, which is the frame I am now submitting' > However, I think allowing the period to be specified in frames might be> a > mistake, because it won't work well with variable refresh rate The API needs to be expanded further to explain Vulkan what a 'frame' is.Is it the monitor's refresh rate? Or is it an arbitrary elapsed time defined in the form numerator and denominator? (e.g. 60hz is numerator = 1, denominator = 60; 59.94hz is numerator = 1001 denominator = 6000)By specifying arbitrary definitions of a frame, it is possible to be compatible with variable refresh rates e.g. for VRR monitors, applications may define denominator = 240 or denominator = 120 It should also be possible to dynamically change how long a frame lasts, in case the GPU simply can't catch up (e.g. specifying a denominator = 240 and using frames when the GPU can only render at 30hz is almost the same as presenting ASAP i.e. the same as not using VK_MESA_present_period at all) Specifying denominator = 0 means using the monitor's native refresh rate. If such concept makes no sense (e.g. VRR?) then the behavior fallbacks to some unspecified low value (like denominator = 240) or some other vendor-defined behavior.The value is unspecified because vendors will likely want to adjust this to an optimal value (e.g. controlled via driver settings in the Control Panel, defined by the Monitor manufacturer, defined by the GPU vendor, etc). CheersMatias___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
On 2020-02-02 7:51 a.m., Keith Packard wrote:
>
> I spent some time over the last week experimenting with a different way
> of doing frame timing.
>
> Instead of specifying *when* a particular frame should be displayed, how
> about we specify how *long* a particular frame should be made visible
> to the user?
>
> This has a couple of advantages over the approach taken in
> GOOGLE_display_timing:
>
> 1. It provides information to the backend about frame timing
> a frame earlier.
>
> 2. Missing a frame can generate fewer artifacts.
>
> Here's what I'm thinking the extension would look like:
>
> An application uses VK_MESA_present_period by including a
> VkPresentPeriodMESA structure in the pNext chain in the
> VkPresentInfoKHR structure passed to the vkQueuePresentKHR call.
>
> typedef struct VkPresentPeriodMESA {
> VkStructureTypesType;
> const void*pNext;
> uint32_t swapchainCount;
> const int64_t* pPresentPeriods;
> } VkPresentPeriodMESA;
>
> The fields in this structure are:
>
> * sType. Set to VK_STRUCTURE_TYPE_PRESENT_PERIOD_MESA
> * pNext. Points to the next extension structure in the chain (if any).
> * swapchainCount. A copy of the swapchainCount field in the
>VkPresentInfoKHR structure.
> * pPresentPeriods. An array, length swapchainCount, of presentation
>periods for each image in the call.
>
> Positive presentation periods represent nanoseconds. Negative
> presentation periods represent frames. A zero value means the
> extension does not affect the associated presentation.
> Nanosecond values are rounded to the nearest upcoming frame so that a
> value of n * refresh_interval is the same as using a value of n
> frames.
Instead of rounding to the nearest upcoming frame, should it round to
the earliest frame after the specified period has passed? As written, it
seems to contradict the next paragraph below:
(I'm not ruling out that rounding to nearest might be better, but there
should be a rationale for it, which also justifies being inconsistent
with GOOGLE_display_timing)
> The presentation period causes *future* images to be delayed at least
> until the specified interval after this image has been
> presented. Specifying both a presentation period in a previous frame
> and using GOOGLE_display_timing is well defined -- the presentation
> will be delayed until the later of the two times.
>
> I've got this kludged together to experiment with; I managed to make it
> work purely within Vulkan using the infrastructure built for
> GOOGLE_display_timing.
>
> https://gitlab.freedesktop.org/keithp/mesa/commits/present-period
>
> I wrote a longer article on my blog:
>
> https://keithp.com/blogs/present-period/
>
> I'm interested in hearing what people think about the general approach.
Repeating my comment on
https://gitlab.freedesktop.org/keithp/mesa/commit/c81c6ffe335032d7c88b68f83360597f7dfd5b60
(hadn't got to this post yet):
I like this extension in general.
However, I think allowing the period to be specified in frames might be
a mistake, because it won't work well with variable refresh rate. But
it'll be tempting for application / toolkit developers not to bother
with proper time calculations but to just use frames instead. (It would
be good to seek feedback on this from AMD DC developers and the larger
DRM kernel driver community as well)
P.S. It would be good to create a WIP merge request for this in the main
Mesa project, to have a central place for gathering feedback and
tracking progress.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Unable to find a matching EGL config on Wayland
On Fri, 31 Jan 2020 14:48:29 +0530 "Devashish Tiwari" said: Hi Devashish. That fact you have "SGX" for demos hints to me that you have some hardware with an Imagination based GPU and drivers provided by them. Their drivers provide EGL and and the implementation of eglChooseConfig() under the hood. You should contact whoever provided you with your drivers for help as Daniel suggested. It very likely is a set of proprietary drivers that Wayland as a project and set of developers who work on and with it have nothing to do with. We can't help with something we didn't build nor even can see the insides of because it's a proprietary binary blob. If you were using Mesa based drivers (I suspect you are not given the above) which are open source and have a lot of common development happen hand in hand with wayland, then we may be able to. > Hi Daniel, > > My application, as I described, requires a display protocol to run. And it is > using wayland. > > Because if I stop weston and run my application, it throws me following error: > > Error- Unable to init SDL: No available video device > > Also, I just checked $WAYLAND_DISPLAY environment variable and it is already > set to 'wayland-0'. > > The fact that eglinfo works perfectly after stopping weston makes me think > that my application uses SDL_EGL_ChooseConfig() to set some EGL > parameters/attributes and then calls _this->egl_data->eglChooseConfig() to > see if it matches any available egl configurations but is not able to match > with configurations returned by this function. And in my opinion, the reason > behind this is _this->egl_data->eglChooseConfig() somehow calls eglinfo it > doesn't return available egl configurations on the EVM and hence matching > fails and egl surface is not created. > > Please check and revert. > > On Fri, 31 Jan 2020 08:27:50 +, Daniel Stone wrote > > Hi Devashish, > It sounds like your application, as well as eglinfo, are not even > trying to use Wayland. Maybe they are autodetecting the platform > incorrectly and trying to use GBM instead. This could perhaps be > solved by setting the $WAYLAND_DISPLAY environment variable to the > name of the socket Weston uses (usually 'wayland-0'). However you > should probably contact The Qt Company for support in using Qt, and > you should contact TI (or your BSP vendor) for support with the > proprietary Imagination EGL/GLES driver. > > Cheers, > Daniel > > On Fri, 31 Jan 2020 at 08:12, Devashish Tiwari wrote: > > > > Hello, > > > > > > I have built a simple application using QT & SDL that has a button which > > opens a preview on clicking, whenever camera (system/usb) is connected to > > the EVM. > > > > My app successfully receives correct parameters related to camera > > (resolution, frame rate, frame format) and I have verified it using debug > > prints. However, when I click on preview button, it crashes and throws > > error related to EGL. > > > > > > On executing it with gdb, I found out that it is not able to get a valid > > EGL configuration. The eglChooseConfig function (in SDL_egl.c) doesn't > > find a matching EGL config and it fails to create a surface and open the > > preview. > > > > Also, I do not get any "EGL 1.4 Initialised" prints when my app executes. > > This print, on the contrary, is visible when I run OGLES2ChameleonMan > > in /usr/bin/SGX/demos/Wayland. > > > > > > On digging further, I found that the "eglinfo" command displays the egl > > configurations on the terminal. > > > > However, when it returns EGL_BAD_ALLOC on my EVM, if I run it without > > stopping weston. It runs successfully only after stopping weston. I am > > assuming this is the reason why my application is not able to find a > > matching EGL config because it runs over weston. > > > > > --- > > > > > root@am57xx-evm:/mnt# eglinfo > > > > eglGetConfigs(): > > == > > ** EGL config number: 0 EGL vendor string: > > Imagination Technologies EGL version string: 1.4 build 1.14@3699939 (MAIN) > > EGL extensions: EGL_IMG_client_api_ogl EGL_KHR_image EGL_KHR_image_base > > EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image > > EGL_KHR_gl_renderbuffer_image EGL_KHR_vg_parent_image EGL_IMG_cl_image > > EGL_KHR_fence_sync EGL_IMG_context_priority EGL_IMG_hibernate_process > > EGL_IMG_image_plane_attribs EGL_KHR_surfaceless_context EGL_KHR_wait_sync > > EGL_KHR_create_context EGL_WL_bind_wayland_display > > EGL_EXT_image_dma_buf_import EGL client APIs are: OpenGL_ES EGL config > > Attributes: EGL_CONFIG_ID = 0x1 EGL_BUFFER_SIZE = 0x20 EGL_RED_SIZE = 0x8 > > EGL_GREEN_SIZE = 0x8 EGL_BLUE_SIZE = 0x8 EGL_LUMINANCE_SIZE = 0x0 > > EGL_ALPHA_SIZE = 0x8 EGL_ALPHA_MASK_SIZE = 0x0 EGL_BIND_TO_TEXTURE_RGB = > > 0x1
Re: [Mesa-dev] Unable to find a matching EGL config on Wayland
Hi Daniel, My application, as I described, requires a display protocol to run. And it is using wayland. Because if I stop weston and run my application, it throws me following error: Error- Unable to init SDL: No available video device Also, I just checked $WAYLAND_DISPLAY environment variable and it is already set to 'wayland-0'. The fact that eglinfo works perfectly after stopping weston makes me think that my application uses SDL_EGL_ChooseConfig() to set some EGL parameters/attributes and then calls _this->egl_data->eglChooseConfig() to see if it matches any available egl configurations but is not able to match with configurations returned by this function. And in my opinion, the reason behind this is _this->egl_data->eglChooseConfig() somehow calls eglinfo it doesn't return available egl configurations on the EVM and hence matching fails and egl surface is not created. Please check and revert. On Fri, 31 Jan 2020 08:27:50 +, Daniel Stone wrote Hi Devashish, It sounds like your application, as well as eglinfo, are not even trying to use Wayland. Maybe they are autodetecting the platform incorrectly and trying to use GBM instead. This could perhaps be solved by setting the $WAYLAND_DISPLAY environment variable to the name of the socket Weston uses (usually 'wayland-0'). However you should probably contact The Qt Company for support in using Qt, and you should contact TI (or your BSP vendor) for support with the proprietary Imagination EGL/GLES driver. Cheers, Daniel On Fri, 31 Jan 2020 at 08:12, Devashish Tiwari wrote: > > Hello, > > > I have built a simple application using QT & SDL that has a button which > opens a preview on clicking, whenever camera (system/usb) is connected to > the EVM. > > My app successfully receives correct parameters related to camera > (resolution, frame rate, frame format) and I have verified it using debug > prints. However, when I click on preview button, it crashes and throws error > related to EGL. > > > On executing it with gdb, I found out that it is not able to get a valid EGL > configuration. The eglChooseConfig function (in SDL_egl.c) doesn't find a > matching EGL config and it fails to create a surface and open the preview. > > Also, I do not get any "EGL 1.4 Initialised" prints when my app executes. > This print, on the contrary, is visible when I run OGLES2ChameleonMan in > /usr/bin/SGX/demos/Wayland. > > > On digging further, I found that the "eglinfo" command displays the egl > configurations on the terminal. > > However, when it returns EGL_BAD_ALLOC on my EVM, if I run it without > stopping weston. It runs successfully only after stopping weston. I am > assuming this is the reason why my application is not able to find a > matching EGL config because it runs over weston. > > --- > > > root@am57xx-evm:/mnt# eglinfo > > eglGetConfigs(): > == > ** EGL config number: 0 EGL vendor string: > Imagination Technologies EGL version string: 1.4 build 1.14@3699939 (MAIN) > EGL extensions: EGL_IMG_client_api_ogl EGL_KHR_image EGL_KHR_image_base > EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image > EGL_KHR_gl_renderbuffer_image EGL_KHR_vg_parent_image EGL_IMG_cl_image > EGL_KHR_fence_sync EGL_IMG_context_priority EGL_IMG_hibernate_process > EGL_IMG_image_plane_attribs EGL_KHR_surfaceless_context EGL_KHR_wait_sync > EGL_KHR_create_context EGL_WL_bind_wayland_display > EGL_EXT_image_dma_buf_import EGL client APIs are: OpenGL_ES EGL config > Attributes: EGL_CONFIG_ID = 0x1 EGL_BUFFER_SIZE = 0x20 EGL_RED_SIZE = 0x8 > EGL_GREEN_SIZE = 0x8 EGL_BLUE_SIZE = 0x8 EGL_LUMINANCE_SIZE = 0x0 > EGL_ALPHA_SIZE = 0x8 EGL_ALPHA_MASK_SIZE = 0x0 EGL_BIND_TO_TEXTURE_RGB = 0x1 > EGL_BIND_TO_TEXTURE_RGBA = 0x1 EGL_COLOR_BUFFER_TYPE = 0x308e EGL_CONF IG_CAVEAT = 0x3038 EGL_CONFORMANT = 0x1 EGL_DEPTH_SIZE = 0x18 EGL_LEVEL = 0x0 EGL_MAX_PBUFFER_WIDTH = 0x1000 EGL_MAX_PBUFFER_HEIGHT = 0x1000 EGL_MAX_PBUFFER_PIXELS = 0x100 EGL_MAX_SWAP_INTERVAL = 0xa EGL_MIN_SWAP_INTERVAL = 0x1 EGL_NATIVE_RENDERABLE = 0x0 EGL_NATIVE_VISUAL_ID = 0x0 EGL_NATIVE_VISUAL_TYPE = 0x0 EGL_RENDERABLE_TYPE = 0x1 EGL_OPENGL_ES_BIT EGL_SAMPLE_BUFFERS = 0x0 EGL_SAMPLES = 0x0 EGL_STENCIL_SIZE = 0x8 EGL_SURFACE_TYPE = 0x5 EGL_PBUFFER_BIT EGL_WINDOW_BIT EGL_TRANSPARENT_TYPE = 0x3038 EGL_TRANSPARENT_RED_VALUE = 0x0 EGL_TRANSPARENT_GREEN_VALUE = 0x0 EGL_TRANSPARENT_BLUE_VALUE = 0x0 Creating Window surface.. PVR:(Error): WSEGL_CreateWindowDrawable: Couldn't set CRTC: Permission denied [0, ] Unable to create surface egl error 'EGL_BAD_ALLOC' (0x3003) > --- > > > > Does anyone has any idea about this
