> Can you use those non-power-of-two mpeg surfaces as normal
>textures without limitations? I don't think most hardware can
>do that, some possibly can't at all.
Well for one thing my XvMC surfaces ARE power of two, but that is
not the point. The HWMC engine used the very same texture engine
as
>Well, except that, at least in the open-source DRI based drivers, the
>texture memory manager doesn't live in the DRM (anymore than malloc and
>free live in the kernel).
The texture manager itself may not but the drm is the arbitrator. As
I understand it the app takes the lock and then manages
> It *may* not always be required. There have been GLX extensions in the
> past (see my first message in this thread) that worked that way.
> However, as we discussed earlier, this doesn't seem to work so well with
> MPEG video files. The main problem being that you don't get the frames
> exa
On Mon, 2 Jun 2003, Sottek, Matthew J wrote:
>
> Let me preface my comment with "I don't know a lot about OGL" so some
> further clarification may be needed.
>
> I am assuming that pbuffers are basically buffers that can be used
> as textures by OGL. I would then assume that the OGL driver would
Sottek, Matthew J wrote:
Let me preface my comment with "I don't know a lot about OGL" so some
further clarification may be needed.
I am assuming that pbuffers are basically buffers that can be used
as textures by OGL. I would then assume that the OGL driver would
have some mapping of pbuffer id to
Let me preface my comment with "I don't know a lot about OGL" so some
further clarification may be needed.
I am assuming that pbuffers are basically buffers that can be used
as textures by OGL. I would then assume that the OGL driver would
have some mapping of pbuffer id to the texture memory it r
