GstMemory Flags

[Stirling Westrup]

I'm in the middle of implementing a new type of GstMemory and would
like some clarification on the intended meaning of the
GST_MEMORY_IS_PHYSICALLY_CONTIGUOUS flag. The help text essentially
just repeats what the flag already says, and ignores the fact that any
piece of allocated memory represented by a single address is
NECESSARILY physically contiguous. So the flag appears to be
inherently useless (and indeed, it appears completely unused in the
gstreamer sources).

My only guess at a likely meaning is that it marks the memory as being
part of a larger contiguous piece of allocated memory, but without
additional associated information, this would appear to be of no use,
especially considering that GstMemory already has a mechanism to
handle this very thing, using the size and offset fields.

So, what is the flag intended to indicate?


--
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeu. 29 nov. 2018 15 h 14, Stirling Westrup <[hidden email]> a écrit :

I'm in the middle of implementing a new type of GstMemory and would
like some clarification on the intended meaning of the
GST_MEMORY_IS_PHYSICALLY_CONTIGUOUS flag. The help text essentially
just repeats what the flag already says, and ignores the fact that any
piece of allocated memory represented by a single address is
NECESSARILY physically contiguous. So the flag appears to be
inherently useless (and indeed, it appears completely unused in the
gstreamer sources).

My only guess at a likely meaning is that it marks the memory as being
part of a larger contiguous piece of allocated memory, but without
additional associated information, this would appear to be of no use,
especially considering that GstMemory already has a mechanism to
handle this very thing, using the size and offset fields.

So, what is the flag intended to indicate?

It was meant to announce if memory is contiguous in physical memory. Information known with NXP Freescale vendoe stack, but not generally available for Linux CMA allocation. In general, you should not need it.

--
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Thu, 2018-11-29 at 19:35 -0500, Nicolas Dufresne wrote:

>
>
> Le jeu. 29 nov. 2018 15 h 14, Stirling Westrup <[hidden email]> a
> écrit :
> > I'm in the middle of implementing a new type of GstMemory and would
> > like some clarification on the intended meaning of the
> > GST_MEMORY_IS_PHYSICALLY_CONTIGUOUS flag. The help text essentially
> > just repeats what the flag already says, and ignores the fact that
> > any
> > piece of allocated memory represented by a single address is
> > NECESSARILY physically contiguous. So the flag appears to be
> > inherently useless (and indeed, it appears completely unused in the
> > gstreamer sources).
> >
> > My only guess at a likely meaning is that it marks the memory as
> > being
> > part of a larger contiguous piece of allocated memory, but without
> > additional associated information, this would appear to be of no
> > use,
> > especially considering that GstMemory already has a mechanism to
> > handle this very thing, using the size and offset fields.
> >
> > So, what is the flag intended to indicate?
>
> It was meant to announce if memory is contiguous in physical memory.
> Information known with NXP Freescale vendoe stack, but not generally
> available for Linux CMA allocation. In general, you should not need
> it.

The important part here is that memory is of course virtually
contiguous when allocated as a single chunk of memory, but how the
pages of the allocation are laid out physically can be completely
different.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel