Jump to content

  • Log In with Google      Sign In   
  • Create Account

Krohm

Member Since 27 Aug 2002
Offline Last Active Dec 18 2014 12:59 PM

Topics I've Started

M8M, an educational miner

31 July 2014 - 02:51 AM

Hello, this is my first announcement in several years.

 

Due to life issues, I had to neglect a bit my C++ graphics skills. I realized it was time to update my knowledge to more modern GPU standards so I bought a Radeon and started playing with OpenCL. Since I have difficulty focusing on abstract problems, I needed something real to focus on. A friend of mine told me about this cryptocurrency thing so I decided to write a miner (plus: legacy miners are oldschool).

 

Now, I don't believe good software must be open source at all costs but writing this was great learning and there is the need of better understanding what this whole mining thing is, what is an hashing algorithm and such. So I decided to release it under MIT license, if you want to take a look. What I have updated should be buildable, albeit I haven't checked.

 

So what you get is the first (OpenCL) GPU miner written by someone with a clue about what a GPU is before crypto happened. My hardware seems to like it. cool.png

I'm looking to test it on other cards (since I only have a 7750). As a gamedev.net user, you get to try it for first.

 

Download M8M-249-preAlpha.zip

The package includes executable, kernels and config file (adeguate for 7750). Double-clicking it will be sufficient. You don't need install nor admin rights.

CAUTION! If you use the config file as is, you will be donating hashrate to me.

Which is of course a good thing to do, but I guess it's worth making this clear. rolleyes.gif

 

Be warned: pre-alpha.

