GUI requirements for 0.8 / Luxrays

[tomb]

Hi,

0.8 is well underway and with the inclusion of luxrays, we need to extend the gui to handle render devices setup and configuration. I'm opening this thread so we can have a discussion on how we should best go about doing this.

The gui would need the following elements:

List of native devices (CPU cores)
List of OpenCL devices
- GPU devices
- CPU devices

For the GPU devices there will also have to be sub-elements such as workgroup size, feeder threads etc

Also functions such as:
Save config | load config | config dropdown

These configfiles can then be referred to from the commandline as well (for luxconsole or as default profile in the gui)

I would also like a function for auto-tuning, that is finding the (or at least a) optimal configuration for the current scene (or for a synthetic scene)

Atm, I envision this being a tab along the top a la render/log

Any thoughts/ideas?

[dougal2]

I think this has been mentioned before, but I think networking could be set up in the same interface as another type of device. Networking devices should have settings such as IP:port, threads available and update interval.

[tomb]

I think this has been mentioned before, but I think networking could be set up in the same interface as another type of device. Networking devices should have settings such as IP:port, threads available and update interval.

Thats a very good point doug, I agree it could probably be put in the same place

[jeanphi]

Hi,

We also need to account for network rendering. The parameters either should not be transmitted with the scene data or should be discarded upon reception or should be sent according to a node selection scheme.
The parameters might be a bit hard to describe in a RIB like way, so it might be better to have a separate file with its own format and the ability to specify configurations for several nodes.
What do you think?

Regarding the GUI, maybe we could extend the network tab to expose the node configuration in a tree (open a node to list devices, provide a way to configure each device).

Jeanphi

[tomb]

Hi,

We also need to account for network rendering. The parameters either should not be transmitted with the scene data or should be discarded upon reception or should be sent according to a node selection scheme.
The parameters might be a bit hard to describe in a RIB like way, so it might be better to have a separate file with its own format and the ability to specify configurations for several nodes.
What do you think?

Yes, I think the separate config file is the best approach - there may be situations such as a render farm where the hw is totally homogenous, but that will probably not be the case in general, so it doesnt make sense to "multicast" it to all nodes

Regarding the GUI, maybe we could extend the network tab to expose the node configuration in a tree (open a node to list devices, provide a way to configure each device).

You mean tweak the luxrays render device settings of each node after they are added? Yes I guess. Not sure how this would work for running nodes though - what do you think Dade?

T

[jeanphi]

You mean tweak the luxrays render device settings of each node after they are added? Yes I guess. Not sure how this would work for running nodes though - what do you think Dade?

Changing the configuration might need to stop and restart the render obviously.

[tomb]

You mean tweak the luxrays render device settings of each node after they are added? Yes I guess. Not sure how this would work for running nodes though - what do you think Dade?

Changing the configuration might need to stop and restart the render obviously.

Perhaps changing the config shouldn't actually do anything until a manual "restart" is done - i.e. not automatically restart the node

I'll can do a quick mock up of such a tree-config thing this weekend if I manage to find some time

[patrickwalz]

what if you just looked at everything as a node -- nodes could report other nodes (eg feeder nodes, other network nodes, gpu device nodes, local cpu thread nodes) with the root always being a server
you would end up with a structure something like

Server - CPU Node, CPU Node, GPU Node, Client Node, Client Node

basically you would just filter up device info and contributions to the server...the device description could be made a queryable parameter to that could be sent and reside somewhere in the gui like post processing params...

[tomb]

Just a quick update - I'm sorry that I haven't been able to follow up on this, I've been very busy the last month at work in combination with some annoyingly persistent health issues I do think a lot about it though so I've not dropped the ball in any way

[a4jp]

I can't wait to use a version that uses the GPU.