Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thursday 10 December 2009 16:57:09 Igor Oliveira wrote:
> On Thu, Dec 10, 2009 at 6:32 AM, Zack Rusin wrote:
> > On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
> >> Hi Zack,
> >>
> >> 1) agreed. OpencCL is a complete different project and should exist in
> >> a different repository.
> >> 1.1) Well use Gallium as CPU backend is a software dilemma:
> >> "All problems in computer science can be solved by another level of
> >> indirection...except for the problem of too many layers of
> >> indirection"
> >> But in my opinion we can use Gallium for CPU operations too, using
> >> gallium as a backend for all device types we maintain a code
> >> consistency.
> >
> > Yes, it will certainly make the code a lot cleaner. I think using
> > llvmpipe we might be able to get it working fairly quickly. I'll need to
> > finish a few features in Gallium3d first. In particular we'll need to
> > figure out how to handle memory hierarchies, i.e. private/shared/global
> > memory accesses in shaders. Then we'll have some basic tgsi stuff like
> > scatter reads and writes to structured buffers, types in tgsi (int{8-64},
> > float, double}, barrier and memory barrier instructions, atomic reduction
> > instructions, performance events and likely trap/breakpoint instructions.
> > We'll be getting all those fixed within the next few weeks.
> >
> > z
>
> right,
> So until fix that issues i would be working in building system(i have
> many hacked things here), create an unit test environment and finish
> the patchs(that i sent to you) to implement all things used in OpenCL
> documentation(like errors handler in context creating).
That sounds great Igor.
> Other thing that could be done or started is the api_memory, you
> already implemented some cpu_buffers operations, right? or i am wrong?
That was a while back, all of that code should likely go. I think we'll end up
needing something like D3D11_BIND_UNORDERED_ACCESS and
D3D11_RESOURCE_MISC_BUFFER_STRUCTURED flags in Gallium3d but we can tackle that
later.
z
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thursday 10 December 2009 16:26:33 Younes Manton wrote:
> On Thu, Dec 10, 2009 at 3:34 PM, Zack Rusin wrote:
> > On Thursday 10 December 2009 15:14:46 Younes Manton wrote:
> >> OK, so we seem to be on the same page here, pipe_context will get some
> >> more functions. That's what I was originally asking about, will
> >> pipe_context grow or will there be a new kind of context? From my POV
> >> we would end up in roughly the same place either way.
> >
> > In general it's safe to assume that pipe_context as the main Gallium3d
> > interface will largely model the modern pipeline. Meaning that the
> > Gallium3d pipeline will look a lot like D3D 11 pipeline because
> > realistically that's what's going to get the most attention from hardware
> > vendors. So effectively 1) input assembler
> > 2) vertex shader
> > 3) hull shader
> > 4) tessellator
> > 5) domain shader
> > 6) geometry shader
> > 7) rasterizer
> > 8) pixel shader
> > 9) compute shader
> > 10) output merger
> > When it comes to compute OpenCL is more robust so the compute resources
> > will be designed to make sure CL 1.1 is easily implementable and
> > certainly make it possible to use compute without graphics but the
> > pipeline itself will have to stay as outlined above otherwise we'd just
> > be asking for trouble. Does that make sense?
>
> Makes perfect sense, I just had a completely different looking, yet
> practically identical picture that put orthogonal functionality (2D,
> 3D, compute, video) in seperate 'contexts' as far as gallium was
> concerned, even if everything ended up in the same command buffer on
> the backend.
>
> pipe_foo_context { foo(); bar(); }
> pipe_shaz_context { shaz(); blam(); }
> ...
>
> vs
>
> pipe_context { foo(); bar(); shaz(); blam(); }
>
> If we want to grow pipe_context beyond just 3D then thats fine too,
pipe_context isn't so much about 3d as it is about abstracting modern
programmable graphics hardware. compute shaders are becoming part of the
pipeline so it's hard to exclude them. different contexts certainly make a lot
of sense but for parts that are adjoining to the pipeline, rather than within
it.
extracting compute code into another context would make a few things a lot
more complicated than they should be e.g. for d3d given the same context is
used for both and compute shaders are executed after and can communicate with
fragment shaders so we would have to create another object that would unify
the commands and resources of our pipe_ contexts in some way and then give
guarantees for execution order, for cl we'd need to port mesa to the new
interface to allow sharing of GL resources as defined in the CL spec. all
things that we get for free with one context.
z
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thu, Dec 10, 2009 at 3:34 PM, Zack Rusin wrote:
> On Thursday 10 December 2009 15:14:46 Younes Manton wrote:
>> OK, so we seem to be on the same page here, pipe_context will get some
>> more functions. That's what I was originally asking about, will
>> pipe_context grow or will there be a new kind of context? From my POV
>> we would end up in roughly the same place either way.
>
> In general it's safe to assume that pipe_context as the main Gallium3d
> interface will largely model the modern pipeline. Meaning that the Gallium3d
> pipeline will look a lot like D3D 11 pipeline because realistically that's
> what's going to get the most attention from hardware vendors. So effectively
> 1) input assembler
> 2) vertex shader
> 3) hull shader
> 4) tessellator
> 5) domain shader
> 6) geometry shader
> 7) rasterizer
> 8) pixel shader
> 9) compute shader
> 10) output merger
> When it comes to compute OpenCL is more robust so the compute resources will
> be designed to make sure CL 1.1 is easily implementable and certainly make it
> possible to use compute without graphics but the pipeline itself will have to
> stay as outlined above otherwise we'd just be asking for trouble. Does that
> make sense?
Makes perfect sense, I just had a completely different looking, yet
practically identical picture that put orthogonal functionality (2D,
3D, compute, video) in seperate 'contexts' as far as gallium was
concerned, even if everything ended up in the same command buffer on
the backend.
pipe_foo_context { foo(); bar(); }
pipe_shaz_context { shaz(); blam(); }
...
vs
pipe_context { foo(); bar(); shaz(); blam(); }
If we want to grow pipe_context beyond just 3D then thats fine too,
it's just that I was operating under the assumption that pipe_context
was for 3D all this time, so that's where the confusion comes from.
Cheers.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thursday 10 December 2009 15:14:46 Younes Manton wrote: > OK, so we seem to be on the same page here, pipe_context will get some > more functions. That's what I was originally asking about, will > pipe_context grow or will there be a new kind of context? From my POV > we would end up in roughly the same place either way. In general it's safe to assume that pipe_context as the main Gallium3d interface will largely model the modern pipeline. Meaning that the Gallium3d pipeline will look a lot like D3D 11 pipeline because realistically that's what's going to get the most attention from hardware vendors. So effectively 1) input assembler 2) vertex shader 3) hull shader 4) tessellator 5) domain shader 6) geometry shader 7) rasterizer 8) pixel shader 9) compute shader 10) output merger When it comes to compute OpenCL is more robust so the compute resources will be designed to make sure CL 1.1 is easily implementable and certainly make it possible to use compute without graphics but the pipeline itself will have to stay as outlined above otherwise we'd just be asking for trouble. Does that make sense? z -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thu, Dec 10, 2009 at 3:03 PM, Zack Rusin wrote: > On Thursday 10 December 2009 14:35:47 Younes Manton wrote: >> Well how do we keep the compute state seperate from the 3D state, and >> how do you mix the two? > > It's really the same state. You bind a compute shader and execute it. It > doesn't affect the rest of your state. Compute binds the buffers pretty much > exactly like you'd bind them for any other api, and the "pretty much" comes > only from the fact that you can bind structured buffers with compute for > scatter reads/writes which purely graphics api don't have a lot of need for. > >> Do you have two state trackers using the same >> pipe_context and re-emitting their entire states to the HW as >> necessary? > > Why would that be necessary? Compute doesn't destroy the state that's been set > for graphics. > >> Do you use two pipe_contexts? > > That depends on how the context was created, i.e. it's up to API and the users > to decide how they want to use it. With d3d a lot of usage might be shared, > with opencl a lot of usage will use a separate context. > >> What about cards that know about compute and keep a seperate state? > > Well, a) compute doesn't care about the 3d state so that should be fine, b) if > they shared some intrinsics parts of the state between the scenes they became > deprecated the second D3D11 introduced compute shaders. > >> When you set a shader/read buffer/write buffer/const buffer with the >> pipe_context it's not clear to me what we should do on the driver's side. > > You should set a shader/read buffer/write buffer/const buffer like > pipe_context > asks you to =) > >> The card basically has seperate state for DMA, 2D, 3D, video, compute >> on nv50+, and a bunch of others. When we create a pipe_context we bind >> the DMA, 2D, and 3D and some of the others and issue commands. For >> nv50 we have a compute state, but we need to know what to do with >> commands coming through pipe_context, are they for 3D or compute? > > The compute state is for compute, the 3d specific state is for 3d =) When > we'll > do context->bind_compute_shader(...) surely you'll know that you're supposed > to set the compute shader. And for buffers NVIDIA and really anyone can't > require that distinction because they wouldn't be able to implement d3d > compute shaders. We'll likely add a buffer flag anyway, just to make it > explicit > that a certain buffer will be utilizing unordered access, just like most > likely > will slip in a dispatch(int work_groups_x, int work_groups_y, int > work_groups_z) call. > it really all boils down to a very simple math: the first api all ihv support > is directx => directx does it => we better do it. OK, so we seem to be on the same page here, pipe_context will get some more functions. That's what I was originally asking about, will pipe_context grow or will there be a new kind of context? From my POV we would end up in roughly the same place either way. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thursday 10 December 2009 14:35:47 Younes Manton wrote: > Well how do we keep the compute state seperate from the 3D state, and > how do you mix the two? It's really the same state. You bind a compute shader and execute it. It doesn't affect the rest of your state. Compute binds the buffers pretty much exactly like you'd bind them for any other api, and the "pretty much" comes only from the fact that you can bind structured buffers with compute for scatter reads/writes which purely graphics api don't have a lot of need for. > Do you have two state trackers using the same > pipe_context and re-emitting their entire states to the HW as > necessary? Why would that be necessary? Compute doesn't destroy the state that's been set for graphics. > Do you use two pipe_contexts? That depends on how the context was created, i.e. it's up to API and the users to decide how they want to use it. With d3d a lot of usage might be shared, with opencl a lot of usage will use a separate context. > What about cards that know about compute and keep a seperate state? Well, a) compute doesn't care about the 3d state so that should be fine, b) if they shared some intrinsics parts of the state between the scenes they became deprecated the second D3D11 introduced compute shaders. > When you set a shader/read buffer/write buffer/const buffer with the > pipe_context it's not clear to me what we should do on the driver's side. You should set a shader/read buffer/write buffer/const buffer like pipe_context asks you to =) > The card basically has seperate state for DMA, 2D, 3D, video, compute > on nv50+, and a bunch of others. When we create a pipe_context we bind > the DMA, 2D, and 3D and some of the others and issue commands. For > nv50 we have a compute state, but we need to know what to do with > commands coming through pipe_context, are they for 3D or compute? The compute state is for compute, the 3d specific state is for 3d =) When we'll do context->bind_compute_shader(...) surely you'll know that you're supposed to set the compute shader. And for buffers NVIDIA and really anyone can't require that distinction because they wouldn't be able to implement d3d compute shaders. We'll likely add a buffer flag anyway, just to make it explicit that a certain buffer will be utilizing unordered access, just like most likely will slip in a dispatch(int work_groups_x, int work_groups_y, int work_groups_z) call. it really all boils down to a very simple math: the first api all ihv support is directx => directx does it => we better do it. z -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thu, Dec 10, 2009 at 11:44 AM, Zack Rusin wrote:
> On Thursday 10 December 2009 11:25:48 Younes Manton wrote:
>> On Thu, Dec 10, 2009 at 5:32 AM, Zack Rusin wrote:
>> > On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
>> >> Hi Zack,
>> >>
>> >> 1) agreed. OpencCL is a complete different project and should exist in
>> >> a different repository.
>> >> 1.1) Well use Gallium as CPU backend is a software dilemma:
>> >> "All problems in computer science can be solved by another level of
>> >> indirection...except for the problem of too many layers of
>> >> indirection"
>> >> But in my opinion we can use Gallium for CPU operations too, using
>> >> gallium as a backend for all device types we maintain a code
>> >> consistency.
>> >
>> > Yes, it will certainly make the code a lot cleaner. I think using
>> > llvmpipe we might be able to get it working fairly quickly. I'll need to
>> > finish a few features in Gallium3d first. In particular we'll need to
>> > figure out how to handle memory hierarchies, i.e. private/shared/global
>> > memory accesses in shaders. Then we'll have some basic tgsi stuff like
>> > scatter reads and writes to structured buffers, types in tgsi (int{8-64},
>> > float, double}, barrier and memory barrier instructions, atomic reduction
>> > instructions, performance events and likely trap/breakpoint instructions.
>> > We'll be getting all those fixed within the next few weeks.
>>
>> Doesn't seem like the current pipe_context is suited to the
>> requirements of a compute API.
>
> Can you be more specific? Which parts you don't think are suited for it?
>
>> Should it be made larger or is another kind of context in order?
>
> I don't see anything missing from pipe_context to warrant a new interface.
> What exactly is your concern?
Well how do we keep the compute state seperate from the 3D state, and
how do you mix the two? Do you have two state trackers using the same
pipe_context and re-emitting their entire states to the HW as
necessary? Do you use two pipe_contexts? What about cards that know
about compute and keep a seperate state? When you set a shader/read
buffer/write buffer/const buffer with the pipe_context it's not clear
to me what we should do on the driver's side.
>> Under the hood on nvidia cards there's are
>> seperate hardware interfaces for compute, graphics, video, even though
>> there is some duplicate functionality, so it's not like most of the
>> code of our current pipe_context would be reused*, so to me a
>> different type of context makes sense.
>
> Really? To be honest I've never seen any compute specific hardware in nvidia,
> what is it?
The card basically has seperate state for DMA, 2D, 3D, video, compute
on nv50+, and a bunch of others. When we create a pipe_context we bind
the DMA, 2D, and 3D and some of the others and issue commands. For
nv50 we have a compute state, but we need to know what to do with
commands coming through pipe_context, are they for 3D or compute?
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thursday 10 December 2009 11:25:48 Younes Manton wrote:
> On Thu, Dec 10, 2009 at 5:32 AM, Zack Rusin wrote:
> > On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
> >> Hi Zack,
> >>
> >> 1) agreed. OpencCL is a complete different project and should exist in
> >> a different repository.
> >> 1.1) Well use Gallium as CPU backend is a software dilemma:
> >> "All problems in computer science can be solved by another level of
> >> indirection...except for the problem of too many layers of
> >> indirection"
> >> But in my opinion we can use Gallium for CPU operations too, using
> >> gallium as a backend for all device types we maintain a code
> >> consistency.
> >
> > Yes, it will certainly make the code a lot cleaner. I think using
> > llvmpipe we might be able to get it working fairly quickly. I'll need to
> > finish a few features in Gallium3d first. In particular we'll need to
> > figure out how to handle memory hierarchies, i.e. private/shared/global
> > memory accesses in shaders. Then we'll have some basic tgsi stuff like
> > scatter reads and writes to structured buffers, types in tgsi (int{8-64},
> > float, double}, barrier and memory barrier instructions, atomic reduction
> > instructions, performance events and likely trap/breakpoint instructions.
> > We'll be getting all those fixed within the next few weeks.
>
> Doesn't seem like the current pipe_context is suited to the
> requirements of a compute API.
Can you be more specific? Which parts you don't think are suited for it?
> Should it be made larger or is another kind of context in order?
I don't see anything missing from pipe_context to warrant a new interface.
What exactly is your concern?
> Under the hood on nvidia cards there's are
> seperate hardware interfaces for compute, graphics, video, even though
> there is some duplicate functionality, so it's not like most of the
> code of our current pipe_context would be reused*, so to me a
> different type of context makes sense.
Really? To be honest I've never seen any compute specific hardware in nvidia,
what is it?
z
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thu, Dec 10, 2009 at 5:32 AM, Zack Rusin wrote:
> On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
>> Hi Zack,
>>
>> 1) agreed. OpencCL is a complete different project and should exist in
>> a different repository.
>> 1.1) Well use Gallium as CPU backend is a software dilemma:
>> "All problems in computer science can be solved by another level of
>> indirection...except for the problem of too many layers of
>> indirection"
>> But in my opinion we can use Gallium for CPU operations too, using
>> gallium as a backend for all device types we maintain a code
>> consistency.
>
> Yes, it will certainly make the code a lot cleaner. I think using llvmpipe we
> might be able to get it working fairly quickly. I'll need to finish a few
> features in Gallium3d first. In particular we'll need to figure out how to
> handle memory hierarchies, i.e. private/shared/global memory accesses in
> shaders. Then we'll have some basic tgsi stuff like scatter reads and writes
> to
> structured buffers, types in tgsi (int{8-64}, float, double}, barrier and
> memory
> barrier instructions, atomic reduction instructions, performance events and
> likely trap/breakpoint instructions.
> We'll be getting all those fixed within the next few weeks.
Doesn't seem like the current pipe_context is suited to the
requirements of a compute API. Should it be made larger or is another
kind of context in order? Under the hood on nvidia cards there's are
seperate hardware interfaces for compute, graphics, video, even though
there is some duplicate functionality, so it's not like most of the
code of our current pipe_context would be reused*, so to me a
different type of context makes sense.
* Assuming noone wants to do compute via 3D on older HW that doesn't
have all of the modern compute facilities.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
> Hi Zack,
>
> 1) agreed. OpencCL is a complete different project and should exist in
> a different repository.
> 1.1) Well use Gallium as CPU backend is a software dilemma:
> "All problems in computer science can be solved by another level of
> indirection...except for the problem of too many layers of
> indirection"
> But in my opinion we can use Gallium for CPU operations too, using
> gallium as a backend for all device types we maintain a code
> consistency.
Yes, it will certainly make the code a lot cleaner. I think using llvmpipe we
might be able to get it working fairly quickly. I'll need to finish a few
features in Gallium3d first. In particular we'll need to figure out how to
handle memory hierarchies, i.e. private/shared/global memory accesses in
shaders. Then we'll have some basic tgsi stuff like scatter reads and writes to
structured buffers, types in tgsi (int{8-64}, float, double}, barrier and
memory
barrier instructions, atomic reduction instructions, performance events and
likely trap/breakpoint instructions.
We'll be getting all those fixed within the next few weeks.
z
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thursday 10 December 2009 03:25:25 Jose Fonseca wrote: > I agree you're free to choose whatever build system you'd like if it's > going to be in a separate repos. > > I've used CMake many times and it is a very nice build system indeed. It's > also very convenient to use on windows (it can generate Visual Studio > files), and recently they made very easy to cross-compile linux->windows. > > The problem I had when I tried to convert Mesa to CMake was that it didn't > support convenience libraries -- a static library which contains -fPIC > objects. All mesa/gallium auxiliary libraries are like that since the > final target is a shared object, and it there was no way to extend CMake > to do that at that time [1]. Has this changed recently, or is this not > relevant for a OpenCL statetracker? A bit of both :) The state tracker itself won't be producing convenience libraries, it's really just a single library so it should be fine either way. And the solution that the CMake folks seem to be advocating (splitting sources into separate CMakeLists.txt files: http://www.cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F ) is imho a reasonable one. And yea, I really like that CMake can produce native build files on all platforms (Makefiles on linux, Visual Studio on Windows, XCode build files on osx...) and that it has self-contained installers for all platforms, it's very neat. z -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
I agree you're free to choose whatever build system you'd like if it's going to be in a separate repos. I've used CMake many times and it is a very nice build system indeed. It's also very convenient to use on windows (it can generate Visual Studio files), and recently they made very easy to cross-compile linux->windows. The problem I had when I tried to convert Mesa to CMake was that it didn't support convenience libraries -- a static library which contains -fPIC objects. All mesa/gallium auxiliary libraries are like that since the final target is a shared object, and it there was no way to extend CMake to do that at that time [1]. Has this changed recently, or is this not relevant for a OpenCL statetracker? Jose [1] http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg04040.html From: Igor Oliveira [igor.olive...@openbossa.org] Sent: Thursday, December 10, 2009 1:30 To: Zack Rusin Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods Hi Zack, 1) agreed. OpencCL is a complete different project and should exist in a different repository. 1.1) Well use Gallium as CPU backend is a software dilemma: "All problems in computer science can be solved by another level of indirection...except for the problem of too many layers of indirection" But in my opinion we can use Gallium for CPU operations too, using gallium as a backend for all device types we maintain a code consistency. 2)Well the project live in a different repository, so we could use CMake instead of SCons. Personally i prefer CMake, it is lot of fast to generate Makefiles and easy to use. 3)I prefer C++ but as you said it could cause militant schism because it is a complex language and many people do not like it. But i do not care if we use C instead of C++ :). Igor On Wed, Dec 9, 2009 at 3:08 PM, Zack Rusin wrote: > On Wednesday 09 December 2009 13:29:05 Igor Oliveira wrote: >> These patchs implements and implements stub context methods in OpenCL. >> Almost all operation in OpenCL use a context. >> The patch implements the gallium3d context and implements the methods >> below: >> >> -clCreateContext >> -clCreateContexFromType >> -clRetainContext >> -clReleaseContext >> >> ps: probably i show break it in 2 patchs > > Hi Igor, > > the patch looks ok. Thanks. > > we're just working on adding support for compute to Gallium so I'd probably > wait a bit so that we can nail down the framework underneath before anything > else. Also we have to decide the following issues before doing really > anything: > > 1) should the opencl state tracker live in a repository of its own or should > it live withing mesa3d repo like the other state trackers. The thing that > makes the opencl state tracker a bit different is that it has to work on raw > cpu (which is really subquestion to 1: should the opencl state tracker be able > to work without gallium when working on top of a cpu). i didn't really feel > like creating another branch of mesa and be merging things in initially which > is why there is a separate repo right now. > > 2) should the opencl state tracker be using cmake or scons. originally i > picked cmake because it generates actual makefile's and that's incredibly > useful. > > 3) the language selection. it's using c++ because llvm is using c++ and > because i dig c++, which is good enough for me but i guess it might cause > militant schism. > > i'd also like to rename it to "coal" to make it fit better with the mesa and > gallium naming. > > opinions? > > z > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
Hi Zack, 1) agreed. OpencCL is a complete different project and should exist in a different repository. 1.1) Well use Gallium as CPU backend is a software dilemma: "All problems in computer science can be solved by another level of indirection...except for the problem of too many layers of indirection" But in my opinion we can use Gallium for CPU operations too, using gallium as a backend for all device types we maintain a code consistency. 2)Well the project live in a different repository, so we could use CMake instead of SCons. Personally i prefer CMake, it is lot of fast to generate Makefiles and easy to use. 3)I prefer C++ but as you said it could cause militant schism because it is a complex language and many people do not like it. But i do not care if we use C instead of C++ :). Igor On Wed, Dec 9, 2009 at 3:08 PM, Zack Rusin wrote: > On Wednesday 09 December 2009 13:29:05 Igor Oliveira wrote: >> These patchs implements and implements stub context methods in OpenCL. >> Almost all operation in OpenCL use a context. >> The patch implements the gallium3d context and implements the methods >> below: >> >> -clCreateContext >> -clCreateContexFromType >> -clRetainContext >> -clReleaseContext >> >> ps: probably i show break it in 2 patchs > > Hi Igor, > > the patch looks ok. Thanks. > > we're just working on adding support for compute to Gallium so I'd probably > wait a bit so that we can nail down the framework underneath before anything > else. Also we have to decide the following issues before doing really > anything: > > 1) should the opencl state tracker live in a repository of its own or should > it live withing mesa3d repo like the other state trackers. The thing that > makes the opencl state tracker a bit different is that it has to work on raw > cpu (which is really subquestion to 1: should the opencl state tracker be able > to work without gallium when working on top of a cpu). i didn't really feel > like creating another branch of mesa and be merging things in initially which > is why there is a separate repo right now. > > 2) should the opencl state tracker be using cmake or scons. originally i > picked cmake because it generates actual makefile's and that's incredibly > useful. > > 3) the language selection. it's using c++ because llvm is using c++ and > because i dig c++, which is good enough for me but i guess it might cause > militant schism. > > i'd also like to rename it to "coal" to make it fit better with the mesa and > gallium naming. > > opinions? > > z > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Wednesday 09 December 2009 13:29:05 Igor Oliveira wrote: > These patchs implements and implements stub context methods in OpenCL. > Almost all operation in OpenCL use a context. > The patch implements the gallium3d context and implements the methods > below: > > -clCreateContext > -clCreateContexFromType > -clRetainContext > -clReleaseContext > > ps: probably i show break it in 2 patchs Hi Igor, the patch looks ok. Thanks. we're just working on adding support for compute to Gallium so I'd probably wait a bit so that we can nail down the framework underneath before anything else. Also we have to decide the following issues before doing really anything: 1) should the opencl state tracker live in a repository of its own or should it live withing mesa3d repo like the other state trackers. The thing that makes the opencl state tracker a bit different is that it has to work on raw cpu (which is really subquestion to 1: should the opencl state tracker be able to work without gallium when working on top of a cpu). i didn't really feel like creating another branch of mesa and be merging things in initially which is why there is a separate repo right now. 2) should the opencl state tracker be using cmake or scons. originally i picked cmake because it generates actual makefile's and that's incredibly useful. 3) the language selection. it's using c++ because llvm is using c++ and because i dig c++, which is good enough for me but i guess it might cause militant schism. i'd also like to rename it to "coal" to make it fit better with the mesa and gallium naming. opinions? z -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
These patchs implements and implements stub context methods in OpenCL. Almost all operation in OpenCL use a context. The patch implements the gallium3d context and implements the methods below: -clCreateContext -clCreateContexFromType -clRetainContext -clReleaseContext ps: probably i show break it in 2 patchs -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