It's still very clunky (in particular, only the quit button works in context menu). I haven't managed to get it to mine on P2Pool but it works on MPOS (or at least the MPOS I'm using now).

If this doesn't make any sense to you, I can offer support.

 

Only supported algorithm is Qubit, which unfortunately means you can mine MyriadCoin only.

 

I ask you to try it for at least 10 minutes and then post here your results (average hashrate or time spent on average iteration). I would appreciate if you could also post them to the MYR hardware comparison.

 

If you want to mess with the config file, I am not going to support any other param than linearIntensity at this time. Just scale it accordingly to your Radeon Compute Units count WRT 7750 and you should be fine.

 

Thank you!


How efficient are current GPU schedulers?

06 January 2014 - 03:08 AM

While I had a quick look on GPU releases in the last few years, since I've focused on Development (as opposed to Research), I've haven't had the time to deeply inspect GPU performance patterns.

On this forum I see a lot of people dealing with graphics is still optimizing a lot in terms of data packing and such. It seems very little has changed so far, yet on this forum we care about a widespread installed base.

 

In an attempt to bring my knowledge up-to-date, I've joined a friend of mine in learning CL, and we're studying various publicly available kernels.

In particular, there's one having the following "shape":

Attached File  MemoryUsage.png   1.07KB   6 downloads

The kernel is extremely linear up to a certain point, where it starts using a lot of temporary registers. After a while, those massive amount of values are only read and then become irrelevant.

 

What I expect to happen is that the various kernel instances will

  1. be instanced in number to fit execution clusters, according to the amount of memory consumed.
    What happens to other ALUs in the same cluster?
  2. Happily churn along until memory starts to be used. At this point, they will starve one after the other due to the low arithmetic intensity.
  3. The scheduler will therefore swap the "threads" massively every time they starve by bandwidth.
  4. When a "thread" is nearby the ending, compact phase, the swapping will possibly end.

It is unclear to me if the compiler/scheduler is currently smart enough to figure out the kernel is in fact made of three phases with different performance behavior.

 

However, back when CL was not even in the works and GPGPU was the way to do this, the goal was to make "threads" somehow regular. The whole point was that scheduling was very weak and the ALUs should have been working conceptually "in locksteps". This spurred discussions about the "pixel batch size" back in the day.

 

Now, I am wondering if simplifying the scheduling could improve the performance. On modern architectures such as GCN (or Kepler).

The real bet I'm doing with him is that the slowdown introduced by increased communication (which is highly coherent) will be smaller than the benefit given by improved execution flow.

 

Unfortunately, we don't have easy access to neither GCN nor Kepler systems, so all this is pure speculation. Do you think it still makes sense to think in those terms?

 

Edit: punctuation.


Not traversing the prototype chain?

27 December 2013 - 12:42 PM

I've come to the conclusion I missed something very important about the prototype chain and how to set up "proper" OOP inheritance in Javascript.
Here's what I think I'm doing:
01function Interesting() {
02    this.a = []; /* Array of Auxiliary structures */;
03    this.b = ...;
04}
05Interesting.prototype = {
06    Auxiliary: function(c, d, e, f) {
07        /* validity checks.
08        This is a basic "packet" of data.
09        It could be a stand-alone object but since it's used only
10        when dealing with Interesting objects, I decided to define
11        its ctor here. */
12    }
13};
14// ...
15Interesting.prototype.Auxiliary.prototype = {
16    c: undefined, // I'm still not sure about the style a base class should have BTW
17    d: undefined,
18    e: undefined,
19    f: undefined
20};
21// ...
22function DefaultInteresting() {
23    Interesting.call(this); // Seems to work ok.
24    this.parts[0] = new Interesting.Auxiliary(1, 2, 3, 4); // Auxiliary is undefined
25    this.b[0] = undefined;
26};
27DefaultInteresting.prototype = Interesting; // new Interesting() does not seem to work either

Problem is line 24. If I do new Interesting.prototype.Auxiliary(1, 2, 3, 4) then it calls the correct function.

Why is this happening? It was my understanding this should have been automatic. The inheritance chain in the debug window appears to be indeed correct. An hour of googling made me more confused.
What do you suggest me to look at?
 

Bringing really bad news, reccomendations

22 June 2013 - 04:25 AM

Hello everyone. Looks like I found a job. It's only a temporary job but at least it involves IT. It's not game related but I'm not sure I should put it in the lounge but since it's job-dynamics related I guess I'll drop it there.

I have to give really bad news to my boss and I'd like advice on how to do that "professionally".

Albeit it's only a temporary job, I won't disclose details; hopefully this is not going to be an issue there since the question is mostly about business dynamics rather than anything else my elaborations below are mainly to let you understand my current mindset and problem perception.

As a start, I've only been there for slightly more than a month and everything went fine so far. About three weeks ago, I was introduced to a certain program (The Program). Since two weeks ago, I have been given the task to evaluate The Program with regards to some of its features. I'll have to discuss The Program next week.

 

Deploying The Program to end users is apparently a priority (at least in terms of marketing), nonetheless, it so far slipped through the cracks by a few months and it's still far from being integrated in the business practice. AFAIK, The Program had no more than a couple of deployments so far, both in quite specific scenarios. I suspect the open position I'm filling is meant to hold someone dealing specifically with The Program, as the officially appointed "expert" isn't really taking this being already overworked (he has a business role that allows him to pull off the task).

In the past, I have never been scared from being the harbinger of bad news but considering my previous experiences, I've come to the conclusion I have to reconsider at least my methodologies in doing so. I need suggestions on how am I supposed to bring out this issue. Calling it an issue is rather reductive in my opinion: I've dealt with crashes, general instability, incoherent UI, missing input sanification, overreliance on end-user correctness, missing documentation, lacking support, systematic bugs... I could go on forever! And don't even get me started on licensing, Vendor itself seems to have lost grasp on it!

I found so many issues I started to ask myself about the developer studio so I went to google to find a very minimal amount of hits. Trends also informed me about a very low search volume, a thing which I find in stark contrast to the concept of a globally established leader solution. I understand business-oriented software is not really such a big hot topic but I guess there should be some more hits. Am I worrying too much? Do I have to recalibrate my scale of things?

I'm therefore inclined to believe this vendor is selling fry-ware. Because if we start deploying this, we're fried. Sure thing: developer has no QA (nor people doing debugging, much less architecture).

Of course, since we deploy it to end users, we take responsibility on that and given its general instability and fragility to slip errors, I'd say

  1. It's high business risk: component is critical to end user business
  2. Probably not profitable: maintenance requires super extra special care, even license management itself is something to be performed with care.

So my personal opinion is that The Software should be ditched in favor of something that actually works or proprietary solution.

I mean, what's the reason to sell it? We're basically selling the licenses for this other company. Sure, we might get some benefit but at what cost? If we get even a single on-site support call per year (remote management will be unlikely) our margins are going to suffer massively.

According to my colleagues, "we're pushing it because all other competitors are doing the same". Sure thing. But what has the end user to gain? He as to pay. He as this extra layer of complexity. He has to be more careful than he already is when doing his daily activities. And that supposing the software works fine.

 

Of course I am not in the position of saying the whole policy over the last few months is to be scrapped. But I couldn't get along either and not expose the risks. How could I convey this message in a business-appropriate way?

 

Honestly, I don't want to support The Program either because that means I would be responsible to keep it working and explain the many bugs to end users by inventing stupid excuses. To further exacerbate the issue, I think I could write something equivalent (for most basic tasks) in no more than 6 man months, not to mention it would fit with company's core business perfectly.

General advice on the situation is also appreciated.


Messed up compiles, different sub-field offsets

03 January 2013 - 09:22 AM

I don't really know where to look to fix this. Perhaps I should set a higher verbosity level?

So I checked project settings... they seem compatible. But maybe I've missed something. I guess so.

Or maybe I'm compiling against the wrong runtime in different packages? It seems not...

 

Ok, first thing first. While in the process of a bug hunt I have (I admit it has been a terrible idea) integrated AssImp in VC2012 build toolchain. Now I cannot get a correct executable. It compiles and it runs up to a certain point but then runs utterly amok.

Sometimes it seems to work with a full rebuild, but more often than not, it doesn't.

 

Problem is as follows. In the AssImp package,

Attached File  AssImp_ok.png   30.13KB   86 downloads

So my understanding is the following. Structure dstMesh begins at SOME_ADDRESS. The pointer mFaces is stored at SOME_ADDRESS+124.

AssImp works as intended. The shaded lines of code were added by me.

The size of an aiMesh structure is 1176 bytes.

Seems legit.

 

Now let's get to my code. So there could be anything going on as it's a different project.

Attached File  Filter_wrong.png   21.67KB   79 downloads

So sure I have messed up packing settings somehow.

I'm not even sure I've looked at them correctly. Perhaps I should look for pragmas.

Pointer size appears coherent.

I'm thinking about dumping offsets for all sub-fields and check the first difference in the hope to gain some insight on what's going on. I thought it might be a pointer-size difference but it's both 4 bytes.

 

Sure it's a project setting to double check. Or a defined macro? Where would you look?


PARTNERS