[x264-devel] Bug (or bugs) in x264 rev 2334 OpenCL and one improvement proposal.

[Nihil]

 >>>> So which leaves adding OpenCL support on -p 2 and -p 3.
 >>>
 >>>Multi-pass encoding performs the lookahead on the first pass; the
 >>>lookahead doesn't run on the second pass, so there would be nothing
 >>>for OpenCL to do.
 >>
 >> Well this is my bad, I wasn't expressing myself clearly. What my 
improvement
 >> proposal kept in it and what I was thinking but not explaining 
obviously is
 >> following.
 >>
 >> To expand OpenCL and GPU usage for all possible work areas not just
 >> lookahead. After all OpenCL & GPU's are used for Bitcoin mining, 
password
 >> cracking, in heavy industry for making strength assessment, in
 >> supercomputers etc. So in sense like SMP work would be divided 
between CPU
 >> and GPU where some of the frames are processed in CPU and others in GPU.
 >
 >I'm confused; where is your proposal? Do you have a document
 >explaining how you intend to deal specifically with the
 >synchronization and parallelism problems inherent in GPU video
 >compression and interaction with an existing CPU encoder, as well as
 >restructuring or replacing all the various algorithms for which
 >efficient GPU implementation are impossible?
 >
 >It is very easy to say that you want something extraordinary to happen
 >(e.g. "I want a billion dollars and a personal starship"), but on its
 >own not very useful without some kind of plan ("how I intend to earn a
 >billion dollars and build a personal starship").

You are absolutely correct here it's easy for me to say or ask personal 
starship and that's exactly what I did.

As 35 years old father who works full time I may have hour or two in 
week for side projects. Even though I work in software development and 
network industry sadly doesn't mean that I have a lot of time to code 
outside of work.

So most I can do is ask that personal starship.

Now without comprehensive internal knowledge of x264 source code etc.

What I was thinking was that on -p 2 and -p 3 videos frame structure is 
already known. So for example dividing encoding between CPU and GPU 
could be done taking frames from one I frame to next. CPU encodes one 
IPB set while GPU encodes another IPB set. And if or when this isn't 
valid idea / process other ideas and maybe even some implementation can 
be looked from (in this case nVidia code, AMD might have something 
similar but since I haven't used ATI after early 2000 I don't know what 
they have to offer).

https://developer.nvidia.com/nvidia-video-codec-sdk
NVCUVENC - CUDA-Based Video Encoding
NVCUVENC is a hybrid CPU/GPU accelerated library with related code 
samples that creates video streams compliant with AVC/H.264.

Sure it's CUDA code but porting it to OpenCL should be possible on most 
parts. If it isn't well there is always more work requiring option which 
is GPU architecture specific implementation.

So here I'm asking personal starship.

 >Jason